本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
第 1 阶段：定义你的北极星
可观测性的成功实施不仅仅是运营和工具，而是要培养一种主人翁意识、持续改进和主动解决问题的文化。与任何成功的策略一样，您的可观察性策略需要全面考虑三个支柱：人员、流程和技术。
当你想建立或改善自己的可观察性态势时，我们建议你从定义重要内容开始，根据业务结果进行反思，随着业务、团队和产品的发展，不断审查、调整和调整战略。
在第一阶段，你定义并建立你的北极星，这是对你的组织来说什么样子的一个商定且众所周知的定义。我们建议您随着业务的发展、推出新产品、应用程序或服务或设计重大架构变更时，重新审视此阶段的部分或全部活动，以重新评估您的可观测性平台和组织需求。
在开发生命周期的早期集成可观察性（左移方法）
将可观察性作为工程、运营和产品团队每位成员的责任，并将其视为主要的功能要求，就像处理单元测试或安全性一样。这不会将责任从运营团队转移到开发团队，而是突显了跨多个团队所需的协作。对于团队来说，在开发生命周期的早期协作执行以下活动会很有帮助。您可能需要按票证、每项功能或每件产品执行这些操作。
-
确定利益相关者。谁是利益相关者？如果此功能或产品不能按预期运行，对他们有什么重要意义？ 在确定利益相关者时，应考虑功能、可用性、安全性、成本、销售和产品使用等方面。利益相关者可以包括您的团队、产品的客户、内部业务利益相关者、平台运营团队的成员和应用程序开发人员。视情况而定，您的安全和财务团队也可以成为利益相关者。
-
确定关键成果。确定关键结果及其对业务和每个利益相关者的影响。确定每项结果和利益相关者的成功与失败。结果通常被定义为服务级别目标 (SLOs)，并且必须是可量化的。SLO 是衡量每个结果的指标。一个好的 SLO 有一个应该努力实现或保持的目标值作为目标。SLO 可以用来衡量用户满意度。服务级别指标 (SLI) 是用于确定您是否满足 SLO 的实际衡量标准：它是您根据目标跟踪的可量化数据点。例如，将 MTTR 降低 60%，将应用程序可用性保持在 99.99%，或者将开发人员工作效率提高 30%。
让我们以将应用程序可用性保持在 99.99% 为例，并定义衡量和验证成功所需的SLO、SLI和指标。在此示例中，让我们考虑一个 RESTful 应用程序，并将应用程序可用性定义为所有传入请求的成功完成。这需要衡量向应用程序提出的请求总数以及每个请求的完成状态。当您将它们转换为 SLO 和 SLI 时，您需要一个用于捕获传入请求的指标和另一个用于捕获请求状态的指标。如果所有请求都成功完成，则认为该应用程序可用。如果一个或多个请求导致错误，则认为该应用程序不可用。因此，SLI 将是错误的请求完成次数之和除以 5 分钟间隔内传入请求的总和，实际上就是错误率。您可以向此 SLI 添加一个目标，将其变成 SLO；例如：在连续 3 个 5 分钟间隔内，争取错误率低于 0.1%。
-
确定关键结果的优先顺序。根据你为每个结果设定的优先级，你可以选择首先关注影响最大的结果，而不是同时做所有事情。从小处着手，进行迭代，并以较小的增量改善您的可观察性姿势。可观察性是一个需要持续审查、审计、增强和改进的过程，以提高成熟度和收益。确定优先级还可以让你有机会定义实现已确定结果的渐进里程碑。
-
确定所需的仪器。架构或实现中有哪些组件和相关特征可以影响前面步骤中确定的重要结果？ 例如，当您在亚马逊弹性计算云 (Amazon EC2) 实例上运行应用程序时，内核数量和可用 RAM 会影响应用程序的响应能力和吞吐量。在此阶段，确定您使用的工具或库是否已经提供了其中一些工具也可能会有所帮助。进行一系列初步审查或在工单的就绪 (DoR) 定义
中添加以下问题可以使该活动成为标准流程的一部分。 -
如果此操作失败，您需要知道什么来解决失败？ 典型或有问题的操作会如何影响所涉及的组件？ 此操作应发送什么样的信号：日志、指标或跟踪？ 与其价值相比，这种仪器的成本是多少？ 哪种聚合在不违 SLOs规的情况下是可以接受的？
-
哪些组件和依赖关系可能导致此操作失败？ 您将如何确定哪个组件或依赖项导致了故障？ 这些组件和依赖关系有哪些不同的配置杠杆，它们对操作有何影响？
-
确保准确测量 SLI 和 SLO 所需的指标粒度和采样率是多少？
-
-
定义成功标准。对于每项按优先顺序排列的结果，定义与达到或未达到目标的影响相一致的阈值。成功标准为团队在响应警报时提供了额外的背景信息。它们还使您能够预测和权衡仪器的成本，以获得所需的可见性。
建立有效的组织和团队结构
根据架构的复杂性和业务规模，您可能需要组建一个专注于可观察性的专门团队。该团队将负责配置可观测性工具并为其他团队设置可观测性平台。如果您选择标准 OpenTelemetry 实施，我们还建议您成立一个专门的团队。在小型组织中，您可以将可观察性作为每个团队成员的额外责任，还可以任命可观察性倡导者，在团队中宣传和实施最佳实践。这些倡导者自愿抽出一天中的一部分时间来定义流程并为组织设定标准。他们要么作为一个自我规范的团队工作，要么可以由专门的可观测性专家领导。下图显示了您的投资如何决定您的组织方法。
冠军可以完全融入团队（如下图所示的第 2 组），也可以成为跨团队轮换以建立和推广最佳实践的支持团队的一员（插图中的第 1 组）。
跟踪成本分配
Organizations 应实施全面的成本跟踪和跨指标、日志和跟踪的可见性，同时建立针对特定团队的资源使用和成本问责制。要成功整合财务运营 (FinOps) 实践，就需要带有预算警报的自动监控系统，以及系统的数据保留和收集优化。工程和财务团队应通过共享仪表板和定期审查来调整其目标。组织受益于实施清晰的退款模式和成本分配策略，以推动所有权和问责制。
定义标准
识别和定义应用程序所需的基本信号和遥测数据，包括警报和仪表板策略。为每份申请创建清单或正式审查流程。AWS
Observabilit
建立上报流程
建立和执行上报机制、警报所有权和响应程序非常重要。我们建议您提倡一种不容忍升级的文化。
通过培训提高技能
确定提高现有和新团队成员技能的最佳方法，强调可观察性的重要性，培养持续改进的文化。根据组织的需求，您可以选择预先录制的按需培训或由可观察性倡导者或专家提供的课堂培训。您的 AWS 账户 团队可以提供深入的动手培训课程，例如O ne Observability Work
