题干与适用场景
服务的 SLO 是可用性 99.99%，月度错误预算为 0.01%。本月用户侧失败率已超过预算，团队仍有一项影响大客户续约的功能等待发布。请说明你如何定义指标、判断预算是否真实耗尽、决定哪些变更暂停，以及怎样恢复发布节奏。
Google SRE 将错误预算视为 SLO 允许的失败空间：预算未耗尽时，团队可以在合理范围内发布；预算耗尽后，通常冻结变更，保留紧急安全修复和解决当前故障的修复。这个机制是风险决策输入，不是无条件的产品禁令。
面试官考察点
高质量回答会从用户体验定义 SLI，再把错误预算与发布、回滚和恢复时间绑定。面试官会追问：服务端指标为何不能代表用户可用性、短暂尖峰与持续消耗如何区分、紧急功能怎样证明值得破例，以及谁有权解除冻结。
只说“预算耗尽就停止所有开发”忽略安全修复、数据完整性和合规义务；只说“业务重要所以照常发布”又放弃了共同的风险语言。
回答前需要澄清的问题
用户影响与指标边界
确认 SLI 是否来自真实用户路径，是否包含客户端、依赖和关键工作流。区分请求失败、延迟、数据错误和不可用；一个聚合平均值可能掩盖尾延迟或某类客户的严重故障。
预算窗口与消耗速度
确认预算按月、季度还是滚动窗口计算，当前消耗速率和不确定性是多少。预算余额应能回答“还能承受多久”，而不仅是显示一个百分比。
发布价值与风险
评估功能带来的收入、合规或安全价值，发布是否可灰度、可回滚、可限制租户。没有可验证的收益和回退路径时，不应以客户压力替代风险证据。
30 秒回答框架
“我先验证用户侧 SLI、SLO 窗口和错误预算消耗，确认是持续性问题还是采集误差。若预算确实耗尽，默认暂停非必要发布，把容量和工程投入转向恢复 SLO、修复根因和验证监控。安全、合规或修复事故的变更可以例外，但要小范围、可回滚、明确负责人。对大客户功能，我会尝试隔离租户的灰度或延迟发布，并用风险评审决定是否破例。恢复到约定的预算余量后，再逐步恢复常规发布，并复盘 SLO 是否真正反映用户价值。”
分步骤深入解答
第一步：把 SLI 定义成用户结果
为核心工作流定义成功率、端到端延迟和正确性，优先使用客户端或入口层数据。明确有效请求、排除维护窗口和多租户分层，避免把内部健康探针当成用户体验。若用户关心导出完成时间，单独建立作业完成 SLI，而不是只看 API 200。
第二步：计算预算与消耗
99.99% 可用性意味着给定窗口允许 0.01% 的失败比例；具体可容忍分钟数取决于窗口长度和统计方式。用统一查询计算剩余预算、消耗速率和置信区间，并标注数据延迟。预算消耗异常时先排除重复计数、采集缺失和依赖错误归因。
第三步：建立发布闸门
预算健康时允许常规发布，但仍要求自动回滚和监控。预算接近耗尽时提高评审级别、缩小批次和灰度比例。预算耗尽后冻结非必要变更，只允许修复故障、数据完整性、严重安全或合规风险的变更，并要求可回滚验证。闸门规则写进发布工具和责任矩阵，避免靠口头共识。
第四步：评估破例请求
对每个破例记录用户收益、风险、受影响租户、暴露比例、回滚条件和观察窗口。能否隔离到单租户、影子流量或内部用户，是降低风险的重要证据。产品负责人、变更负责人和 SRE 共同签字，不能由销售承诺单独决定。
第五步：优先恢复而非追求指标完美
冻结期间先修复根因、容量瓶颈和监控盲区，设定恢复 SLO、错误预算余量和截止时间。若 SLO 目标过于严格导致长期英雄式操作，应在复盘中调整目标，但不能为了发布而事后修改窗口或排除失败请求。
第六步：向客户与团队沟通
用受影响工作流、时间范围、当前缓解措施和下一次更新点说明决策。对客户功能提供可验证的替代方案或时间表，不承诺未经验证的恢复时间。内部以同一份预算看板、事件时间线和负责人列表沟通，减少产品与工程之间的政治争论。
第七步：恢复后的复盘与治理
预算恢复到约定阈值后分阶段放开发布，先小批次再扩大。复盘变更失败、检测延迟、回滚耗时和客户影响；如果 SLO 没有代表用户价值，提出带数据的调整。保留冻结、破例、批准和结果记录，便于季度风险审查。
高质量示范回答
我不会先凭“销售很急”或“预算归零”做绝对决定。先确认用户侧 SLI、统计窗口、数据完整性和预算消耗速度，排除采集错误与重复计数。若预算确实耗尽，默认冻结非必要发布，把容量、修复和监控投入到恢复可靠性；安全、合规、数据修复和缓解当前事故的变更可申请例外。
大客户功能若必须推进，我会优先隔离租户、使用小比例灰度、设置自动回滚和明确观察窗口。产品、变更负责人和 SRE 共同批准，并记录收益、风险和停止条件。预算恢复后逐步解除冻结，复盘 SLO 是否衡量了真实用户结果，再调整目标或发布流程。
常见错误
- 错误表现： 预算耗尽后冻结所有变更。→ 失败原因： 安全修复、数据修复和故障缓解可能被延误。→ 修正方法： 定义有限例外、审批人和回滚证据。
- 错误表现： 只看服务器平均延迟。→ 失败原因： 无法代表客户端失败、尾延迟或关键租户体验。→ 修正方法： 从用户工作流定义端到端 SLI。
- 错误表现： 为了上线而修改 SLO 窗口或排除失败请求。→ 失败原因： 预算失去可比性，风险被隐藏。→ 修正方法： 保持当前窗口，复盘后按正式治理流程调整。
- 错误表现： 用一次成功灰度证明可以全面发布。→ 失败原因： 暴露比例、依赖和长尾风险不同。→ 修正方法： 分阶段扩大并保留自动回滚。
追问及应对
追问一：99.99% 的错误预算是多少？
在固定窗口内允许的失败比例是 0.01%；换算成分钟必须说明窗口长度、统计口径和是否按请求或时间计算。面试中应强调预算是速率与剩余量，不要脱离窗口给一个无条件数字。
追问二：销售承诺的功能属于例外吗？
商业价值本身不足以自动破例。需要证明用户影响、收入或合规风险，提供隔离、灰度、回滚和观察证据，并由产品、变更负责人和 SRE 共同批准。若无法降低暴露，应延期并给出替代方案。
追问三：预算计算可能有误怎么办？
冻结高风险发布，同时并行检查埋点覆盖、重复计数、时间延迟、依赖归因和客户端样本。修正数据后重新计算，但不应在结果不明时继续扩大暴露。
追问四：何时调整 SLO？
在稳定运行和复盘数据表明目标与用户价值、成本或能力不匹配时调整。变更前记录旧目标、新目标、影响和批准人；不能把一次事故或一次发布压力作为临时调低目标的理由。
追问五：怎样判断冻结已经结束？
预先定义恢复条件，例如连续观察窗口内 SLI 达标、预算重新积累到阈值、根因修复已验证、回滚路径可用。达到条件后先小批次发布并继续监控，而不是瞬间恢复全速。