大促保障最头疼的不是技术问题，是扯皮。业务方要快迭代多上功能，运维要稳定少发版本，两边天天为「这次发不发」吵。后来引入了错误预算这套机制，吵不吵了，因为该不该发变成一个数据问题，不是立场问题。
这是 Google SRE 体系里我觉得最聪明的一个设计。它的核心不是某个具体技术，而是把「追求 100% 可用」这个根本达不到的目标，换成了「用一个预算来管理可靠性」这个能执行的框架。
从 SLI 到 SLO 到错误预算
图：SLI（测什么）→ SLO（目标多少）→ 错误预算（可花的额度），最关键的一步是把抽象的可用性翻译成具体的预算。
先把概念理清楚，它们是一条链。
SLI（Service Level Indicator）是测量指标，比如请求成功率、P99 延迟。SLO（Service Level Objective）是 SLI 的目标，比如 99.9% 的请求成功。错误预算就是 1 减去 SLO，也就是允许你「不达标」的那 0.1%。
这个 0.1% 具体是多少时间，按月算大约是 43 分钟。意思是，一个月里你的服务有 43 分钟可以出问题，不算违约。这 43 分钟就是你能用来发布、试错、承担小故障的额度。
把「可用性」翻译成「预算」，是这个体系最关键的一步。它让可靠性从一个抽象的「越高越好」，变成一个具体的「你还剩多少额度可以花」。
错误预算怎么化解稳定和迭代的矛盾
图：错误预算把开发与运维的立场之争化解为看预算余额的工程决策——预算充足就发布，耗尽就冻结。
传统模式下，开发和运维是对立的。开发用预算（发新版本）来推进业务，运维保护预算（少发版本）来保稳定。谁来决定该不该发，靠吵架，靠谁嗓门大。
错误预算把这个矛盾数据化了。预算还充足，随便发，小故障是试错的正常代价，业务可以接受。预算耗尽或者烧得太快，冻结非关键发布，全组专注修稳定性问题。该不该发，看预算余额，不看立场。
这套机制最妙的地方是，它把「能不能上线」从一个需要说服很多人的政治问题，变成一个看数字的工程问题。没人需要为「发还是不发」背锅，预算替你做了决定。
SLO 怎么定
这是落地时最容易踩坑的地方。
第一条，SLO 要基于用户真实的期望，不是拍脑袋定个越高越好的数。问的是，用户能容忍多少不可用。
第二条，绝对不要定 100%。100% 是不可达的，总有故障，总有维护。把 SLO 定成 100%，团队永远在「违约」状态，错误预算永远是零，这个机制直接失效，永远冻结。
第三条，区分核心。核心交易链路的 SLO 要严，比如支付和账户。辅助功能的 SLO 可以松，比如后台报表和运营工具。一刀切要么过严拖累迭代，要么过松漏掉关键问题。
第四条，SLO 可调整。业务演进、用户期望变化，SLO 也该跟着调。但它是个需要走流程的决定，不是悄悄改个数掩盖违约。
多窗口多烧率，告警的升级版
图：基于烧率的告警只在「真有燃烧预算危险」时才响——快速烧立刻处理，慢慢烧看趋势，正常消耗不打扰。
成熟的 SLO 实践会用多窗口多烧率，这是告警层面的进化。
长窗口，比如 28 天的 SLO，看整体健康度。短窗口，比如 1 小时，快速发现问题。烧率，预算消耗的速度，判断紧急程度。
关键洞察是，告警该看的是预算消耗的速度，不是瞬时的绝对值。同样是预算在减少，慢慢烧是正常的迭代消耗，不用告警。快速烧（比如 1 小时烧掉 2% 的预算）是出事了，要立刻处理。持续地慢慢烧，也要关注趋势，可能是某个慢性病在拖累系统。
这套机制比传统的「超阈值就告警」聪明太多。传统告警的问题是噪音大，一个短暂的抖动就炸一堆告警。基于烧率的告警，只在「真的有燃烧预算的危险」时才响。
SLI 选什么
SLI 的选择有个原则，选用户感知最强的指标，不是选最容易测的指标。
可用性（成功请求除以总请求）、延迟（P99 或 P999 响应时间）、正确性（业务数据准不准），这三个是用户真正关心的。吞吐量（QPS）是容量指标，它高不代表用户体验好，它只是说明系统在处理很多请求。
选错 SLI 的后果是，你的 SLO 达标了，但用户依然在骂。因为你在优化一个用户根本不在乎的数字。
落地的现实挑战
讲了一堆好处，落地时这几个坎绕不过去。
SLI 难定义。用户体验是个主观的东西，量化成数字不容易。「慢」到底是 P99 超过 200ms 还是 500ms，每个业务不一样，得和业务方一起磨。
组织阻力。开发团队天然不喜欢被预算约束，觉得这是给他们上枷锁。这需要自上而下的推动，以及让大家看到这个机制最终是保护所有人，不是惩罚谁。
数据不准。错误预算要靠监控数据，监控不完善，预算就算不准，机制就成了空中楼阁。所以上 SLO 之前，先把可观测性建好。
这套机制很重，团队没经验的话容易把自己绕进去。务实的第一步是，先定一个最简单的 SLO（单指标可用性，比如 99.9%），跑起来，让团队习惯「看预算做事」这个节奏。等机制磨合好了，再加多窗口和多烧率。工程化的事，永远是先跑通再优化，别一上来就追求完美形态。
一个认知上的转变
SLO 驱动开发最深层的价值，在我看来是改变了团队对「故障」的态度。
传统观念里，故障是坏事，出了故障要追责、要写检讨。于是大家本能地隐藏小故障，不敢报，等到爆大的。
错误预算的视角下，只要在预算内，小故障是正常且健康的，它是迭代必须付出的代价。这种心态的转变，让团队敢于发布、敢于试错，也敢于把小问题暴露出来及时修，而不是捂着。
这才是 Google SRE 这套体系最值钱的地方。它不是一套告警规则，是一种用工程方式管理可靠性的思维方式，把可靠性从「靠运气靠拼命」变成「靠数据靠机制」。
