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

# 第 2 阶段：实现可观察性
<a name="implement-observability"></a>

在这个阶段，你将开始让你的团队逐步走向北极星的过程。

## 选择您的可观测性平台
<a name="platform"></a>

第一步是确定合适的工具来摄取、可视化和分析信号，以及发送警报。选择工具时，请考虑其功能集、许可模式、价格、技能要求和维护。

### 功能集
<a name="features"></a>

以下是一些需要考虑的问题：
+ **可配置性和自定义**。该工具提供了哪些功能来简化调查体验并帮助降低 MTTR？ 该工具是否提供警报关联、指标数学、灵活处理丢失的遥测数据或异常检测？
+ **粒度**。遥测信号摄取和可视化的支持粒度是多少？
+ **人物角色。**该工具是否支持您想要为开发人员、平台工程师和其他角色提供的体验？ 它对技术角色和商务角色都有用吗？
+ **小工具**。仪表板支持哪些类型的微件？ 该工具是否允许创建自定义控件？
+ **预先构建的解决方案**。该工具提供了哪些类型的预建可观测性解决方案来缩短价值实现时间？
+ **自动化和生成式人工智能**。该工具提供了哪些功能可以帮助您和您的团队自动化或减少工作量？ 例如，自动异常检测、预测分析和其他生成式 AI 功能可以帮助减轻假设和*未知未知数*（即你既不知道也不完全理解的事情）带来的压力。该工具是否支持使用生成 AI/ML 模型来增强对大规模数据的分析？ 它是否为你提供了自动化和实施的选项 AIOps？
+ **安全。**该工具支持哪些类型的身份验证和授权集成？ 用户体验和登录体验是否满足贵组织的需求？
+ **OpenTelemetry 支持。**该工具和代理是否支持 OpenTelemetry？ 大多数可观测性平台都支持摄取 OpenTelemetry兼容信号，但并非所有代理都提供将这些信号转发到可观测性平台的配置选项。
+ **集成。**该工具提供哪些集成？ 考虑是否需要向 Slack、页面团队成员发送提醒，还是需要自动解决问题。
+ **可扩展性**。该工具的可扩展性和性能如何？ 可观察性解决方案必须随着需求和使用量的增加而扩展，因此即使您的应用程序不可用，它也可以提供诊断。
+ **Support。**提供什么支持模式？ 即使您的应用程序出现故障，您的可观察性工具也必须可用，这样您才能满足 MTTR 和应用程序可用性目标或服务级别协议（）。SLAs开源解决方案可能提供的正式支持有限。

### 许可和部署模式
<a name="licensing"></a>

考虑解决方案的许可模式（开源或商用）和部署模式（自托管或基于云）。开源选项的前期成本通常较低，但在提供价值之前，可能需要更多时间进行部署、设置和配置、维护和团队技能提升。如果您正在考虑开源选项，则可能需要一支由可观测性专家组成的专门团队。商业软件通常以更高的前期成本提供更快的价值实现时间，随着采用率、复杂性和成熟度的提高，对专门的可观察性团队的需求会随着时间的推移而变化。与基于云的解决方案相比，自托管解决方案需要更多时间进行部署、设置和配置、维护和运营开销。

### 定价维度
<a name="pricing"></a>

随着您的应用程序获得新用户、更大的架构占用空间或新功能和应用程序，该工具的定价模式将如何影响您的总拥有成本 (TCO)？ 例如，一些典型的许可模式是永久许可模式或基于订阅、指定用户数量、消耗量或数量的许可模式。考虑一下您的应用程序和可观测性工具的使用量将如何扩展，以及许可模式如何影响工具的成本。

### 团队技能
<a name="skills"></a>

根据团队当前的技能组合和成熟度，你需要确定需要多少技能提升。考虑供应商提供什么样的支持来培训您的团队。还要考虑您的组织结构是否支持您选择的工具的配置和管理。例如，如果你愿意 OpenTelemetry，你应该考虑成立一个专门研究可观察性的独立团队。

### 操作和维护
<a name="ops"></a>

