OpsCenter 简化 IT 运营的新功能

AWS 团队欢迎客户提出意见和建议，并努力改进服务来提高客户的工作效率。AWS Systems Manager 中名为 OpsCenter 的新功能便是这一思路的体现，该功能可让客户汇集各项服务中的问题、事件和警报。如此一来，客户便可以在一个地方查看、调查和修复问题，就不必再频繁来往于多项不同的 AWS 服务之间了。

问题、事件和警报在这一新控制台中显示为操作项 (OpsItem)，并提供上下文信息、历史指导和快速解决方案步骤。该功能的目的是：通过确保在一个地方提供重要调查数据，来缩短解决问题的平均时间，提高工程师的工作效率。

处理 OpsItem 的工程师可以访问以下信息：

• 事件、资源和账户详细信息

• 以往具有相似特征的 OpsItem

• 相关的 AWS Config 更改和关系

• AWS CloudTrail 日志

• Amazon CloudWatch 警报

• AWS CloudFormation 堆栈信息

• 访问日志和指标的其他快速链接

• Runbook 和推荐的 Runbook 列表

• 通过 AWS 服务传递到 OpsCenter 的其他信息

• 这些信息可帮助工程师更快地调查和修复运营方面的问题。借助 OpsCenter，工程师可以使用 Systems Manager 控制台或通过 Systems Manager OpsCenter API 查看和解决问题。

我将在本博文的剩余部分探讨这一新功能的各种功能。首先，我打开 Systems Manager 控制台，确保自己处于相关区域，然后在屏幕最左侧的“运营管理”菜单中单击“OpsCenter”。

首次到达 OpsCenter 屏幕并单击“入门”后，系统会提示您配置源屏幕。在此屏幕上，系统会使用一些示例 CloudWatch 规则设置系统，并在特定规则触发时创建 OpsItem。例如，如果 AutoScaling EC2 实例停止或终止，则其中一条 CloudWatch 规则将发出警报。在此屏幕上，您需要为有权创建 OpsItem 的 IAM 角色配置并添加 ARN。CloudWatch 规则会使用此安全角色来创建 OpsItem。当然，您也可以通过 API 或创建自定义 CloudWatch 规则来创建 OpsItem。

现在，系统已经为我设置了一些 CloudWatch 规则，我要通过触发警报来对其进行测试。在 EC2 控制台中，我将有意取消注册（删除）与我的 AutoScaling 组相关联的 Amazon 系统映像。然后，我将 AutoScaling 组所需的容量从 2 增加到 4。AutoScaling 组稍后将尝试创建新实例，但是会因为我删除了 AMI 而失败。

正如我所料，这会触发 CloudWatch 规则，在 OpsCenter 控制台中创建 OpsItem。现在，OpsItem 状态摘要控制面板中打开了一个项目。我单击这个项目，以获得有关打开的 OpsItem 的更多详细信息。

系统会显示一个有关所有打开的 OpsItem 的列表，我可以看到我有一个标题为“Auto Scaling EC2 实例启动失败”的消息，它是由 CloudWatch 规则创建的，因为我删除了与 AutoScaling 组相关联的 AMI，所以实例未能成功启动。单击该 OpsItem 将会看到有关该 OpsItem 的更多详细信息。

我可以从这个概述屏幕开始探索该项目。查看此屏幕，我可以找到有关此 OpsItem 的更多信息，并看到它正在从众多服务中收集数据并在一个位置呈现这些数据。

在屏幕下方，我可以看到其他类似的 OpsItem 并可以探索它们。在现实中，这可能会为我提供关于以往如何解决类似问题的背景信息，确保运营团队从他们以前的集体经验中学习。如果 OpsItem 彼此已建立连接，我也可以手动添加它们之间的关系。重要的是，“运营数据”部分会为我提供原因方面的信息。状态消息特别有用，因为它指出了问题：AMI 不存在。

在相关资源详细信息屏幕上，我可以找到有关此 OpsItem 的更多信息。例如，我可以看到有关资源的标签信息以及相关的 CloudWatch 警报。我可以从 AWS Config 中了解详细信息，也可以深入查看 CloudTrail 日志。我甚至可以看到资源是否与 CloudFormation 堆栈相关联。

之前，我创建了一条件 CloudWatch 警报，当我的 AutoScaling 组上的实例数量低于所需的实例阈值（4 个实例）时，它会发出警报。如您所见，我不需要进入 CloudWatch 控制台查看此内容，我可以在此屏幕中看到预订应用程序实例数量低的警报状态。

“Runbook”部分非常具有吸引力；它为我提供自动解决此问题的方法。虽然有几个内置的 Runbook；但幸运的是，我有一个自定义的 Runbook，它可以自动修复这个具体的问题。它将根据我的 AutoScaling 组中一个运行状况良好的实例创建一个新的 AMI，然后更新配置以在创建实例时使用这一新 AMI。要自动执行这一过程，我选择 Runbook 并按“执行”。

它要求我为自动化作业提供一些参数。我将 AutoScaling 组名称 (BookingsAppASG) 粘贴为唯一必需参数，然后按“执行”。

在大约一分钟之后，在 Runbook 的“最新状态”列中会出现一个绿色的成功指示符，我现在能够查看日志，甚至将输出保存到 OpsItem 上的运营数据中，以便其他工程师可以清楚地看到我所做的事情。

回到 OpsCenter OpsItem 相关资源详细信息屏幕，现在我可以看到我的 CloudWatch 警报是绿色且处于“正常”状态，这表示我的 AutoScalling 组当前有四个实例正在运行，我可以安全地处理 OpsItem。

此服务现已推出，您可以立即在所有公共 AWS 区域中开始使用它，赶快打开控制台，开始探索可以节省您和您的团队宝贵时间的所有方法吧！

本文转载自 AWS 技术博客。

原文链接：

https://amazonaws-china.com/cn/blogs/china/opscenter-a-new-feature-to-streamline-it-operations/