"高可用"的谎言：你的 99.99% 是怎么算出来的

"几个 9" 大概是高可用领域最有传播力的概念了。把它列成表：

数字看起来很精确，对吧？5.26 分钟、26.30 秒——精确到让人产生一种"这是经过严格计算的工程指标"的错觉。

但这些数字的来源，只是一个简单的除法。

可用性的基础公式：

\[ A = \frac{MTTF}{MTTF + MTTR} \]

当多个组件 串联 时（任一故障导致系统故障），系统可用性：

\[ A_{串联} = A_1 \times A_2 \times \cdots \times A_n \]

这意味着串联越多，越脆弱。一个由 10 个 99.9% 的组件串联的系统，整体可用性只有 \( 0.999^{10} \approx 99.0\% \)。

当多个组件 并联冗余 时（所有副本都故障才算系统故障），通常的计算是：

\[ A_{并联} = 1 - (1 - A)^n \]

两个 99.9% 的组件做主备冗余，理论上可以达到 \( 1 - 0.001^2 = 99.9999\% \)。

在高可用和数据库冗余实践中，我们用 MTTF 和 MTTR 推导过：双副本冗余让有效 MTTF 提升约 4000 倍。数学上无可挑剔。

但这里有一个关键假设，教科书往往一笔带过：

所有故障必须是统计独立的。

即：组件 A 发生故障的概率，不影响组件 B 发生故障的概率。

\( P(F_A \cap F_B) = P(F_A) \cdot P(F_B) \)

这个条件在真实世界几乎从不成立。

接下来的两个章节，我们会看到这个假设是如何崩塌的。

我们选取三家主流云厂商的计算实例（虚拟机）SLA 条款进行对比：

假设一个系统在一年中发生了 3 次故障，分别是：

• 1 月：停机 4 小时
• 6 月：停机 2 小时
• 11 月：停机 3 小时

如果按 年度 计算： \[ A_{年} = 1 - \frac{4 + 2 + 3}{365 \times 24} = 1 - \frac{9}{8760} \approx 99.897\% \]

指不到三个 9，看起来挺糟的。

但如果按 月度 计算——有 9 个月可用性是 100%（没有故障），剩下 3 个月分别是：

• 1 月：\( 1 - \frac{4}{744} \approx 99.46\% \)
• 6 月：\( 1 - \frac{2}{720} \approx 99.72\% \)
• 11 月：\( 1 - \frac{3}{720} \approx 99.58\% \)

如果 SLA 条款是"任意月度可用性不低于 99.9%"，那只有这 3 个月触发赔偿。如果条款是"年度平均可用性"，那 9 个月的 100% 会 稀释 故障的影响。

同一组故障事件，在不同 SLA 规则下的结论：

           年度计算      月度计算（最差月）  月度计算（平均月）
           ─────────     ─────────────       ────────────────
可用性     99.897%       99.46%              99.925%
是否达标   ✗ (< 99.9%)  ✗ (< 99.9%)         ✓ (> 99.9%)

合同条款往往倾向于采用对供应商更有利的计算窗口和聚合方式。 这里不是说所有厂商都这样计算，而是想说明：一旦计算窗口、故障定义、免责条款被写进合同，"几个 9"的含义就已经发生了变化。

SLA 中最关键的概念是"不可用"（unavailability），但它远不是"服务挂了" 那么简单。

常见的不算"不可用"的情况：

1. 性能降级 ：响应时间从 50ms 升到 5s，但请求还是返回了——不算停机
2. 部分不可用 ：10 个可用区中 1 个挂了——可能不算（取决于条款如何定义"影响区域"）
3. 间歇性故障 ：每分钟有 5% 的请求失败——可能不算（如果阈值定义为"连续 1 分钟失败率超过 50%"）

一个极端但合规的例子：系统 99% 的时间完美运行，剩下 1% 的时间响应延迟增加 100 倍、错误率 10%——但因为"还有响应"且"错误率未超过阈值"，SLA 考核显示可用性 100%。

这就是为什么：

SLA 中的 "99.99%" 描述的不是你的用户体验，而是 SLA 条款定义的可用性。

