4. 可靠性指标：MTBF、MTTR 那些事儿
聊可靠性验证，绕不开几个核心数字。MTBF、MTTR、可用性…… 这些指标就像管道的“体检报告单”，一眼就能看出这条管道靠不靠谱。我个人习惯是，拿到一个新项目，先不看架构图，先问这几个指标的目标值是多少。目标值定了，后面的验证工作才知道往哪儿使劲。
4.1 核心指标拆解
咱们一个一个来看。别着急，每个指标我都给你讲透。
4.1.1 MTBF——平均无故障时间
全称是 Mean Time Between Failures。说白了，就是系统平均能“扛”多久不出毛病。这个值越大，说明管道越皮实。
计算公式很简单：
MTBF = 总运行时间 / 故障次数举个例子：
一条管道跑了 10000 小时，中间出了 5 次故障。那它的 MTBF 就是 2000 小时。意味着平均每 2000 小时，你可能会遇到一次故障。
我在项目中遇到过一件事。有次客户要求 MTBF 达到 5000 小时，我们按理论模型计算完全达标，结果一跑实测数据，只有 3000 小时。后来排查发现，是某个第三方库的异常处理太粗糙，把临时错误也算成了故障。这让我明白一个道理：MTBF 的高低，很大程度取决于你对“故障”的定义。
4.1.2 MTTR——平均修复时间
全称是 Mean Time To Repair。它衡量的是“出事了，多久能修好”。这个值越小，说明系统的自愈能力越强，或者运维团队的响应越快。
MTTR = 总修复时间 / 故障次数还是刚才那条管道，10000 小时里出了 5 次故障，每次修复分别花了 30 分钟、20 分钟、40 分钟、10 分钟和 50 分钟。那 MTTR 就是 (30+20+40+10+50) / 5 = 30 分钟。
嗯，这里要注意：MTTR 不光是修硬件，也包括软件重启、流量切换、甚至回滚操作。你想想看，如果每次故障都要人工登录服务器找日志，那 MTTR 肯定高得吓人。
4.1.3 可用性——Availability
这个指标是 MTBF 和 MTTR 的组合拳。它反映了系统“能正常干活”的时间比例。
可用性 = MTBF / (MTBF + MTTR)算一下刚才的例子：MTBF=2000小时，MTTR=0.5小时（30分钟换算），那可用性就是 2000 / 2000.5 ≈ 0.99975，也就是 99.975%。
业界常说的“几个9”，指的就是这个。99.9% 是三个9，99.99% 是四个9。每多一个9，意味着每年停机时间要减少一个数量级。
| 可用性 | 年停机时间 | 典型场景 |
|---|---|---|
| 99% | 87.6小时 | 内部测试系统 |
| 99.9% | 8.76小时 | 普通在线服务 |
| 99.99% | 52.6分钟 | 金融交易系统 |
| 99.999% | 5.26分钟 | 电信核心网 |
从表格里你能看出来，从 99.99% 到 99.999% ，虽然只差一个9，但允许的停机时间从近一小时压缩到了五分钟。这对架构设计的要求完全是两个世界。
4.2 指标之间的关系
这三个指标不是孤立的。我经常把它们画成一张图来看：
- MTBF 决定了系统“稳不稳”。
- MTTR 决定了系统“恢复快不快”。
- 可用性 是两者权衡后的最终结果。
你想想看，如果 MTBF 很高但 MTTR 也很高，比如一年才坏一次，但一次修三天，那可用性依然很难看。反过来，MTBF 一般但 MTTR 极低，比如每天都出小毛病，但每次几秒就自愈了，那可用性也可能很漂亮。
4.3 计算一个完整案例
咱们用一个真实场景串一下。假设有一条数据处理管道，我记录了它一个月的运行数据：
- 总运行时间：720小时（30天）
- 故障次数：4次
- 每次故障的修复时长：15分钟、25分钟、10分钟、30分钟
第一步：算 MTBF
MTBF = 720 / 4 = 180小时第二步：算 MTTR
MTTR = (15 + 25 + 10 + 30) / 4 = 20分钟
注意单位：20分钟 = 0.333小时第三步：算可用性
可用性 = 180 / (180 + 0.333) ≈ 0.99815
换算成百分比就是 99.815%这个结果意味着，这条管道每年大概有 16 小时左右的不可用时间。对于一般业务来说可以接受，但如果客户要四个9，那就需要继续优化了。
4.4 选择哪个指标作为验证目标？
这个没有标准答案，完全看业务场景。
- 关键任务型管道（比如支付、交易）：优先压 MTBF，保证系统尽量不坏。
- 容错能力强的管道（比如日志采集）：可以适当放宽 MTBF，但必须死磕 MTTR，确保故障自愈够快。
- 面向客户的 API 管道：直接拿可用性说事，因为 SLA 合同里写的都是几个九。
我个人习惯是，在项目初期先定一个可用性目标，然后倒推出 MTBF 和 MTTR 的预算值。比如目标四个九，那 MTTR 就不能超过几分钟，再根据这个去设计故障恢复策略。
下面这张图，是我在验证方案里常用的一张框架图，帮你把这几个指标的关系理清楚。
4.5 给验证方案的建议
讲完理论，咱们落回验证方案本身。我建议你在写方案时，至少包含下面几块内容：
- 明确指标目标： 比如 MTBF≥2000小时，MTTR≤30分钟，可用性≥99.99%。
- 定义故障口径： 哪些算故障，哪些不算，必须在方案里写清楚。避免后期扯皮。
- 设计压测场景： 长时间运行压测测 MTBF，混沌工程测 MTTR。
- 数据收集方法： 用日志、监控系统、告警平台自动统计，别靠人工记。
- 验收标准： 连续运行 X 小时无故障，或注入故障后 Y 分钟内自动恢复。