如何管理错误预算：提升服务可靠性与 SLO 达成率的实践经验

客户可靠性工程中的错误预算管理方法

错误预算是服务可靠性管理中的重要工具，它可以帮助团队在功能发布速度与系统稳定性之间取得平衡。当服务超出服务级别目标（SLO）时，团队不应只依赖直觉决策，而应通过错误预算消耗分析，判断问题来源，并采取合适的发布控制、可靠性改进和风险缓解措施。对于研发团队而言，借助 PingCode 这类智能化研发管理工具，将目标、需求、开发、测试、发布和知识沉淀等环节打通，也有助于让错误预算管理更加数据化和可追踪。

偿还你的错误预算债务

信用卡欠款较高的人都知道，债务会给每月家庭预算带来多大压力。良好的理财习惯通常意味着：尽可能多地偿还债务，从而降低未来的月度支出。错误预算管理也是同样的道理。

一旦通过错误预算消耗分析，找出了影响预算消耗率的主要因素，就应该准备好将开发人员的精力从新功能开发转向解决这些根本问题。这可能包括：改进质量保证环境或测试套件，以便在有缺陷的版本上线前发现更多问题；也可能包括更好地部署自动化和监控系统，以便更快检测到问题版本并及时回滚。

这种做法可能会降低发布频率，或者减少每次发布中包含的变更量，从而降低引发错误预算消耗的风险。换句话说，你暂时放慢发布速度，是为了将来能够以原有速度更加安全地发布。

审视下游错误预算消耗

另一个需要考虑的问题是：如果错误预算超支并不是开发团队造成的呢？例如，如果你的数据中心或云平台发生硬件故障，开发人员对此也无能为力。当然，最终用户并不关心服务中断的原因，你也不希望他们的体验因此变差；但如果因为其他环节的问题而责怪开发团队，也显然并不公平。正如前文所说，这一点应当体现在错误预算消耗分析中。

接下来该怎么办？你可能需要与平台负责人沟通，了解他们过去经过验证的可靠性数据，以及这些数据是否与你设定的服务级别目标（SLO）相匹配。双方可能都需要做出一些改变：你需要改进自己的系统，使其能够检测并容忍平台侧的某些故障；平台方则需要提升对影响你服务的故障的检测和解决速度。

很多时候，底层平台本身并不会很快发生重大变化。因此，你需要决定如何应对未来可能出现的错误预算损失。你可能会判断这类损失非常严重，因此需要提升系统弹性，例如实施并演练跨云区域自动故障转移能力，让服务能够从受影响区域切换到未受影响区域。关于这一问题，也可以参考海外某些公司在相关技术博客中对“如何为存在依赖关系的服务定义 SLO”的讨论。

当软件发布导致错误预算超支

不过，分析也可能让你得出另一个结论：软件发布才是错误预算消耗的主要来源。海外某些公司的经验表明，二进制版本发布是导致服务中断的主要原因之一。许多事后复盘都是这样开始的：“我们发布了一个新版本，本以为它实现了用户会喜欢的 <X> 功能，但实际上它却产生了 <Y> 行为，导致用户在浏览器中看到错误、无法查看图片，或者每分钟收到 100 封退信。”

如果一系列严重问题导致版本发布消耗了过多错误预算，常见做法是冻结新功能发布。这可以被视为最后手段：它承认现有修复措施尚未带来足够的可靠性提升，因此必须降低变更频率，以保护用户体验。发布冻结还可以为开发团队提供空间和明确方向，使他们把注意力从功能开发转向可靠性改进。不过，这的确是一项相当激进的措施。

除了发布冻结，还有哪些选择？

为了避免直接冻结发布，可以考虑以下几种做法。

首先，可以明确调整功能开发与可靠性工作的比例。例如，团队通常采用两周一个迭代周期，其中 95% 的工作用于功能开发，5% 用于事后复盘和其他可靠性工作。团队可以约定：当服务超出 SLO 时，在后续迭代中将工作比例调整为功能开发 50%、可靠性工作 50%。

其次，可以对服务进行超额配置。例如，投入更多资源，将服务复制到其他云区域，或者运行更多服务副本，以承受更高流量负载。不过，只有当你确信这种做法确实有助于减少错误预算消耗时，它才是有效的。

