SLO 与可靠性

• SLO 的设定依据（业务需求、历史数据）
• SLO 过于严格的弊端
• 错误预算与发布节奏的关系

SLO 设定方法：1）基于业务需求——从用户可感知的指标出发（可用性、延迟、错误率），理解"用户对服务的最低可接受水平"；2）基于历史数据——统计近 30-90 天的实际表现（可用性、P99 延迟），设定在"历史可达 + 合理改进"的水平，避免脱离实际；3）SLO 应略高于实际但留有余量，形成可消耗的错误预算。SLO 不应过于严格的原因：1）过于严格导致错误预算过小，任何小故障都会触发告警与冻结发布，抑制发布迭代；2）为达到不切实际的 SLO 需投入过高成本（冗余、扩容），收益递减；3）严格 SLO 会引发"误报警疲劳"，反而降低告警可信度。合理 SLO 是"业务可接受 + 经济可持续"的平衡。

SLO 是"承诺"而非"理想"。过于严格会耗尽错误预算、抑制发布、增加成本。设定依赖业务需求与历史数据，让团队有"可燃烧的预算"。

• Multi-Window Multi-Burn-Rate 告警原理
• 单一窗口告警的缺陷
• 长短窗口组合避免误报漏报的机制

Multi-Window Multi-Burn-Rate 告警用多个时间窗口（如 5 分钟、1 小时、6 小时）同时计算错误预算消耗率，只有多个窗口同时超过阈值才告警。单一窗口告警的缺陷：短窗口（如 5 分钟）对瞬时抖动敏感，易误报（短暂的流量毛刺也被当作故障）；长窗口（如 1 小时）对快速恶化不敏感，易漏报（严重故障在长窗口内被平均稀释，需要更久才告警）。组合机制：短窗口用于快速发现"严重错误燃尽速率"（快速消耗），长窗口用于发现"缓慢稳定的消耗"（慢速消耗）；当多个窗口同时越界才告警，可过滤瞬时抖动（误报）又不漏掉持续恶化（漏报）。例如：5 分钟窗口燃尽率 > 14.4 且 1 小时窗口燃尽率 > 14.4 才告警，能同时捕捉快速与慢速消耗。

单一窗口在"误报"与"漏报"间不可兼得。多窗口组合要求"多个时间尺度同时超标"才告警，既过滤瞬时噪声又捕捉持续恶化，是告警设计的黄金标准。

• 稳态假设的定义与验证
• 稳态指标的采集与基线
• 故障注入前后的对比

稳态假设验证方法：1）定义稳态指标（业务 SLI，如吞吐、错误率、延迟分位数、资源利用率）与阈值；2）在故障注入前采集足够时长的基线数据，建立稳态基线（均值、分位数、波动范围）；3）注入故障后持续采集，对比故障期间与基线的偏差；4）用断言验证"故障期间稳态指标是否保持在可接受范围内"（如错误率不超阈值、P99 不超 SLO）；5）故障恢复后验证系统回到稳态（稳态恢复时间）。验证过程要区分"系统暂时偏离稳态但可恢复"与"稳态被破坏（不可恢复）"。稳态假设验证是混沌实验与可靠性测试的核心，用"故障前基线 vs 故障期间 vs 恢复后"三阶段对比。

稳态假设是可靠性测试的"对照组"。验证方法是"故障前采基线→故障中测偏差→恢复后验回归"，用量化断言判断故障影响是否可接受。

• 批处理管道 SLO 的维度
• 批处理与在线服务 SLO 的差异
• 完整性、新鲜度等指标

批处理管道 SLO 定义在以下维度：1）完整性——数据是否全部处理（处理记录数/总数、无丢失）；2）新鲜度（Freshness）——数据更新的滞后时间（如数据延迟不超过 X 小时）；3）准时性（SLA deadline）——批任务是否在指定时间窗口内完成；4）正确性——处理结果与预期一致（校验和、对账）；5）可用性——批任务成功率（成功运行/总运行）。与在线服务差异：在线服务 SLO 侧重"延迟与错误率"（用户实时感知），批处理 SLO 侧重"完整性、新鲜度、准时性"（数据质量与时效）。在线服务 SLO 用"请求率/错误率/延迟分位"衡量，批处理 SLO 用"处理完成率、数据新鲜度、运行准时性"衡量。

