3. 恢复能力目标与韧性指标设计
恢复能力目标不是一句“系统要能快速恢复”的口号，而是一组可以被测量、被分解、被验证的量化承诺。本节要解决的核心问题是：如何把业务对中断的容忍度，翻译成 SLO/SLA 中的恢复目标，再通过韧性度量体系、KPI 与 KRI，把目标逐层分解到系统和团队，使每个团队都知道自己该守住哪条线。
一、从业务容忍度到恢复目标：RTO 与 RPO 是两条不同的轴
恢复目标设计首先要区分两条轴：RTO（Recovery Time Objective，恢复时间目标）回答“中断后多久必须恢复服务”，是时间轴；RPO（Recovery Point Objective，恢复点目标）回答“最多允许丢失多长时间的数据”，是数据轴。二者不能互相替代：一个系统可能 RTO 只有 5 分钟，但 RPO 允许 15 分钟，因为它是可重放的日志类服务；另一个系统 RPO 接近 0，但 RTO 允许 30 分钟，因为它是批量对账系统。
把业务容忍度翻译成 RTO/RPO 时，建议按业务影响分级，而不是按系统重要性拍脑袋。例如某电商平台按订单损失速率分级：
| 业务等级 | 典型场景 | RTO | RPO | 可用性 SLO |
|---|---|---|---|---|
| L1 核心交易 | 下单、支付 | ≤ 5 分钟 | ≤ 10 秒 | 99.99% |
| L2 重要支撑 | 库存查询、优惠券 | ≤ 30 分钟 | ≤ 5 分钟 | 99.95% |
| L3 一般业务 | 评价、推荐 | ≤ 4 小时 | ≤ 1 小时 | 99.9% |
| L4 内部工具 | 运营后台报表 | ≤ 24 小时 | ≤ 24 小时 | 99.5% |
表中数值为教学示例，实际取值需结合业务损失模型、合规要求和成本约束确定。关键原则是：RTO/RPO 必须由业务方签字确认，而不是由运维单方面设定，否则恢复目标会与业务预期脱节。
二、SLO/SLA 与恢复目标对齐
SLA 是对外承诺，通常带有赔偿条款；SLO 是内部目标，一般比 SLA 更严格，留出缓冲。恢复目标要与二者对齐，需要把“可用性”拆成可观测的指标。常见的可用性 SLO 表达式为：
可用性 = 成功请求数 / 总请求数 ≥ 99.95%（按 5 分钟窗口滚动计算）
错误预算 = 1 - SLO = 0.05%，即每月约 21.6 分钟不可用这里的“错误预算”是恢复目标与 SLO 对齐的关键桥梁：如果 L1 系统月错误预算只有 21.6 分钟，那么单次故障的 RTO 就不能设计成 30 分钟，否则一次故障就会耗尽整月预算。因此，恢复目标必须满足：
单次故障允许恢复时间 ≤ 错误预算 × 可接受故障次数
例如：21.6 分钟 / 每月允许 2 次重大故障 ≈ 单次 RTO ≤ 10 分钟对齐时还要注意 SLO 的统计口径：是按请求成功率、按时间可用性，还是按业务事务完成率。口径不同，恢复目标的验证方式也不同。建议在 SLO 文档中明确“测量点、窗口、排除项（如计划维护）”，避免恢复演练时各团队各算各的。
三、韧性度量体系：从结果指标到能力指标
韧性度量体系应覆盖“结果”和“能力”两个层面。结果指标回答“恢复得怎么样”，能力指标回答“为什么能恢复”。只盯结果指标，容易在故障后才发现能力缺失；只盯能力指标，又可能脱离业务影响。建议采用三层结构：
- 业务层：MTTR（平均恢复时间）、MTBF（平均故障间隔）、故障影响时长、受影响订单数。
- 技术层：RTO 达成率、RPO 达成率、切换成功率、数据校验通过率、备份可恢复率。
- 能力层：演练覆盖率、故障注入次数、预案更新及时率、依赖拓扑完整率、值班响应达标率。
其中，备份可恢复率常被忽视：备份成功不等于能恢复。建议每月抽取一定比例备份做真实恢复验证，记录“恢复耗时”和“数据一致性校验结果”，作为 RTO/RPO 达成率的直接证据。
四、KPI 与 KRI 设计：一个看结果，一个看风险
KPI 衡量恢复能力是否达标，KRI 衡量风险是否正在累积。二者应成对设计，避免“KPI 好看但风险已高”。例如：
| 类型 | 指标 | 目标/阈值 | 数据来源 |
|---|---|---|---|
| KPI | 核心系统 MTTR | ≤ 15 分钟 | 故障工单 + 监控时间线 |
| KPI | RTO 达成率 | ≥ 95% | 演练与真实故障记录 |
| KRI | 单点依赖数量 | ≤ 3 个/系统 | 依赖拓扑扫描 |
| KRI | 备份恢复验证失败次数 | 0 次/月 | 恢复验证报告 |
| KRI | 关键预案超期未更新 | 0 个/月 | 预案管理系统 |
KRI 需要设置“预警线”和“熔断线”。例如单点依赖数量超过 3 个触发预警，超过 5 个则冻结该系统的变更发布，直到完成冗余改造。这样 KRI 才真正具备治理约束力，而不是一张报表。
五、目标分解到系统与团队
目标分解不是把 RTO 平均分给每个团队，而是沿着“业务服务 → 应用系统 → 组件/依赖 → 团队”的链路逐层推导。分解时要回答三个问题：该团队负责的对象是什么？它影响哪个上层恢复目标？它自己的恢复目标是多少？
以一个 L1 订单服务为例，业务 RTO 为 5 分钟，分解过程如下：
- 订单服务整体 RTO ≤ 5 分钟，RPO ≤ 10 秒。
- 订单服务依赖支付网关、库存服务、消息队列。若支付网关不可用，订单可降级为“先下单后支付”，因此支付网关 RTO 可放宽到 15 分钟。
- 库存服务不可用会直接阻塞下单，因此库存服务 RTO ≤ 3 分钟，且必须支持多活切换。
- 消息队列承担订单事件投递，RPO ≤ 10 秒，要求跨可用区副本同步。
- 对应团队：订单团队负责服务自身恢复；库存团队负责多活切换；中间件团队负责消息队列副本与切换演练。
分解结果应写入“恢复目标责任矩阵”，每个目标都有唯一责任团队、验证方式和复核周期。团队级目标还要与值班、演练、变更冻结等机制挂钩，否则目标只是纸面数字。
六、落地要点与常见误区
第一，不要把 RTO 当成单一数字。同一系统在不同故障场景下 RTO 可能不同：单实例故障 1 分钟恢复，机房级故障 30 分钟恢复。建议按故障场景分别定义，并标注适用条件。
第二，SLO 与恢复目标要定期回归。业务量增长、架构演进、依赖变化都会让原有目标失效。建议每季度复核一次 RTO/RPO 与错误预算的匹配关系，尤其是新增单点依赖后。
第三，KRI 要能触发动作。如果 KRI 超标后没有任何治理动作，团队就会逐渐忽视它。可以把 KRI 与变更审批、发布冻结、架构评审挂钩，让风险指标真正影响工程决策。
第四，目标分解要避免“平均主义”。不是每个组件都分到同样的 RTO，而是按关键路径和依赖关系分配。关键路径上的组件目标更严，非关键路径可适当放宽，这样才能把有限的恢复资源用在最影响业务的地方。
最后，恢复目标与韧性指标设计完成后，应形成一份可执行的“恢复目标责任矩阵”，包含业务服务、系统、组件、责任团队、RTO/RPO、验证方式、复核周期和当前状态。这份矩阵既是治理依据，也是演练和复盘的输入，确保恢复能力建设始终围绕业务目标展开。