评估以下问题：
+ 可观测性代理或收集器提供哪些部署选项？ 这些选项是否符合您的架构要求？ 例如，如果您为可观察性工具使用容器化部署，它是否支持守护程序集或边车？ 运营团队还需要采取或使用哪些其他步骤或工具来确保与安全和所有其他流程保持一致？
+ 维护解决方案需要付出多少努力？ 更新代理或收集器的过程有多简单或自动化？ 尽管代理或收集器的管理保持不变，但与自行部署和托管的应用程序相比，完全托管和基于云的可观测性接口的操作开销通常较低。考虑您的团队结构，并考虑维持所选选项的人力成本。

## 对您的应用程序进行检测
<a name="instrumentation"></a>

上一节中问题的答案为您提供了检测应用程序所需的信息，也就是说，添加代码以捕获应用程序中的遥测信号，以及测量、观察和验证行为。你可以使用 SDKs诸如应用程序语言的 OpenTelemetry SDK 来自动检测你的应用程序。您可能仍需要添加手动检测代码以弥补任何空白并确保 end-to-end可见性。请谨慎对待您添加的遥测数据，并确保可以将其连接到一个或多个遥测系统 SLOs ， SLIs 并且是在上一阶段建立的。

## 收集遥测数据
<a name="telemetry"></a>

[配置遥测收集器或代理，使其接收相关的遥测信号，使其与您在第 1 阶段优先考虑的结果保持一致。](define-north-star.md)

## 实现可观测性组件
<a name="components"></a>

当遥测数据流入可观测性平台时，创建仪表板、警报、行动手册和运行手册。
+ **仪表板：**创建包含相关信息的仪表板，包括与您的优先结果相关的当前和历史趋势的可视化表示。将这些仪表板提供给您在[第 1 阶段](define-north-star.md)中定义的利益相关者。有关更多信息，请参阅 Amazon Builders Library 网站上的[构建控制面板以实现运营可见性](https://aws.amazon.com/builders-library/building-dashboards-for-operational-visibility/)。
+ **警报：**定义警报，以便在结果面临风险或被违反时通知您的团队。考虑[为安全和性能问题添加警报](https://docs.aws.amazon.com/wellarchitected/latest/devops-guidance/o.cm.1-automate-alerts-for-security-and-performance-issues.html)。通过采用以下方法来优化[警报以减少警报疲劳](https://docs.aws.amazon.com/wellarchitected/latest/devops-guidance/o.cm.9-optimize-alerts-to-prevent-fatigue-and-minimize-monitoring-costs.html)和成本：
  + 使用异常检测可以避免设置需要频繁调整的硬阈值，并减少未知未知数的出现。
  + 使用可同时查看多个相关指标的智能警报组合，而不是为每个指标设置单独的警报。例如，与其分别为 CPU、内存和响应时间设置警报，不如创建一个有意义的警报，只有当这些指标共同表明存在实际问题时才会触发。这种方法可以显著减少警报噪音，帮助您的团队专注于影响服务的实际问题，而不必对孤立的指标峰值做出响应。
  + 仅在用户体验或结果面临风险时才生成警报。例如，当您的应用程序没有活跃用户时，请避免收到有关自动升级导致的 CPU 峰值的警报。
+ **剧本：**剧本为响应事件或警报的人提供了心理模型和背景信息，并帮助他们更快地确定根本原因。考虑为高度耦合、复杂的应用程序以及缺少工具但直接影响您在第 1 [阶段](define-north-star.md)确定和优先考虑的结果的应用程序创建行动手册。
+ **运行手册：**使用运行手册定义解决事件或警报所需的步骤。

## 验证可观测性系统
<a name="validation"></a>

在整个软件开发生命周期 (SDLC) 中，验证仪表板在系统测试期间是否提供了预期的行为和更新。实施[混沌工程](https://docs.aws.amazon.com/prescriptive-guidance/latest/chaos-engineering-on-aws/)并验证行动手册和运行手册中记录的步骤，以确保它们准确且符合其目的。您还应验证警报所有权和升级路径。