批处理 SLO 关注"数据是否完整、是否新鲜、是否准时"，与在线服务关注的"用户请求延迟与错误率"不同。SLO 设定需匹配业务形态。

• 串联依赖的可用性计算
• 并联依赖的可用性计算
• 组合可用性对 SLO 的影响

串联依赖（A 依赖 B 且 B 依赖 C，串行调用）：组合可用性 = 各依赖可用性相乘。例如 A 可用性 99.9%、B 99.9%、C 99.9%，则组合可用性 = 0.999³ ≈ 99.7%。依赖链越长，组合可用性越低，因此需要为每个依赖设更高的 SLO。并联依赖（A 依赖 B 或 C，任一可用即可，如多副本/多可用区/多路冗余）：组合可用性 = 1 - (1 - B可用性) × (1 - C可用性)。例如两组各 99%，并联可用性 = 1 - 0.01×0.01 = 99.99%。并联依赖通过冗余提升组合可用性。实际系统中多依赖混合，需按拓扑计算组合可用性，并据此分配各依赖 SLO（上游要高于下游以留出余量）。

串联依赖相乘会放大不可用，并联依赖相乘不可用率会降低。组合可用性计算指导"如何分配依赖 SLO"——关键链路依赖应设更高 SLO，或增加冗余。

• 错误预算消耗趋势与容量的关系
• 扩容时机的判断
• 资源需求的推导

容量规划方法：1）监控错误预算消耗趋势——若延迟/错误率上升导致错误预算消耗加速，说明容量趋于饱和；2）用"关键指标（如 P99 延迟、CPU 饱和度、队列长度）与负载的关系"识别容量瓶颈；3）当 P99 延迟接近 SLO 上限、资源利用率接近饱和（如 CPU>80%）时，触发扩容；4）根据负载增长速率与目标 SLO 预测未来容量需求（如未来 30 天负载增长 20%，则需预留对应资源）；5）用"错误预算消耗速率"作为扩容信号——若当前消耗速率会导致预算在周期内耗尽，则需扩容。容量规划还要考虑冗余（N+1）、突发流量与故障时的资源余量。

错误预算消耗趋势是"容量逼近上限"的前兆。当消耗加速说明系统接近饱和，据此判断扩容时机；用负载增长预测与 SLO 反向推导资源需求。

• SLI 与 SLO 的定义与关系
• SLI 的度量方式（可用性、延迟、错误率）
• SLO 阈值的设定

SLI（Service Level Indicator）是"度量服务表现的具体指标"，SLO（Service Level Objective）是"SLI 的目标阈值"。SLI 定义：1）可用性——成功请求数/总请求数（如 99.9%）；2）延迟——特定分位数（如 P99 延迟 < 200ms）；3）错误率——错误请求/总请求。SLO 阈值设定：基于业务需求与历史数据，设定在"可实现且留有余量"的水平（如历史 P99=180ms，则 SLO 定为 200ms 以留余量）。测试/发布视角：测试应验证"发布后 SLI 是否满足 SLO"——监控新版本的关键 SLI（可用性、延迟、错误率），用 SLO 作为发布门禁与回滚依据。SLO 是 SLI 的目标值，SLI 是度量依据，二者是"指标与目标"的关系。

SLI 是"度量什么、怎么度量"，SLO 是"目标值是多少"。测试与发布用 SLI 度量新版本表现，用 SLO 判断是否达标，SLO 是发布门禁。

• 错误预算耗尽时的测试策略
• 错误预算耗尽时的发布策略
• 预算驱动的优先级调整

错误预算耗尽时：1）发布策略——冻结高风险发布（暂停新功能、减少变更），优先稳定系统；只允许必要的低风险修复（hotfix）上线；2）测试策略——增加可靠性测试与回归测试，重点验证故障恢复与韧性；增加混沌实验覆盖，排查脆弱点；3）优先级调整——把资源从"新功能开发"转向"可靠性修复"，偿还可靠性债务；4）复盘——分析预算耗尽根因，建立改进项。错误预算驱动的决策本质是"用预算剩余量决定发布与测试的激进程度"：预算富余时鼓励快速发布与探索，预算耗尽时收缩发布、加强测试与修复。

