错误预算是指在违反服务水平协议（SLA）或目标（SLO）并损害用户信心之前，你的服务在一段时间内所能经历的错误数量或降级量。要理解错误预算，你首先必须理解SLA和SLO。建立错误预算是网站可靠性工程（SRE）的一个重要部分，即使用数据和软件驱动的方法来提高生产系统的运作。SRE是计算机科学的一个领域，它结合了软件工程和系统工程的原则来处理现代互联网服务的可用性和可扩展性需求。SRE团队负责构建、部署、维护、监控和排除大规模分布式系统的故障。
采用错误预算可以帮助你管理风险，创造一个更有弹性的服务，最大限度地提高你的正常运行时间和用户的幸福。这意味着除了工程上的优势外，错误预算还有一个强有力的商业案例。
在这篇文章中，你将了解什么是错误预算，如何设置错误预算，以及当错误预算用完后该怎么办。
什么是误差预算？
**误差预算是你的内部服务水平目标与你向客户承诺的实际SLA之间的差异，为你提供 "误差空间"。**误差预算通常包含在服务水平协议中，所以超过误差预算意味着你已经违反了与客户的合同。这意味着你可能有责任提供经济赔偿，并可能遭受声誉损失。
附有服务水平协议的服务往往包括错误预算，即使这一点没有被明确承认。例如，一个规定你的网站在一个日历年内必须有99.95%的时间在线的服务水平协议，给你的总错误预算是四小时二十二分钟四十八秒。这就是你必须 "花费 "多少时间--允许事件继续发生--才能对你的业务产生实质性影响。
错误预算是如何使用的
在实践中，错误预算通常是通过承担风险来使用的。例如，软件变化，如数据库升级、遗留系统迁移和主要的新功能发布，本身就是危险的。暂存环境和部署演练不可能抓住每一个边缘情况。错误预算在生产问题上给你留有余地，提供一个可以接受的停机时间的窗口。你可以用错误预算来执行这些操作，而不影响你的服务水平协议。
以一个简单的数据库模式变化为例：你知道这需要几分钟的时间来应用，而且有可能会失败，需要回滚。在部署的时候，你有两个小时的未使用的错误预算在你的测量期。你估计这将是充足的时间来执行回滚，如果需要的话。你继续应用该补丁。
然后，灾难发生了!更新没有成功，你不得不使用回退选项。结果整个过程花了10分钟，在此期间你的系统处于离线状态。
现在，你只剩下一小时五十分钟的错误预算；因为你仍然在你的SLA之内，所以没有必要为这次中断向客户提供补偿。错综复杂的错误也会耗尽错误预算。例如，客户可能会因为一个第三方库的响应时间过长而导致页面加载时间过慢。如果这被报告为你的服务的错误，它将使用宝贵的错误预算，而这些预算可以用在更关键的问题上。
错误预算的目的
错误预算是平衡持续创新和系统可靠运行的需要的一种巧妙方式。工程团队通常都是非常具有前瞻性的--你希望建立下一个大东西，增加价值，并带来更多的收入。
不过，用户对事情的看法略有不同。他们不太可能欢迎导致频繁不稳定的升级。一个系统只有在其功能可预测并且在他们需要的时候可以使用时，才对员工和客户有用。
错误预算告知开发重点
将错误预算纳入你的网站可靠性计划是将创新与最大正常运行时间相结合的一种务实的方式。有时，你能够通过建立新的能力和改进来快速进步。在其他情况下，你需要暂停并解决故障。错误预算提供了数据，因此你可以做出一个明智的决定，即哪一方在当前最需要你的关注。
因此，错误预算应该在你的组织中发挥积极作用。它们在开发团队和商业目标之间架起了桥梁。备用预算是对你的服务目前满足用户需求情况的有效衡量。这个信息应该被参与项目的每个人利用，从开发人员到项目负责人。
还要记住，错误预算的耗尽不一定总是由于开发人员--持续的高预算使用率可能表明公司进展太快，在压力下，正在犯错误。耗尽所有错误预算的团队通常被禁止发布新功能。
错误预算和开发人员的自主权
错误预算也是提高开发人员自主性的一种方式。许多开发者希望有更多的自由来选择他们的工作方式和完成任务的顺序。错误预算是一种在保护服务可靠性的同时提供这种服务的方式。
工程师应该可以自由地使用可用的错误预算--无论是通过启动功能、执行升级，还是试用新的实验系统。任何未分配的预算都可以用于追求创新，而不需要先征求运营部门的同意。这最大限度地提高了吞吐量，并鼓励团队减少发生的实时事件的数量，因为它释放了更多的时间来继续向前推进。
计算你的错误预算
错误预算通常在您的SLA中计算。这使得他们可以作为一个直接的指标来衡量何时发生故障违反了与客户的合同。
为了制定一个你可以承诺的SLA和错误预算，你可以采取的一个步骤是评估你最近经历的事件的数量，以及恢复它们所花费的时间。
错误预算也可以从SLO--你的内部正常运行时间目标--或你跟踪的任何其他与错误有关的指标中得出。
正常运行时间是错误预算的最常见形式。这衡量了你的服务可访问和正常运行的时间。许多SaaS供应商将正常运行时间作为其SLA的主要承诺，承诺在一定时期内达到99%，99.5%，甚至99.9%的可用性。
要从正常运行时间的百分比来计算错误预算，只需将考虑期内的总时间乘以你的百分比值。下面是一些常见的例子。
| SLA百分比 | 年度错误预算（停机时间） | 每月错误预算（停机时间） |
|---|---|---|
| 99.99% | 52分钟，35秒 | 4分钟，23秒 |
| 99.95% | 4小时，23分钟 | 21分钟, 54秒 |
| 99.90% | 8小时，46分钟 | 43分钟, 49秒 |
| 99.75% | 21小时，55分钟 | 1小时, 49分钟 |
| 99.50% | 43小时, 50分钟 | 3小时, 39分钟 |
| 95.00% | 18天, 6小时 | 1天，13小时 |
在承诺SLA之前，您应该始终以小时和分钟为单位计算您的停机时间预算。即使是正常运行时间百分比的微小变化，也会对您在一年内允许的停机时间产生巨大影响。例如，从99.95%到99.99%会使您的错误预算损失3.5小时。
通过失败的请求来计算
基于网络的系统的另一个流行的错误预算是失败请求的数量。你可以定义一个阈值，如果超过1%的请求发出5xx范围内的HTTP状态代码，就会产生一个事件。
这种预算最好以百分比来衡量，因为你无法预测在特定时期内发生的实际请求数。它取决于你的服务被持续使用的程度。
当错误预算被突破时
超过你的错误预算是一个严重的事件。如果违反的错误预算来自于你的SLA，你将需要对客户进行赔偿。此外，你的服务将停止满足用户的期望，使你的声誉受到影响。
当这种情况发生时，必须立即采取行动解决这个问题。你将用尽整个错误预算来应对风险，所以你所有的努力都需要集中在修复错误和防止未来的倒退上，而剩余的预算却很少。
以下是在剩余少量错误预算或已经超过错误预算时可以采取的一些步骤
冻结新产品的发布
开发团队需要把修补事故原因放在任何其他工作之前。因此，当你接近预算的极限时，新功能和其他非必要的改进应该停止。
运营工程师可以通过冻结生产中的部署来保护实时环境。阻止新代码的推出，可以保护应用程序不受进一步风险的影响，这将使你超过错误预算的阈值。这可以作为一种激励措施，确保开发人员在生产中注意其代码的质量和稳定性。
分析什么地方出了差错
在你解决了事件之后，分析是什么消耗了预算。回顾性分析可以帮助你发现以前未被承认的风险，你可以通过进一步的修补来缓解这些风险。这将使未来同样的问题烧掉错误预算的可能性降低。
预测下一个事件
这种从创新到服务恢复的转变最好是在你真正超过错误预算之前发生。你可以在内部同意，80%的错误预算消耗是启动转变的标志。
等到预算完全耗尽，意味着在事件解决后，你将无法承担任何风险，至少在你的SLA滚动到一个新的时期之前。当你需要发送新功能时，这可能会导致不可接受的延迟，但不能保证顺利推出。
记住错误预算的作用
虽然功能冻结可能令人沮丧，但请记住，在没有可用的错误预算时选择部署将对你的组织产生切实的影响。如果出了问题，你将没有回旋余地来解决这个问题，因为你已经违背了对客户的承诺。
更广泛地说，经常忽视错误预算的超额部分将考验你的客户的耐心，并降低你的平台被认为的可靠性。错误预算不是简单的被动计数，它们是为了积极防范商业风险。
结论
错误预算是一种软件可靠性工具，它对错误进行累积计算，直到达到一定的阈值。它们是一种确保符合商定的SLO和SLA的方法，同时允许承担一定的风险。
可用的预算是通过优先考虑新功能而不是导致错误的bug来 "使用 "的。这承认错误是不可避免的，而且团队需要空间来前进。然而，达到阈值应该激励组织解决这些问题，直到错误数量减少和新的预算配额可用。这可以确保可靠性问题得到及时解决，而不是无休止地推迟。
设置错误预算需要一个平台，能够在事件发生时进行跟踪，同时减少停机时间和错误预算的相关使用。Lightstep是一个云原生的可靠性解决方案，提供自动监测、可观察性和事件响应功能。
