针对高速团队的事件管理
什么是错误预算？它为什么重要？
每个开发、运维和 IT 团队都知道事件在所难免。
即使是拥有最出色人才和正常运行时间接近 100% 的大型公司，系统有时也会出现故障。例如苹果、达美航空或 Facebook，过去五年中，它们都因事件损失了数千万美元。
这一现实意味着服务级别协议 (SLA) 绝不应承诺 100% 的正常运行时间。因为这是任何公司都无法兑现的承诺。
这也意味着，如果您的公司非常擅长避免或解决事件，那么您可能会一直在实现更高的正常运行时间目标。也许您承诺正常运行时间为 99％，实际上接近 99.5％。也许您承诺正常运行时间为 99.5％，实际上在一个月中达到 99.99％。
发生这种情况时，行业专家建议，与其通过不断超出承诺来将用户的期望设定得过高，不如考虑将额外的 0.99% 错误预算看成是您的团队可以用来冒险的时间。
什么是错误预算？
错误预算是指技术系统在不产生约定后果的情况下可以出现故障的最长时间。
例如，如果您的服务级别协议 (SLA) 规定，在企业必须针对中断补偿客户之前，系统将在 99.99% 的时间内正常运行，这意味着您的错误预算（或系统可以停机而不会产生任何后果的时间）为每年 52 分 35 秒。
如果您的 SLA 承诺 99.95% 的正常运行时间，则您的错误预算为 4 小时 22 分 48 秒。如果 SLA 承诺正常运行时间为 99.9%，则您的错误预算为 8 小时 46 分 12 秒。
为什么技术团队需要错误预算？
乍一看，错误预算似乎并不那么重要。它们只是 IT 和 DevOps 需要跟踪的另一个指标，以确保一切顺利运行，对吧？
幸运的是，答案是否定的。错误预算不仅仅是确保您兑现协议承诺的便捷方式。它们也是开发团队创新和冒险的机会。
正如我们在 SRE 文章中所解释的那样，
“开发团队可以用自己喜欢的任何方式来‘支出’这种错误预算。如果产品当前运行良好，几乎没有错误，他们就能随时随地发布想要推出的内容。相反，如果达到或超过了错误预算，并且其运行触及或低于定义的 SLA，则所有发布将被冻结，直到他们将错误数量减少到允许继续发布的水平。”
这种方法的好处是，它鼓励团队在可接受的限度内承担风险，从而最大限度地减少实际事件并最大限度地提高创新。它还弥合了以创新和敏捷性为目标的开发团队与侧重稳定性和安全性的运维团队之间的差距。只要停机期间保持在较低水平，开发人员就可以保持敏捷并在不受运维干扰的情况下推动变更。
如何使用错误预算
首先，您需要查阅您的 SLA 和 SLO。您已经为正常运行时间或成功的系统请求设定了哪些目标？您公司对客户做出了什么承诺？这些将决定您的错误预算。
基于正常运行时间的错误预算
大多数团队每月监控正常运行时间。如果可用性超过 SLA/SLO 承诺的数量，则团队可以发布新功能并承担风险。如果低于目标，则停止发布，直到重新达到目标数字。
为了有效地使用这种方法，您需要将您的 SLO 目标（通常以百分比表示）转换为开发人员可以使用的真实数字。这意味着计算允许停机期间的 1%、0.5% 或 0.1% 实际转化为多少小时和分钟。常见目标包括：
SLA 目标 | 每年允许停机期间 | 每月允许停机期间 | |
|---|---|---|---|
| 99.99% 正常运行时间 | 每年允许停机期间 52 分钟 35 秒 | 每月允许停机期间 4 分钟 23 秒 | |
| 99.95%正常运行时间 | 每年允许停机期间 4 小时 22 分钟 48 秒 | 每月允许停机期间 21 分钟 54 秒 | |
| 99.9% 正常运行时间 | 每年允许停机期间 8 小时 45 分钟 57 秒 | 每月允许停机期间 43 分钟 50 秒 | |
| 99.5% 正常运行时间 | 每年允许停机期间 43 小时 49 分钟 45 秒 | 每月允许停机期间 3 小时 39 分钟 | |
| 99% 正常运行时间 | 每年允许停机期间 87 小时 39 分钟 | 每月允许停机期间 7 小时 18 分钟 | |
基于成功请求的错误预算
SLO 不如 SLA 那么麻烦，但是如果它们含糊不清、过于复杂或无法衡量，则可能会造成同样多的问题。SLO 不会让工程师抓狂的关键在于简单明了。只有最重要的指标才有资格获得 SLO 状态，目标应以通俗易懂的语言阐明，并且与 SLA 一样，应始终考虑客户端延迟等问题。
通过 Jira Service Management，始终掌握服务级别协议 (SLA) 情况，根据优先级解决请求，并使用自动上报规则通知相应的团队成员并防止违反 SLA。