本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 运营可观察性
<a name="operational-observability"></a>

 需要具备可观察性，才能深入了解环境的性能，并帮助您发现和调查问题。它还有一个次要用途，允许您定义和衡量关键性能指标 (KPIs) 和服务级别目标 (SLOs)，例如正常运行时间。对于大多数组织来说，重要的操作 KPIs 是平均检测时间 (MTTD) 和平均事件恢复时间 (MTTR)。

在整个可观察性过程中，上下文非常重要，因为数据收集后，相关的标签也会被收集。无论您关注的是哪种服务、应用程序或应用程序层，您都可以针对特定数据集进行筛选和分析。标签可用于自动加入 CloudWatch 警报，以便在突破某些指标阈值时可以向正确的团队发出警报。例如，标签键`example-inc:ops:alarm-tag`及其值可能表示 CloudWatch 警报已创建。[使用标签为 Amazon EC2 实例创建和维护 Amazon CloudWatch 警报中描述了演示这一点的](https://aws.amazon.com/blogs/mt/use-tags-to-create-and-maintain-amazon-cloudwatch-alarms-for-amazon-ec2-instances-part-1/)解决方案。

 配置过多的警报很容易造成警报风暴 - 大量警报或通知迅速压垮操作员，降低他们的整体效率，同时操作员还要手动分类各个警报并确定其优先级。可以通过标签的形式提供警报的其他背景，这意味着可以在Amazon内部定义规则， EventBridge 以帮助确保将重点放在上游问题而不是下游依赖关系上。

 运营的作用常常 DevOps 被忽视，但是对于许多组织来说，中央运营团队仍然在正常工作时间之外提供关键的第一响应。（有关该模式的更多详细信息，请参阅[卓越运营白皮书](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/separated-aeo-ieo-with-cent-gov-and-partner.html)。） 与负责工作负载的 DevOps 团队不同，他们的知识深度通常不一样，因此标签在仪表板和警报中提供的上下文可以将他们引导到正确的问题运行手册，或者启动自动运行手册（请参阅博客文章 “自动[化 A CloudWatch mazon](https://aws.amazon.com/blogs/mt/automating-amazon-cloudwatch-alarms-with-aws-systems-manager/) Alarms”）。 AWS Systems Manager