客户可靠性工程中的错误预算管理方法错误预算是服务可靠性管理中的重要工具它可以帮助团队在功能发布速度与系统稳定性之间取得平衡。当服务超出服务级别目标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 达成率和用户体验之间建立清晰、可执行的平衡机制。最重要的原则是一切以数据为依据。