题干与适用场景
面试官可能问：“系统设计中，你如何用错误预算平衡可靠性与发布速度？”题目要求你说明 SLI、SLO、错误预算如何落地到发布、回滚、容量和团队协作。它适用于 SRE、平台、后端和高级系统设计面试，尤其是题目包含高可用、频繁发布或多团队依赖时。
面试官在考察什么
核心考察不是背出 99.99%，而是把用户体验目标转成可计算的决策规则。Google SRE 将错误预算定义为 SLO 的剩余空间，用来协调可靠性投入和创新速度；预算耗尽时，团队应暂停普通变更，优先恢复可靠性。面试官还会看你是否考虑测量窗口、数据质量、渐进式发布和例外审计。
先澄清这几个问题
先问清楚用户是谁、关键旅程是什么、服务边界在哪里，以及目标是可用性、延迟、新鲜度还是正确性。再确认 SLO 的时间窗口、是否有多区域、依赖是否由别的团队维护、发布是否可回滚。若题目没有给数字，可以声明假设，例如四周窗口、99.9% 可用性和按用户请求计量。
30 秒回答框架
用五步回答：
- 先定义一个用户可感知的 SLI 和 SLO。
- 计算窗口内的错误预算，并说明预算消耗来源。
- 把预算连接到渐进式发布、自动回滚和变更门禁。
- 预算耗尽时冻结普通变更，投入可靠性修复；对安全和紧急修复保留明确例外。
- 用复盘、依赖归因和预算趋势调整下一周期目标。
逐步拆解深度解法
1. 先从用户结果定义 SLI
不要直接用服务器 CPU 或平均延迟当作可靠性目标。对请求型服务，可以选择成功请求比例和满足延迟阈值的请求比例；对异步任务，可以选择按时完成率或结果新鲜度。指标要区分用户受影响的失败、内部重试和无效流量，否则预算会被噪声消耗。
2. 选择可解释的 SLO 与窗口
例如四周内 99.9% 的有效请求成功，则允许约 0.1% 的有效请求失败。窗口决定团队对短时事故和长期趋势的敏感度。多 SLO 服务要说明合并规则：关键用户旅程可以设为发布阻断条件，次要指标用于告警和规划，不能把多个百分比简单平均。
3. 把预算消耗归因到变更
预算应记录总量、消耗速率和原因。发布、配置、依赖故障、容量不足和误报要分开标记。只有归因可信，团队才知道该修代码、调整容量、改变依赖契约，还是修正监控。Google 的示例策略还区分了本服务故障、外部团队故障和不在 SLO 范围内的流量。
4. 设计发布门禁与渐进式回滚
普通变更先进入小比例流量或单个区域，观察错误率、延迟和预算燃烧速率，再扩大范围。门禁应同时检查当前预算余额和短窗口燃烧率，避免月末平均值看似安全却正在快速恶化。发现异常时先回滚，再诊断，以缩短恢复时间；回滚本身也要有幂等和数据兼容方案。
5. 定义预算耗尽后的策略
预算耗尽不等于永远停止开发。冻结普通功能和非必要数据变更，把容量、测试、依赖隔离、降级和根因修复列为优先工作。安全修复和解决导致 SLO 下降的紧急缺陷可以例外，但必须记录原因、审批人和后续复盘，防止“紧急”成为绕过门禁的常态。
6. 处理依赖和跨团队责任
服务的 SLO 不应把所有外部失败都隐藏掉。记录依赖错误、客户端错误和本服务错误的维度，明确谁能修复、谁负责沟通。若两个团队的预算规则冲突，先对齐用户旅程和共享指标，再通过服务负责人升级；不要把责任转移当作可靠性策略。
高质量示范回答
以下回答为虚构示例，候选人应替换题目中的数字与边界：
我会先为最关键的用户请求定义成功率和延迟两个 SLI，假设四周窗口内有效请求成功率 SLO 为 99.9%，预算就是 0.1% 的失败空间。监控同时展示预算余额、近一小时燃烧率和失败归因，排除不在服务责任范围内的流量。发布采用单区域小流量、逐步扩大，任何阶段超过燃烧阈值就自动停止并回滚。预算正常时，产品和 SRE 可以在风险范围内发布；预算耗尽时冻结普通变更，优先做容量、测试、依赖隔离和根因修复，安全修复保留有记录的例外。每次事故做无责复盘，把修复项加入下一周期计划。这样发布速度由剩余预算和实时风险共同决定，而不是由团队偏好决定。
常见失分点
把错误预算当作可随意花费的额度
预算表达的是用户可接受的失败空间，不是鼓励制造故障的配额。回答必须说明用户影响、窗口、燃烧速率和修复责任。
只给一个可用性数字
没有 SLI 定义、统计范围和时间窗口，99.99% 没有决策意义。补充有效请求、延迟或新鲜度，以及如何排除无关流量。
预算耗尽后永远冻结发布
这会忽略安全修复、数据迁移和恢复工作的现实。应列出例外条件、审批、回滚和复盘，并保证例外不会变成默认通道。
忽略渐进式发布和回滚数据兼容
只说“监控后发布”不够。需要描述流量阶段、自动停止条件、回滚顺序，以及新旧版本读写兼容。
追问与进阶练习
SLO 达标但近一小时燃烧率很高，你会允许发布吗？
比较长窗口余额与短窗口趋势。若短窗口显示持续消耗，应暂停扩大流量，先确认是否为真实用户影响、突发流量或监控异常，再决定是否回滚。
外部依赖导致预算耗尽，自己的团队也要冻结吗？
先确认服务承诺是否包含该依赖故障，再按用户旅程决定。即使责任在外部，也要保护用户、启动降级，并与依赖团队共享证据；是否冻结本团队变更要写进事先约定的策略。
多个 SLO 同时失败，如何确定优先级？
按关键用户旅程、影响范围、燃烧速率和可逆性排序。先处理会扩大故障或阻塞恢复的指标，再处理局部性能问题，并说明取舍。
产品经理要求在预算耗尽时继续发布，你怎样沟通？
把争论转成数据：展示预算余额、用户影响、回滚成本和候选修复时间，提出小范围实验或延后方案。若确有紧急商业原因，走记录完整的例外流程，并约定复盘和补偿可靠性工作。