3. 可用性度量与容灾目标

在物联网平台的高可用与容灾工程中，最容易被忽视、却最容易引发争议的问题不是“要不要做容灾”，而是“做到什么程度才算达标”。如果团队对“可用”没有统一的量化语言，运维说系统很稳、业务说经常掉线、管理层说投入太大，三方永远无法对齐。本节围绕七个核心指标展开：SLI、SLO、SLA 构成服务等级的目标体系，MTBF、MTTR 描述可靠性与可恢复性，RTO、RPO 定义容灾的时间边界。理解它们的定义、计算方式，并能在物联网场景中合理设定，是后续架构设计与演练验收的前提。

一、SLI、SLO、SLA：从测量到承诺的三层结构

SLI（Service Level Indicator，服务等级指标）是对服务质量的实际测量值，是一个可采集、可计算的数字。它回答“现在到底怎么样”。物联网平台的 SLI 通常包括：设备接入成功率、消息端到端时延 P99、规则引擎处理成功率、API 请求成功率、设备在线率、数据写入持久化成功率等。SLI 必须来自真实观测数据，例如用“成功响应数 / 总请求数”计算 API 成功率。

SLO（Service Level Objective，服务等级目标）是团队为 SLI 设定的内部目标值，回答“我们希望达到多少”。例如“设备接入成功率 ≥ 99.9%（月度）”“消息 P99 时延 ≤ 500ms”。SLO 是工程团队自我约束的标尺，通常比对外承诺更严格，留出缓冲。

SLA（Service Level Agreement，服务等级协议）是与客户或业务方签订的正式承诺，回答“我们对外保证什么、违约如何赔偿”。SLA 一般包含指标定义、统计周期、达标阈值、排除条款（如计划维护、不可抗力）和赔偿方式。SLA 的阈值通常低于或等于 SLO，因为对外承诺需要留有余量。

三者的关系可以概括为：SLI 是“体温计”，SLO 是“健康目标”，SLA 是“对客户的保证书”。没有 SLI 的 SLO 是空话，没有 SLO 缓冲的 SLA 是风险。

二、MTBF 与 MTTR：可靠性与可恢复性的两个维度

MTBF（Mean Time Between Failures，平均故障间隔时间）衡量系统两次故障之间的平均运行时长，反映“多久坏一次”。计算方式为：MTBF = 总运行时间 / 故障次数。例如某物联网接入集群在 720 小时内发生 3 次故障，则 MTBF = 720 / 3 = 240 小时。MTBF 越大，系统越可靠。

MTTR（Mean Time To Repair/Recovery，平均修复时间）衡量从故障发生到恢复服务的平均耗时，反映“坏了多久能好”。计算方式为：MTTR = 总修复时间 / 故障次数。例如上述 3 次故障分别耗时 0.5h、1h、1.5h，则 MTTR = 3 / 3 = 1 小时。MTTR 越小，恢复能力越强。

两者结合可估算稳态可用性：可用性 ≈ MTBF / (MTBF + MTTR)。上例中可用性 ≈ 240 / 241 ≈ 99.585%。这说明：想提升可用性，既可以延长 MTBF（减少故障），也可以缩短 MTTR（快速恢复）。对物联网平台而言，缩短 MTTR 往往比追求零故障更现实。

三、RTO 与 RPO：容灾的时间边界

RTO（Recovery Time Objective，恢复时间目标）指灾难发生后，业务允许中断的最长时间，即“多久必须恢复”。例如 RTO = 30 分钟，意味着从灾难确认到服务恢复不能超过 30 分钟。

RPO（Recovery Point Objective，恢复点目标）指灾难发生时允许丢失的数据时间窗口，即“最多丢多少数据”。例如 RPO = 5 分钟，意味着恢复后数据最多回退到灾难前 5 分钟的状态。

RTO 决定容灾切换的速度要求，RPO 决定数据复制的方式。RPO 越小，越需要同步复制或高频异步复制，成本和时延越高。物联网平台中，设备上报的时序数据、告警数据、计费数据对 RPO 的要求往往不同，需要分级设定。