错误预算耗尽说明"可靠性债务超标"，应收缩发布、强化测试、优先修复。错误预算把可靠性决策转化为可量化的治理机制。

• 面向用户 SLO 与内部 SLO 的区别
• 外部可感知指标与内部依赖指标
• 分层的 SLO 管理

面向用户的 SLO（External SLO）：基于用户可感知的指标（如用户请求成功率、页面加载延迟、下单成功率），反映用户对服务的真实体验，是最终契约。内部 SLO（Internal SLO）：基于内部依赖与组件指标（如 DB 查询延迟、缓存命中率、消息队列积压、内部服务可用性），反映内部组件健康，服务于外部 SLO 的达成。分层管理：1）外部 SLO 是目标，内部 SLO 是支撑——内部 SLO 需严于外部 SLO（如外部 P99 200ms，内部依赖要留出余量）；2）内部 SLO 用于内部告警与容量规划，外部 SLO 用于对外承诺与用户沟通；3）依赖聚合——内部 SLO 按依赖拓扑组合，确保串行链路不拖垮外部 SLO。分层管理的核心是"内部指标更严格、外部指标更权威"。

外部 SLO 是用户契约，内部 SLO 是内部健康度。内部 SLO 要严于外部 SLO 以留出余量，二者分层管理，内部支撑外部。

• SLO 违约后的补救措施
• 补救后的回归验证方法
• 验证 SLO 恢复的指标与流程

SLO 违约后的补救流程：1）定位根因（容量不足、代码缺陷、依赖故障）；2）采取补救措施（扩容、修复代码、切换依赖、降级）；3）回归验证——在验证环境验证修复后的 SLI 是否达标：容量扩容后验证负载下的延迟/错误率是否回到 SLO 内；代码修复后验证关键路径的 SLI 与故障场景；4）生产验证——通过金丝雀放量、监控生产 SLI，确认修复后 SLO 恢复（错误预算消耗速率回落）；5）持续监控——确认 SLO 在观察窗口内（如 24h）保持达标，错误预算不再异常消耗；6）复盘与行动项闭环。验证 SLO 恢复要用"同样的度量口径"（同 SLI、同窗口、同分位数）对比修复前后，确保对比有效。

SLO 违约补救要"验证有效"而非"只是修复"。用修复前后同口径的 SLI 对比 + 生产监控确认，形成"补救→验证→监控→闭环"。

• SLO 与 SLA 的定义区别
• 违约后果、度量口径、沟通对象的差异
• SLO 应严于 SLA，为内部提供缓冲以避免对外违约

SLO（Service Level Objective）是"内部目标"，是团队自己设定的服务表现目标，用于指导发布、容量规划与可靠性治理；违约后果是内部治理（冻结发布、修复、复盘），度量口径由团队自行定义，沟通对象是内部团队。SLA（Service Level Agreement）是"对外合同义务"，是与客户签订的合同条款；违约后果是合同赔偿（Service Credit、违约金），度量口径需与客户约定（明确、可审计），沟通对象是客户与商务。SLA 通常比 SLO 更宽松（SLA 是承诺客户的最低线，SLO 是内部追求的更高目标），即 SLO 严格于 SLA，确保内部有缓冲不违约。SLA 违约是合同事件，SLO 违约是内部治理事件。

SLA 是外部合同（有赔偿），SLO 是内部目标（治理内部）。SLO 应严于 SLA，保证内部有缓冲，避免对外违约。度量口径与沟通对象也随之不同。

• SLI 度量窗口与分位数的选择
• 滚动窗口与日历窗口的差异
• 聚合方式对 SLO 判定的影响

