翻译自 Boost SRE Productivity with Observability-Driven Automation 。
SRE 团队如何启动可观测性驱动的自动化工作？以下是开始的五个步骤。
数字化转型计划的成功取决于组织简化软件开发和交付流水线的能力。
这是确保产品快速上市并保证高质量和安全标准的关键。站点可靠性工程(SRE)团队在此扮演着至关重要的角色，但手动流程常常阻碍他们的生产力。这些流程范围从软件测试结果的审查到对生产环境中的问题进行分类和解决。提供有关软件质量和安全性见解的关键可观测性数据常常隔离在多个工具和团队之中。而监控解决方案无法跟上现代交付环境的变化。
可观测性驱动的自动化对于克服这些挑战和确保软件交付的未来成功变得至关重要。根据我们的 2022 年“SRE 现状报告”，85% 的组织表示，他们扩展 SRE 的能力将取决于自动化和人工智能 （AI）。通过将可观测性数据的自动配置、收集和评估集成到交付流水线中，SRE 团队可以使用自动化来提高速度、效率、可靠性和安全性，从而增强决策并提高工作效率。
那么，SRE 团队如何启动可观测性驱动的自动化工作呢？以下是开始的五个步骤。
首先，SRE 团队需要快速了解哪些版本随时正在运行、它们在哪里运行以及它们是什么版本。因此，必须有一个提供自动版本检测功能的解决方案。这将有助于 SRE 团队回答重要问题，包括以下内容：
- 当前在预生产和生产环境中部署了哪些版本的应用程序？
- 这些版本位于交付流水线中的什么位置？
- 在满足我们的服务级别目标 （SLO） 及其包含的安全风险数量方面，我们软件的最新版本与以前的版本相比如何？
通过了解组织运行的版本和软件，SRE 可以与每个应用程序的不同所有者合作，定义 SLO 以对性能进行基准测试。SLO 提供了一种通用语言，可增强这些团队之间的协作和指标收集，并增强其主人翁感。为了支持这种协作，SRE 还应设置实时仪表盘，使所有利益干系人能够持续跟踪和共享 SLO 数据。
必须定义错误预算，以便在建立 SLO 时允许少量降级，以便团队对可接受的服务级别和不可接受的服务级别有一个明确的目标。例如，如果组织的服务级别协议 （SLA） 要求其服务在 99.9% 的时间内可用，则他们需要错误预算为 0.1% 的 SLO，这定义了用户可以体验的最大停机时间。
利益干系人还需要自动跟踪其服务的剩余错误预算，以便他们可以更好地管理并避免违反 SLA。AI 支持的可观测性可以通过实时识别 SLO 违规的根本原因来进一步增强这些功能。这使 SRE 团队能够确保最高的服务级别，并通过为业务中的每个人提供见解来在问题违反 SLO 阈值之前解决问题，从而创造更多价值。
下一步， SRE 应根据定义的 SLO 范围为所有服务和应用程序创建健康评分。这将帮助他们了解每个版本的质量，以确保它没有降低先前版本的代码质量。因此，团队可以快速确定是否需要回滚某个版本。
理想情况下，生成此运行状况分数的持续分析和计算应该是自动化的，并且当团队需要深入挖掘以了解问题的原因和影响时，他们可以轻松访问。当应用于持续交付管道时，此运行状况分数可用作最低质量阈值，以防止不良版本投入生产，从而降低快速创新的业务风险。这些分数还有助于向 DevOps 和 SRE 团队指示他们是否有望实现 SLO 目标，以及反复出现的问题可能会导致严重问题。
SRE 还应将 SLO 运行状况检查集成到交付 pipeline 中，以支持多阶段交付，并为开发人员提供更强大的自助服务功能。这些运行状况检查充当质量门，在产品发布周期的每个阶段（从部署到测试和评估）提供急需的平衡。根据这些检查的结果，团队将得到一个明确的答案，即将他们的代码推进到下一阶段交付是否安全，或者他们是否需要返回进行进一步的优化。为了提高这些 SLO 运行状况检查的有效性，SRE 应确保支持问题单自动更新，并通过 Slack 等平台向相关利益相关者发送通知，以增强协作和审计跟踪。
SLO 驱动的修正是拼图的最后一部分，可帮助团队解决新版本或功能投入生产后出现的问题。SRE 的最终目标是确保 SLO 结果在事件管理工作流中标准化，以减少平均修复时间并鼓励更快地从事件中恢复。支持自动发布、通知和事件管理的单一统一解决方案集通过在交付流程中嵌入 SLO 来推动这些工作。
随着现代交付环境复杂性的增加、应用程序的不断扩展和组织的增长，SRE 团队面临的挑战也随之增加。使用 AI 驱动的可观测性来推动基于 SLO 的 DevOps 自动化已成为使 SRE 取得成功的关键功能。通过实时答案，他们可以构建更好的自动化，从而提高生产力、加快产品交付速度并改善业务成果。