四、物联网平台中的指标设定方法

指标设定不能拍脑袋，需要结合业务影响、成本约束和技术可行性。以下给出一个可参考的设定流程与示例参数。

第一步：按业务链路分级。物联网平台通常包含设备接入、消息路由、规则计算、数据存储、API 服务等链路。不同链路的可用性要求不同。例如设备接入和消息路由是核心链路，中断会直接导致设备离线；而报表查询等非实时链路可以容忍更长中断。

第二步：为每条链路定义 SLI。以设备接入链路为例，SLI 可定义为“单位时间内成功建立连接的设备数 / 尝试连接的设备数”。以消息链路为例，SLI 可定义为“端到端成功投递的消息数 / 总消息数”。

第三步：设定 SLO 与 SLA。参考行业惯例，核心链路 SLO 可设为 99.95%，SLA 对外承诺 99.9%；非核心链路 SLO 99.9%，SLA 99.5%。注意 SLO 要留出比 SLA 更小的误差空间，避免对外违约。

第四步：推导 MTBF/MTTR 目标。若要求可用性 99.95%，按每月 30 天（720 小时）计算，允许不可用时间约 21.6 分钟。若 MTTR 控制在 5 分钟，则 MTBF 需满足：0.9995 = MTBF / (MTBF + 5/60)，解得 MTBF ≈ 1666 小时，即约 69 天发生一次故障。这为故障演练和冗余设计提供了量化依据。

第五步：设定 RTO/RPO。核心接入链路 RTO 建议 ≤ 5 分钟，RPO ≤ 1 分钟；数据存储链路 RTO ≤ 30 分钟，RPO ≤ 5 分钟；历史分析链路 RTO ≤ 4 小时，RPO ≤ 1 小时。RPO 越小，越需要采用同步复制或半同步复制；RTO 越小，越需要热备或双活架构。

五、计算示例与结果判读

假设某物联网平台接入集群在一个 720 小时的统计周期内，共发生 4 次故障，每次修复时间分别为 3、5、4、8 分钟。计算如下：

总修复时间 = 3 + 5 + 4 + 8 = 20 分钟 = 0.333 小时
MTTR = 0.333 / 4 ≈ 0.0833 小时 ≈ 5 分钟
MTBF = 720 / 4 = 180 小时
可用性 ≈ 180 / (180 + 0.0833) ≈ 99.954%

若 SLO 要求 99.95%，则当前结果刚好达标，但余量很小。若某次故障修复耗时 30 分钟，MTTR 将升至约 10.5 分钟，可用性降至约 99.91%，低于 SLO。此时应优先优化故障发现与切换自动化，而不是单纯增加冗余节点。

对于 RTO/RPO 的验证，不能只看架构图，必须通过真实演练测量。例如模拟主可用区故障，记录从故障注入到服务恢复的实际时间，与 RTO 对比；同时检查恢复后的数据时间戳，确认丢失窗口是否在 RPO 之内。只有演练数据才能证明容灾目标是否真正达成。

六、常见误区

• 把 SLA 当 SLO 用：对外承诺 99.9%，内部也按 99.9% 管理，一旦波动就直接违约。正确做法是内部 SLO 高于 SLA。
• 只算 MTBF 不算 MTTR：故障少但恢复慢，可用性依然不达标。物联网平台设备量大，快速恢复往往比零故障更关键。
• RPO 设为零：要求任何数据都不丢，成本极高且未必必要。应按数据等级区分，例如计费数据 RPO 接近零，而调试日志可以容忍小时级丢失。
• 指标没有统计口径：“可用性 99.9%”必须明确统计周期、排除条件、采样方式，否则无法验收。

掌握这七个指标的定义、计算与设定方法后，后续的冗余架构、多活部署、备份策略和故障演练才有明确的量化目标。指标不是纸面数字，而是架构决策和资源投入的依据。