两者之间可以有巨大的鸿沟。

几乎所有云厂商的 SLA 都包含大量排除条款。以下是典型的不算入停机时间的情况：

• 计划内维护 ：提前通知的升级窗口
• 用户自身原因 ：配置错误、超出配额、账户欠费
• 不可抗力 ：自然灾害、政策变更、网络运营商故障
• 第三方原因 ：DNS 服务商故障、CDN 供应商问题
• 安全事件 ：DDoS 攻击导致的服务降级

问题是：很多重大故障的根本原因 可以被归类到排除条款中 。DNS 配置错误是"网络问题"还是"平台故障"？上游供应商组件的 bug 是"第三方原因"还是"平台选型责任"？

这些灰色地带给了厂商大量的解释空间。

*关联故障*（Correlated Failure），也叫 *共模故障*（Common Mode Failure），是指多个"独立"组件由于共享某些基础设施或条件，而在同一时间段内发生故障。

分类：

关联故障的来源
├── 物理层关联
│   ├── 同一机架：共享电源、交换机、散热
│   ├── 同一机房：共享电力、网络出口、冷却系统
│   └── 同一区域：自然灾害、电网故障
│
├── 软件层关联
│   ├── 相同 OS 版本：同一个内核 bug 影响所有节点
│   ├── 相同依赖库：CVE 暴露所有使用该库的服务
│   └── 相同配置：一次错误推送干掉所有实例
│
├── 人为关联
│   ├── 运维操作：同一个人对所有节点执行了相同的错误命令
│   ├── 部署发布：新版本 bug 同时上线到所有副本
│   └── 配置变更：全量推送（而非灰度）
│
└── 时间/负载关联
    ├── 流量高峰：所有节点同时接近过载
    ├── 定时任务：cron job 同时触发 → 瞬间资源争抢
    └── 级联依赖：上游慢了 → 所有下游同时超时

在独立假设下，两个副本同时故障的概率是：

\[ P(F_1 \cap F_2) = P(F_1) \cdot P(F_2) \]

但如果引入关联性，我们需要用 条件概率 来建模。定义故障关联系数 \( \rho \)，表示一个副本故障时另一个副本也故障的条件概率超出独立预期的程度：

\[ P(F_1 \cap F_2) = P(F_1) \cdot P(F_2) + \rho \cdot P(F_1) \cdot (1 - P(F_1)) \]

其中 \( \rho = 0 \) 退化为独立情况，\( \rho = 1 \) 表示完全关联（一个挂了另一个 100% 也挂）。

对于 n 个副本的并联系统，引入关联系数后（使用简化的对称关联模型）：

\[ A_{关联并联} \approx 1 - \left[ (1-A)^n + \rho \cdot (1-A) \cdot (1 - (1-A)^n) \right] \]

当 \( \rho \) 较小时可近似为：

\[ A_{关联并联} \approx 1 - (1-A)^n - \rho \cdot (1-A) \]

这个公式的关键含义是：*当 \(\rho > 0\) 时，系统不可用概率有一个下限，约等于 \(\rho \cdot (1-A)\)，与副本数 n 几乎无关。*

换句话说：再加多少个副本，只要存在关联故障可能性，增益就会撞上天花板。

假设单节点可用性 99.9%（三个 9），3 个副本并联：

冗余的有效性上限取决于关联度，而不是副本数量。

如果你的 3 个副本共享机房电源、运行相同 OS 版本、由同一个人运维，那么 "3 副本冗余"在关联故障面前可能只比单机好一点点。

级联故障的核心机制：一个组件故障 → 其负载被转移到其他组件 → 其他组件因额外负载而过载 → 继续转移 → 连锁崩溃。

级联故障时间线

t=0   [A] 故障               [B] [C] [D] 正常，各 60% 负载
        ↓ A 的负载被转移
t=1   [A] 故障               [B] 80%  [C] 80%  [D] 80%
                                ↓ B 开始变慢，响应超时增加
t=2   [A] 故障  [B] 过载      [C] 90%  [D] 90%
                    ↓ B 的请求转移到 C 和 D