SLI 度量口径设计：1）窗口——可用性用时间窗口（如月度/30 天滚动窗口）聚合错误率；延迟用分位数（如 P99/P95）而非均值，避免被极端值掩盖。2）聚合方式——滚动窗口（rolling window）：滑动的最近 N 天/小时，能反映"当前趋势"，对突发故障敏感，SLO 判定随窗口滑动而变化；日历窗口（calendar window）：固定日历周期（如每月），判定简单、可预期，但对周期内分布不均不敏感（月初消耗多、月末还账）。3）影响——滚动窗口更利于实时监控与告警（能捕捉突发），日历窗口利于审计与对账（固定周期）。延迟分位数还应考虑"聚合粒度的键"（按服务/实例/租户）与"有效请求定义"（排除哪些请求）。度量口径不一致会导致 SLO 判定结果不同，因此口径必须明确定义并固化。

窗口与聚合方式决定 SLO 判定。滚动窗口敏感实时、日历窗口稳定可预期，分位数优于均值。口径必须明确固化，否则 SLO 判定会失真。

• 错误预算消耗速率的监控
• 消耗速率告警的设计
• 快速消耗与慢速消耗的区分

错误预算消耗速率监控：持续计算错误预算的消耗比例（已消耗/总预算），跟踪其随时间的变化。告警策略用 Multi-Window Multi-Burn-Rate：1）短窗口（如 5 分钟）监测"快速消耗"——严重故障导致错误率激增，预算快速烧毁；2）长窗口（如 1 小时/6 小时）监测"慢速消耗"——持续缓慢的错误率超标；3）定义燃尽率阈值（如 5 分钟窗口燃尽率 > 14.4 倍/小时），多窗口同时超标才告警，避免误报；4）告警分级——快速消耗为 P1/P0（紧急），慢速消耗为 P2（关注）；5）告警触发后关联行动（冻结发布、扩容、降级）。监控目标是在预算耗尽前及时发现并干预，避免"预算耗尽才告警"。

错误预算消耗速率监控的核心是"提前发现消耗过快"。用多窗口燃尽率告警区分快速与慢速消耗，在预算耗尽前及时干预。

• 预算耗尽时触发的组织行为
• 错误预算策略的强制执行
• 避免策略被忽视的方法

预算耗尽时的组织行为：1）冻结发布——暂停高风险新功能发布，只允许必要修复；2）增加测试——加强可靠性测试、混沌实验、回归测试，排查脆弱点；3）回滚——对导致预算消耗的变更回滚；4）优先修复——把资源转向可靠性修复，偿还预算债务；5）复盘——分析根因，建立行动项。避免策略被忽视：1）自动化执行——把预算策略固化为工具/流水线门禁（CI 自动检查预算，耗尽则禁止发布），而非依赖人工自觉；2）明确责任——预算耗尽有 owner 与升级路径；3）透明可见——预算状态公开可见（Dashboard），消耗异常自动告警；4）与考核挂钩——可靠性纳入团队绩效目标，避免策略形同虚设。策略要"可执行、可强制、可问责"。

错误预算策略要"自动化执行 + 透明可见 + 责任明确"，避免被忽视。靠工具强制而非人工自觉，才能让策略真正落地。

• 故障注入、回归、容量测试对 SLO 的支撑
• 三类测试的协同
• 可靠性测试的验证闭环

故障注入（Chaos）：验证系统在故障下仍能维持 SLO（可用性、延迟不超限），发现韧性缺口并修复，防止故障导致 SLO 违约。回归测试：验证功能正确性与关键路径质量，防止回归缺陷导致错误率上升、可用性下降，是 SLO 达成的基础保障。容量测试：验证系统在预期负载与峰值下的性能（延迟、吞吐），发现容量瓶颈，防止高负载下延迟超标、错误率上升导致 SLO 违约。三者协同：容量测试验证"负载下不超标"，故障注入验证"故障下不跌破"，回归测试验证"变更不引入缺陷"。可靠性测试把 SLO 作为验收标准，用测试保障 SLO 达成。

故障注入保"故障韧性"，回归保"变更质量"，容量保"负载性能"，三者共同支撑 SLO。可靠性测试以 SLO 为验收基准，形成"测试-SLO"闭环。

• 故障注入的测试方法
• 恢复验证的要点
• 故障注入与恢复的闭环

