在过去的文章中，我们讨论了创建一个明确的策略文档的重要性，物联网传感器，该文档描述了如何升级SLO违规行为，并给出了一个来自Google的SRE团队的文档的真实示例。这最后一篇文章是一个假设的练习，好淘客，提供一些场景来练习策略和演示边缘案例。下面的场景都假设一个服务的可用性SLO为"三个9"，该服务在后台错误上消耗了一半的错误预算，即我们的错误预算是0.1%的错误，南昌大数据，服务0.05%的错误是"正常的"。

首先，让我们回顾一下策略阈值：

场景1：短暂但严重的停机很快就会导致依赖性问题

错误预算：假设3个9，仅此停机期间服务就消耗了30天错误预算的70%。它已经超过了7天的预算，而且，考虑到背景错误，30天的预算也是如此。升级：已提醒SRE处理对生产的影响（阈值1）。如果SRE判断问题的类别（错误配置或二进制推送）足够罕见或充分缓解，那么服务将"带回SLO"，并且策略不需要其他升级。这是在设计上，策略在开发速度方面出错，仅仅因为30天的错误预算耗尽而阻止发布与此相反。

如果这是一个重复出现的问题（例如，连续两周发生，烧毁了一个季度的大部分错误预算）或以其他方式判断可能再次发生，然后是时候升级到阈值2或3了。

场景2：短暂但严重的停机没有明显的根本原因

错误预算：与之前的场景相同：服务已超过其7天和30天的错误预算。

升级：SRE收到警报，以处理对生产的影响（阈值1）。SRE迅速升级到开发团队。他们可能会请求新的度量来提供问题的额外可见性，安装回退警报，并且SRE和dev oncall会在下周优先调查问题（基本要求2）。

如果根本原因仍然无法理解，SRE会在第一周后暂停功能发布，直到停机超过30天的SLO测量窗口。更多的SRE和dev团队被从他们的项目工作中拉出来调试或试图重现中断—这是他们的首要任务，直到服务回到SLO中或找到根本原因。随着调查的继续，SRE和dev团队转向缓解、解决问题和建立纵深防御。理想情况下，当大修超过SLO范围时，SRE确信任何复发都将更容易成为根本原因，不会产生同样的影响。在这种情况下，大数据支持，即使没有确定具体的根本原因，他们也可以证明继续发布推送是合理的。

场景3：错误预算的缓慢消耗，其根本原因很糟糕

错误预算：如果没有解决，每月消耗1.5个月的错误预算。

升级：当7天预算被消耗时，在T+5天左右通过票据通知SRE oncall。SRE触发阈值2，并在T+7天左右升级到开发团队。由于与CPU利用率的增加有一定的相关性，SRE和devoncall假设错误的根本原因是性能回归。devoncall找到一些简单的优化并提交它们；这些优化在T+16天作为正常发布过程的一部分投入生产。这些修复没有解决问题，但是现在要为受影响的服务回滚两周的每日代码发布是不切实际的。

在t+20天时，服务超过了30天的错误预算，触发阈值3。SRE停止发布并升级以获得更多开发人员参与。dev团队同意组建一个由两个dev和一个SRE组成的工作组，其首要任务是解决问题的根本原因和补救措施。由于代码更改和回归之间没有很好的相关性，他们开始进行深入的性能评测并消除更多的瓶颈。所有的补丁都会在当前生产版本的基础上聚合成一个每周的补丁。服务的效率显著提高，但服务的错误率仍然很高。

在T+60天时，服务花费了90天的错误预算，云端云服务器，触发阈值4。SRE升级到执行领导层，要求进行大量的开发工作，以解决持续缺乏可靠性的问题。开发团队进行了深入研究，发现了一些体系结构问题，最终重新实现了一些特性，结束了服务器和客户机之间的边缘案例交互。错误率恢复到以前的状态，一旦发布再次开始，被阻止的功能将分批推出。

场景4：反复出现的、暂时的SLI偏移

错误预算：如果错误不会威胁到长期SLO，SRE完全有责任确保警报得到适当调整。因此，在这种情况下，假设错误尖峰不会在超过几个小时的时间内威胁SLO。

升级：基于SLO的警报最初通知SRE，升级路径继续进行，如慢烧案例。特别是，这个问题不应该仅仅因为SLI在两个版本之间恢复正常而被认为是"已解决"的，因为将服务恢复到SLO的门槛设置得比这个更高。SRE可能会调整警报，以便更长或更快地烧录错误预算触发页面，并可能决定调查该问题，作为其正在进行的服务可靠性工作的一部分。