还可以宣布一次可靠性事件，指定专人负责事后复盘和错误预算消耗分析，并提出改进建议。重要的是，业务部门必须事先承诺：这些建议将被优先处理。在涉及研发、产品、测试、运维和业务等多团队协同时，也可以借助 Worktile 这类通用项目协作系统，对任务、审批、日程、文档和责任人进行统一管理，避免可靠性改进停留在会议结论中。

凛冬将至：错误预算超支后，冻结应持续多久？

如果确实需要冻结新功能开发，那么冻结应持续多久？一般来说，应持续到错误预算超支完全消除，并且团队有充分信心认为超支不会再次发生为止。错误预算通常有两种主要计算方式：一种是固定周期，例如每个自然月；另一种是滚动周期，例如最近 N 天。

如果采用固定周期计算错误预算，那么对预算超支的应对措施会受到超支发生时间的影响。如果超支发生在月初第一天，你可能整个月都要暂停发布；如果超支发生在第 28 天，你实际上可能无需停止发布，因为下一次发布可能已经进入下个月，届时错误预算会被重置。除非你的客户也只按自然月感知故障，否则这种方式似乎并不利于优化客户体验。

如果采用滚动 30 天的错误预算衡量周期，某一天消耗的错误预算会在 30 天后滚出统计窗口。对于 99.9% 可用性的服务来说，第 N-30 天损失的错误预算会在第 N 天被“补回”。因此，如果你超支了 20 分钟，就需要等待这 20 分钟的超支从滚动窗口中消失。举例来说，如果你在第 N-29 天消耗了 15 分钟预算，在第 N-28 天消耗了 5 分钟，且之后没有发生其他故障，那么还需要再等待两天，错误预算才会重新回到正余额。

在实际操作中，你可能还希望等到积累出相当于错误预算 20% 的缓冲之后，再恢复正常发布。这样可以为一些小规模的意外消耗留出余地。

按照这条原则，如果一次重大故障在一天之内耗尽了整个月的预算，那么项目可能会被冻结整整一个月。现实中，这往往难以接受。但至少，你应该显著降低发布速度，以便释放更多工程时间来修复根本原因，也就是前文所说的“偿还错误预算债务”。此外，也可以参考海外某些技术团队关于“阻止发布”的讨论，其中通常会涉及升级策略和例外处理机制。

可以看到，滚动式错误预算衡量周期受故障发生日期的影响较小。我们建议尽可能采用这种方法。不过也必须承认，在现有监控工具中收集这类数据仍然可能具有一定挑战。

长期发布冻结的代价

冻结新功能发布并非没有代价。最糟糕的情况是：开发人员继续开发新功能，却不向用户发布。这样一来，变更会不断累积；等到恢复发布时，几乎不可避免地会出现一连串版本故障。

实践中已经出现过类似情况：如果在黑色星期五、新年等关键时期冻结服务发布，冻结结束后一周内往往会出现异常频繁的服务故障，因为所有积压的变更都会陆续抵达用户。为了避免这种情况，必须再次向受冻结影响的团队强调：冻结的目的，是让他们专注于可靠性开发，而不是继续堆积功能开发。

有时，冻结所有版本发布并不现实。例如，公司可能即将举办大型活动，因此无论用户最近体验如何，都迫切需要将某些新功能推向生产环境。在这种情况下，可以采用一种名为“银弹”的策略：产品管理团队拥有非常有限的权限，可以绕过发布冻结，部署关键功能。

为了让这种方法真正有效，行使这项权限的成本必须足够高，使用频率也必须受到严格限制。使用“银弹”应被视为一次失败，需要进行事后复盘，以弄清楚为什么会走到这一步，以及如何降低再次发生的风险。

充分利用错误预算，持续提升服务可靠性

在以原则性方法提升服务可靠性时，错误预算是一个至关重要的概念。它就像家庭预算一样，由你，也就是服务所有者，负责管理。但同样重要的是，服务相关方应在预算超支之前，就超支后的应对措施达成一致。

如果发现错误预算超支，冻结功能发布确实可以有效地将开发时间优先投入到可靠性改进中。但请记住，当错误预算超支时，盲目冻结发布并不总是合适的应对措施。你应该分析预算究竟消耗在何处，如何减少主要消耗来源，以及是否应当适度放宽预算约束。

归根结底，错误预算管理的目标不是限制发布，而是在功能交付速度、SLO 达成率和用户体验之间建立清晰、可执行的平衡机制。最重要的原则是：一切以数据为依据。