t=3   [A] 故障  [B] 故障      [C] 过载  [D] 过载
                                ↓ 全部崩溃
t=4   [A] [B] [C] [D] 全部不可用
        ↓
      总停机时间 >> 单节点故障的停机时间

在服务系统中，延迟和吞吐的关系不是线性的。根据 M/M/1 排队模型，平均等待时间：

\[ W = \frac{1}{\mu - \lambda} \]

其中 \( \mu \) 是服务速率，\( \lambda \) 是到达速率。利用率 \( \rho_{util} = \frac{\lambda}{\mu} \)。

当利用率接近 1 时，等待时间趋向无穷大：

这就是为什么当一个节点故障、其负载被分摊到其他节点时，系统不是"稍微变慢"而是"指数级恶化"。

假设 4 个节点各承担 70% 负载（看起来很安全）。一个节点故障后，剩余 3 个节点每个需要承担 \( \frac{4 \times 70\%}{3} \approx 93.3\% \) 的负载。延迟从 1.67x 跳到 7.5x——这就是级联崩溃的触发点。

传统思维："加更多节点，提高冗余，这样单节点故障的影响就更小了。"

但是：

• 更多节点 = 单节点故障转移到每个剩余节点的增量更小 ✓
• 更多节点 = 发生至少一个故障的概率更高 ✗
• 更多节点 = 更复杂的依赖关系，更多潜在的级联路径 ✗

如果单节点故障率为 p，n 个节点中至少一个故障的概率为： \[ P_{至少一个故障} = 1 - (1-p)^n \]

当节点数达到 100 时，几乎 10% 的时间里你的集群中都有至少一个节点在故障状态。如果你的系统不能优雅处理这种情况，级联崩溃就只是时间问题。

回到可用性公式：

\[ A = \frac{MTTF}{MTTF + MTTR} \]

假设当前 MTTF = 10,000 小时，MTTR = 1 小时，则 A = 99.99%。

现在考虑两种投资方向：

投资 A：MTTF 翻倍 \[ A_{new} = \frac{20000}{20000 + 1} = 99.995\% \] 提升了 0.005 个百分点。

投资 B：MTTR 减半 \[ A_{new} = \frac{10000}{10000 + 0.5} = 99.995\% \]

效果相同！但考虑到：

• MTTF 翻倍需要大幅提升硬件质量或增加冗余（成本指数增长）
• MTTR 减半通常只需要更好的监控、自动化和演练（成本线性增长）

在大多数互联网服务场景下，MTTR 优化通常更划算。

更重要的是，MTTR 的优化不依赖"故障独立"这个幻觉。无论故障是独立的还是关联的，快速恢复都能减少影响。

Google SRE 团队提出了 Error Budget（错误预算）的概念，这是一个比"追求更多的 9"更务实的框架。

核心理念：

100% 可用性是错误的目标。如果你的系统 真的 做到 100%，说明你在可靠性上过度投资了——这些资源本可以用于创新。

具体操作：

1. 根据业务需求设定 SLO（服务等级目标），比如 99.95%
2. 计算错误预算：一个月有 \( 30 \times 24 \times 60 = 43200 \) 分钟， 99.95% 的错误预算是 21.6 分钟
3. 只要错误预算没用完，团队可以大胆发布新功能
4. 如果错误预算接近耗尽，暂停功能发布，专注稳定性

这个框架把"可用性"从一个空洞的数字变成了一个 可操作的资源分配工具 。

Netflix 的 Chaos Monkey 是混沌工程的先驱：在生产环境中随机杀死服务实例，强迫工程师构建真正能容错的系统。

核心价值：

• 在故障 真正发生 之前，找到系统的弱点
• 验证监控和告警系统是否真的有效
• 训练团队的应急响应能力
• 发现那些隐藏的关联故障模式

"你不是在测试系统能不能扛住故障，你是在测试你的 团队 能不能扛住故障。"

与其追求单点的极致可用性，不如在多个层次构建防御：

这些层级的设计可以参考 CAP 定理再审视 一文中关于 PACELC 模型的分析——在非分区状态下，延迟和一致性的权衡同样影响你的可用性策略。