「译文」常见的 SLO 陷阱以及如何避免它们

👉️URL: https://www.dynatrace.com/news/blog/common-slo-pitfalls-and-how-to-avoid-them/

✍️Author: Emory Zhao

📝Description:

服务等级目标（SLO）帮助 DevOps 团队实现业务目标。学习 5 个最佳实践以避免常见的 SLO 陷阱。

如今，在线服务需要接近 100% 的正常运行时间。这种需求使 DevOps 团队越来越需要维护关键业务应用程序的性能和可靠性。构建服务等级目标 （SLO）以及服务等级协议和服务等级指标，是团队评估和衡量错误预算范围内的软件性能的好方法。但是存在 SLO 陷阱。因此，在创建 SLO 时，避免这些常见错误非常重要，这些错误可能会给您的 DevOps 团队带来更多麻烦。

陷阱 1：SLO 与您的业务目标不一致

一个常见的陷阱是创建与您的业务目标或服务等级协议 （SLA） 不一致的 SLO。这可能会造成不必要的干扰，并偷走关键任务的时间。例如，一家银行的 IT 团队希望确保在过去 30 天内，对于没有收入影响的应用程序，具有 99.9% 的服务可用性和 <50 毫秒的延迟。为非业务关键型应用程序设置严格的 SLO 可能会导致在修复问题或执行任务以确保正常运行时间时浪费时间和资源。

如果 SLO 与关键业务目标或外部 SLA 无关，则最好重新考虑或重新校准该目标。最好的投资是为 面向客户、创收、高可见性 的应用程序管理 SLO。例如，支票存款应用程序的服务可用性不断违反 SLO，会造成客户的不满，导致潜在的收入影响。

陷阱 2：没有所有权或问责制的 SLO

当 SLO 被违反时，你会打电话给谁？谁拥有它？由高层管理人员创建的 SLO 在没有相关开发、运营和 SRE 利益相关者支持的情况下创建，当违规行为发生时，可能会导致相互指责、甩锅和混乱的作战室。没有所有者的损坏的 SLO 可能需要更长的时间来修复，并且与具有所有者和明确定义的修复过程的 SLO 相比，它更有可能再次发生。

为避免孤立的 SLO，请确保在创建 SLO 期间，关键利益干系人之间有高水平的协作，并且 SLO 经过审查、可行和达成一致。建立需要监视的相关服务级别指标 （SLI）、修复任何问题的过程、所需的相关工具以及解决的时间范围。在团队采用 SLO 之前，您应该讨论并同意所有这些问题。

陷阱 3：被动使用 SLO 与主动使用 SLO

通常，团队创建 SLO 是因为他们只是遵循行业中其他人正在做的事情，或者因为它们是常见的最佳实践。但许多人无法理解它与业务目标相关的目标。在这些组织中，IT 团队可能不会关注 SLO，直到违规行为发生，之后个人所有者争先恐后地解决这些问题。这本质上是被动的，并且侵蚀了 SLO 在维护应用程序的运行状况，可靠性和弹性方面为组织带来的价值。被动也不能防止类似的违规行为在将来再次发生，而是占用开发人员的关键时间。

为避免这种情况，请在设计过程的早期开始 SLO 讨论。推动将 SLO 评估整合到 CI/CD 管道中，而不仅仅是在生产中。通过告警和根本原因分析确保设置和跟踪错误预算，以便开发团队可以在问题成为问题并导致违规之前了解和分类问题。

陷阱 4：SLO 阈值过高或过低

最常见的 SLO 陷阱之一是通过将 SLO 目标设置得太高而过度承诺，或者通过将 SLO 目标设置得太低来实现不足。SLO 对于评估您的团队在交付已商定的内容（无论是面向客户的 SLA 还是内部商定的业务目标）方面的成功程度非常重要。如果你设置的 SLOs 使它们不断地被违反，那么它们就变得毫无意义，不能帮助你了解你的应用程序的健康状况。

让我们以服务可用性为例。根据 Google G-Suite 研究人员 的说法，一个好的可用性指标应该是 有意义 的（捕获用户体验）、成比例 的（指标的变化应该与用户感知的可用性的变化成正比）和 可操作 的（洞察指标为什么低或高）。

一个好的经验法则是：你在 SLO 中的成功应该与客户和用户体验相关，而违规行为应该代表服务恶化。例如，将服务可用性设置为 89% 的 SLO 可能会有问题，因为 11% 的停机时间可能会影响大量用户, 但与此同时，DevOps 团队不会收到任何告警或担心客户影响，因为他们的 SLO 在阈值内。

若要设置有意义的阈值，请与相关利益干系人合作，建立可实现且对明确用户体验有影响的 SLO。与所有者一起审查，以校准最能捕获特定用例的 SLI。以这种方式定制 SLO 可确保您花费资源来确保满足 SLO 的要求、高效使用、提升客户价值，并帮助开发人员改进其 QA 和解决方案流程。

陷阱 5：通过仪表板和电子表格手动评估 SLO

开发仪表板和电子表格来跟踪 SLO 性能对于组织和可视化 SLO 和 SLI 非常有用。然而，另一个常见的 SLO 陷阱是，许多组织使用不同的工具手动组装这些指标，这可能需要时间进行创新。需要通过查看多个仪表板来执行眼球分析，就会减慢质量评估过程，并引入更高的故障风险。

持续和自动化的发布验证就是答案。能够自动评估测试结果，利用监控工具中的关键 SLI，并计算质量分数，以便在生命周期的每个阶段自动执行通过 / 不通过决策，这对于减少人为错误和扩展 QA 流程至关重要。通过智能的数据驱动方法自动阻止不良代码的能力对于不断受到手动流程限制但又被要求快速交付更高质量软件的开发团队来说非常重要。

创建和监控 SLO 的自动智能方法

避免 SLO 陷阱并应对创建 SLO 的挑战可能会令人沮丧，尤其是在当今复杂的 IT 流程中。但是，通过 Biz、Dev、Ops 和安全团队之间的充分规划和高度协作，利益相关者可以更好地准备建立 SLO，以确保您交付的软件可靠、有弹性并满足客户期望。