可观测性旅程成熟度模型
现代基础设施和应用程序复杂且不断演进。了解您的组织在可观测性旅程中的位置以及如何提高您的成熟度
评估您的组织的可观测性成熟度
模型
这个可观测性成熟度模型将提供一种方法，通过评估您的工具、人员和流程在 9 个关键维度上的表现，帮助您识别可观测性成熟度水平。这将有助于识别您的优势和改进机会。然后，该模型将帮助您确定可以采取的行动，以系统化地实现可观测性并保持您的应用程序正常运行。
如何使用
您可以使用此模型，从如何访问和分析可观测性数据以及如何响应和预防事件的角度来评估可观测性。要实现系统化的可观测性，需要掌握 9 个关键维度。
可观测性维度
访问
可观测性覆盖范围
可观测性数据访问
可观测性数据效率
分析
可视化
关联
根因分析
响应和预防
SLO 和业务影响
事件响应与管理
可观测性驱动开发
访问
可观测性覆盖范围
通过确定需要观察哪些应用程序、云服务和基础设施来保持环境运行，从而开始您的可观测性旅程。然后收集所需的可观测性数据，以获取对系统的可见性，包括来自应用程序架构关键组件的指标、日志和追踪。可观测性数据源包括云端和自托管基础设施、数据库、API，以及网络、安全、真实用户和合成监控。增加您可以访问的数据源和可观测性数据类型将扩大您组织的可观测性覆盖范围并减少盲点。
可观测性数据访问
接下来，您评估如何收集、存储和访问您的可观测性数据。一些数据收集代理是专有的，而另一些则使用开放标准，可以使用广泛的工具生态系统进行存储和可视化。可观测性团队应使用最新的标准（例如 Prometheus 和 OpenTelemetry）为开发人员和运维团队提供用于托管指标、日志和追踪的数据存储。您应该确定哪些数据可以通过 API 访问，哪些数据必须被收集和存储，以便您可以全面观察您的环境。
可观测性数据效率
最后，您需要高效地存储和管理大量可观测性数据。您提供的数据存储应具有可扩展性、高可用性、安全性以及高性能。您应该定义关于数据精确度和保留期的策略，并创建用于管理基数和成本的策略
分析
可视化
一旦您可以访问可观测性数据，您就需要确定最佳可视化方式。您需要创建跨组织的全局视图以及针对高管和技术用户的特定角色视图，并且最佳实践是在一个地方提供可视化来自众多源数据的能力。您应该为您的业务提供一个可靠的可视化平台，例如 Grafana 仪表盘，同时使用 RBAC 模型确保团队之间的数据访问安全，并与您的目录服务集成。
关联
可视化数据后，您需要能够关联不同数据源以快速解决问题。这包括关联多种类型数据的能力，包括指标、日志和追踪，以及业务和技术数据源。在不同工具之间切换既耗时又容易出错，因此减少关联数据所需的工具数量可以显著缩短识别和解决问题所需的时间。
根因分析
一旦您可以关联数据，您就需要创建一个高效的根因分析 (RCA) 流程和工具集。优秀的可观测性团队会跟踪平均恢复时间 (MTTR) 指标，并不断寻求改进流程以更快地识别根因。根因分析步骤依赖于可靠的数据精确度和保留策略，以确保有足够的数据可用，并平衡预算需求。跨职能团队之间的协作可以减少确定根因所需的工具和人员数量，从而减少错误并加快 MTTR。精心设计的根因分析实践还可以让可观测性团队从每个问题中学习，并持续改进其根因分析流程以预防未来的中断。
响应和预防
SLO 和业务影响
对于您支持的每项服务，您都需要确定性能和可用性预期。这通常以外部客户的服务水平协议 (SLA) 和内部客户的运营水平协议 (OLA) 的形式体现。大多数可观测性团队都为关键服务定义了服务水平目标 (SLO)，无论它们是否受 SLA 约束。报告 SLO 性能和业务影响成为高管管理其关键业务系统的必备工具。
事件响应与管理
通过中央系统统一告警可以帮助可观测性团队识别并通知适当的 On-call 工程师相关信息。可观测性团队应定义 On-call 轮换和升级策略，以及故障排除手册，以便最大程度地减少对特定个人的依赖。
可观测性驱动开发
在开发过程中实施可观测性的组织能够发布具有更高正常运行时间和更好性能的应用程序。在软件开发生命周期 (SDLC) 中越早实施可观测性和性能测试，就越能在影响用户之前预防更多问题。这种“左移”方法要求将指标、日志和追踪包含在编码过程中。它还包括质量保证 (QA) 性能测试阶段，以及专为开发人员设计的工具，这些工具可以对应用程序进行压力测试，以确保在新版本应用程序发布时能够承受生产负载。理想情况下，这些工具和方法应是开发人员熟悉的，以便轻松集成到您的开发流水线中。