故障注入：向系统注入各类故障（网络分区、延迟、节点宕机、资源耗尽、时钟偏移），验证系统在故障下的行为（可用性、错误率、降级、熔断）。恢复验证：故障结束后验证系统恢复——1）恢复时间（从故障到恢复可用的时长，符合 RTO）；2）恢复完整性（数据不丢失、状态一致，符合 RPO）；3）恢复后性能回归（恢复到故障前水平）；4）恢复后的正常服务能力（无残留故障）。故障注入与恢复形成闭环：注入故障→观察行为→恢复→验证恢复→记录缺口→改进。可靠性测试要覆盖"故障期间"与"故障恢复"两个阶段，确保系统既能容忍故障又能快速恢复。

可靠性测试不仅验证"故障期间不宕机"，还验证"故障后能快速干净恢复"。注入与恢复是闭环，恢复验证涵盖时间、数据、性能三个维度。

• SLO 引入的路径（SLI→SLO→错误预算）
• 各步骤的实施要点
• 错误预算驱动决策的落地

引入路径：1）先定义 SLI——选择"用户可感知、可度量"的关键指标（可用性、延迟、错误率），明确度量口径与窗口；2）设定 SLO——基于历史数据与业务需求，为每个 SLI 设定目标阈值（如可用性 99.9%、P99 延迟 200ms），留出余量；3）用错误预算驱动决策——错误预算 = 1 - SLO，用其消耗速率决定发布节奏、扩容时机与优先级；4）建立监控与告警——用 SLI 监控、SLO 达标判断、错误预算消耗告警；5）持续迭代——依据实际数据与业务变化调整 SLO。从无到有关键是"先可度量（SLI），再定目标（SLO），最后用预算做决策（错误预算）"，形成可观测、可治理的可靠性闭环。

SLO 引入必须"先 SLI 后 SLO 再错误预算"，因为 SLO 需要 SLI 度量，错误预算需要 SLO 定义。逐步建立让可靠性从"口号"变为"可量化治理"。

• SLO 与成本的关系
• 错误预算分配反映的投入意愿
• 可靠性投入的经济性

SLO 与成本的关系：越高的 SLO（如 99.99% vs 99.9%）需要越多的冗余、监控、测试与运维投入，成本越高。错误预算分配反映投入意愿：1）业务对"可接受的不可用时间"（错误预算）的容忍度，决定了 SLO 严格度与对应投入；2）若业务愿意为高可靠性投入（多集群、多机房、全链路监控），则设更高 SLO；若业务更看重成本/迭代速度，则设较低 SLO（更多错误预算）换取发布灵活；3）错误预算本质是"业务用钱的投入换取可靠性，用可接受的风险换取成本"。SLO 设定要权衡"可靠性收益 vs 成本投入"，避免过度投资（99.99% 的成本远超 99.9% 但收益有限）。错误预算分配是"可靠性与成本"的显式取舍。

SLO 越高成本越高，错误预算分配是"用多少成本换多少可靠性"的决策。合理的 SLO 反映业务愿意为可靠性投入的真实意愿，是经济性权衡。

• 可用性与宕机预算的换算
• 99.9% 与 99.99% 的差异
• 目标设定的合理性评估

换算：年度宕机预算 = 365 × 24 × 60 × (1 - 可用性) 分钟。99.9% 可用性对应年度宕机约 8.76 小时（525.6 分钟）；99.99% 对应约 52.6 分钟（0.526 小时）；99.999% 对应约 5.26 分钟。可见每多一个 9，宕机时间减少一个数量级，但付出的冗余/容灾成本大幅增加。评估合理性：1）对比历史实际表现——目标是否在历史可达范围内，避免"拍脑袋"定高目标；2）评估成本——达成 99.99% 需要跨可用区/多活、全链路监控、自动化故障恢复，投入是否可持续；3）业务必要性——业务是否真的需要如此高的可用性（如对支付/交易系统，高可用必要；对日志分析，可放宽）；4）渐进式——从 99.9% 起步，达成后再逐步提升。合理性 = 历史可达 × 成本可承受 × 业务必要。

可用性换算揭示"每 9 的代价"。评估目标合理性须结合历史数据、成本投入与业务必要性，避免设定不切实际的高可用目标。