一、先定一个数：一年允许停多久

做容错之前要先定目标，而这个目标通常用【几个 9】来表示：

• 99%（两个 9）——一年约 3.65 天
• 99.9%（三个 9）——一年约 8.77 小时
• 99.99%（四个 9）——一年约 52.6 分钟
• 99.999%（五个 9）——一年约 5.26 分钟

为什么业界常把 99.9% 和 99.99% 当成分水岭？因为跨过这一档，架构要整个换一代：

• 单机冗余——一台服务器，电源、硬盘、风扇做冗余，对应三个 9。
• 传统集群——两台节点加共享存储，故障自动切换，对应四个 9。
• 持续可用——集群再加异地，容错做到部件级，对应五个 9。

每个 9 的成本是跳着涨的：从单机到双机再到双机加异地， 设备数量和管理复杂度都翻倍。所以先定数，再倒推架构，不要反过来。

二、还有一个指标比 9 更实用

光有可用性百分比还不够，实际运维里更常被问的是另外两个指标：

• RTO（恢复时间目标）——从故障发生到系统恢复，最长能接受多久。
• RPO（恢复点目标）——故障发生时，最多能接受丢多少数据。

这两个指标比【几个 9】更能指导采购，因为它直接对应到钱：

• RTO 很短（比如 30 秒），就需要自动切换，也就是热备或集群。
• RPO 接近零，就需要同步复制，代价是交易延迟会变高。
• RTO 几个小时、RPO 一天也可以，那就用冷备加定时备份，便宜得多。

一个常见的设定组合是：可用性 99.9%、RPO 5 分钟、RTO 10 分钟；另一个是 99.99%、RPO 为 0、RTO 30 秒。 后者贵得多，但对核心交易是必要的。

三、值不值得，看停机一小时赔多少钱

容错的投入该花多少，取决于停机的代价。业界的常用口径：

• 业务关键系统停机一小时的损失平均超过 30 万美元。
• 大型企业里有 18% 的比例，一小时停机损失超过 500 万美元。
• 89% 的组织要求关键系统做到四个 9；其中 35% 还想做到五个 9。

这就是为什么容错的账能算得过来。 比如从三个 9 提到四个 9，一年的停机时间从 8.77 小时压到 52.6 分钟， 省下约 8 小时；按每小时 30 万美元算，一年就是 240 多万美元。 只要双机的投入低于这个数，这笔账就是划算的。

反过来，如果一套内部报表系统挂了也就是同事抱怨两句， 那么给它做五个 9 就是纯粹的浪费。 容错从来不是【越可靠越好】，而是【刚好够用】。

四、几种备法：从冷到热到双活

按【备机醒着的程度】，常见的做法可以排成一个梯度：

• 冷备——备机平时关机，出事了人工开机。RTO 以小时到天计， 数据损失看备份间隔。成本最低，适合个人博客、测试环境、非核心业务。
• 温备——系统装好、服务部署好，备机待机但不接流量， 数据准实时同步。RTO 通常 10 到 30 分钟，RPO 在 5 分钟以内。 适合中小企业的 OA、进销存。
• 热备——备机实时同步、随时可接管。RTO 能控制在 5 秒到 1 分钟， RPO 趋近于零。技术栈通常是共享存储、DRBD 加 Pacemaker、 数据库主从复制，或虚拟化层的 HA 集群。
• 双活——两台同时对外服务，互为备份，切换几乎无感。 资源利用率最高，但架构复杂度也最高。

容错系统和热备份的区别值得点出来： 容错是【整机做冗余，部件坏一个它自己顶上去】，用户完全无感； 热备份是【两台机器互为备份】，切换要靠心跳检测和一套切换脚本， 会有一段短暂中断，而且切换脚本本身可能跑不通。

温备这一档还有一个容易被忽略的操作要求：备机要定期做切换演练。 有说法是超过半数的企业从未真正演练过主备切换， 真出故障时才发现脚本跑不通或密码过期——这时候所谓的备用方案等于不存在。

五、动手 Demo：把可用性折算成停机分钟数

【几个 9】听起来抽象，折算成时间就直观了：

mins = 365 * 24 * 60
for nines, name in ((99, "两个9"), (99.9, "三个9"), (99.99, "四个9"), (99.999, "五个9")):
    down = mins * (1 - nines / 100)
    print("  %s：一年停 %.1f 分钟" % (name, down))
print("  三个9到四个9，一年少停 %.0f 分钟 = %.1f 小时" % (8.77 * 60 - 52.6, 8.77 - 52.6 / 60))
print("  按每小时 30 万美元算，省下约 %.0f 万美元" % ((8.77 - 52.6 / 60) * 30))

实跑输出：

--------------------------------------------------------------------
坏多久算正常，得先定下来
--------------------------------------------------------------------
  应对故障的第一步不是买设备，而是先定一个数：一年允许停多久。
  这个数常用几个 9 来表示，每多一个 9，成本都是跳着涨的。

  可用性      俗称      每年允许停机
  -----------------------------------
  99%         两个9     约 3.65 天
  99.9%       三个9     约 8.77 小时
  99.99%      四个9     约 52.6 分钟
  99.999%     五个9     约 5.26 分钟
  -----------------------------------

  为什么 99.9% 到 99.99% 是个分水岭？因为架构要整个换一代：

  等级         架构做法                           对应停机
  -------------------------------------------------------------
  单机冗余     一台服务器，电源和硬盘做冗余       99.9% 一档
  传统集群     两台节点共享存储，故障自动切换     99.99% 一档
  持续可用     集群加异地，容错做到部件级         99.999% 一档
  -------------------------------------------------------------

  值不值得，取决于停机一小时赔多少钱。业界常用的口径：

  口径                                     数值
  ------------------------------------------------------------
  业务关键系统停机一小时的成本             平均超过 30 万美元
  大型企业里超过 500 万美元/小时的比例     18%
  认为关键系统需要四个9的组织              89%
  其中还想做到五个9的                      35%
  ------------------------------------------------------------

  接下来是怎么备。按备机【醒着】的程度，常见五档：

  方式     备机状态                     切换时间          数据损失
  -----------------------------------------------------------------------
  冷备     关机，需要时人工开机         小时到天          大，看备份间隔
  温备     系统装好，数据准实时同步     10 到 30 分钟     5 分钟以内
  热备     实时同步，随时可接管         5 秒到 1 分钟     接近零
  双活     两台同时对外服务             几乎无感          零
  -----------------------------------------------------------------------

  容错系统和热备份的区别在这里：容错是整机做冗余，部件坏一个它自己顶上去；
  热备份是两台机器互为备份，切换要靠心跳检测和一套切换脚本，会短暂中断。

  小算例：99.9% 一年能停 8.77 小时，99.99% 只能停 52.6 分钟，
  差了 10 倍。按每小时 30 万美元算，这 10 倍对应的是每年约 245 万美元的差别。
  所以先问业务能容忍多久，再倒推该买哪一档，别反过来。

第一段循环把四个 9 全部折算成分钟，一眼就能看出每档之间的量级差。 最后两行是这一节的落点：每提高一个 9，省下的钱是可以算出来的。 这个数字就是你能为容错方案出的预算上限。 算不出这个数，就没法判断该买哪一档。

30 秒实验

1. 算一下你单位最核心的那套系统，停机一小时大概损失多少钱。
2. 问一句：我们上一次做故障切换演练是什么时候？答案往往是【没有做过】。
3. 看一下你电脑的电源和硬盘有没有冗余——那是最朴素的容错。

常见误区

1. 错误：容错就是备份，做了备份就不用做冗余。——纠正：两件事解决不同问题——容错管【部件坏了机器还能跑】，备份管【数据没了能找回来】，都不能省。
2. 错误：可用性越高越好，直接上五个 9。——纠正：每多一个 9 成本翻倍；正确做法是先算停机一小时的代价，再倒推该做到哪一档。
3. 错误：热备有备机就一定能切换成功。——纠正：切换要靠心跳检测和切换脚本，脚本本身可能跑不通；超过半数的企业从未演练过切换。

• ☐ 下一节（9-10 关于备份的思考：暖备份、备份服务）

相关笔记

• 服务器的性能管理 —— 上一节解决慢，这一节解决坏
• 关于备份的思考 —— 容错之后还差最后一道防线
• 故障应对与备份（容错、RAID、UPS） —— 容错在硬件层怎么做（RAID、UPS）
• 服务器的规格与形态（冗余、外形、标准、档次） —— 冗余最初是硬件概念
• 大量服务器的故障排除 —— 云上几千台机器怎么处理故障
• 🕸️ Web技术原理 · 索引