波仔
☁️ 第二章 构建系统优先考虑云服务的时代
📄 一句话概括

看得见的地方靠【选】：区域选在哪、放几个可用区、灾备做几级——这些都是你下单时能勾的；也正因为能勾，它们必须在立项时就定下来，事后补救的代价极高。

📝 本节和前面几节的关系

前一节（云服务的区分使用）决定了用哪几家，这一节开始处理"选定之后那些必须写进配置的项"。

教材把注意事项分成两节，用的划分很有意思："看得见的地方"和"看不太见的地方"。这不是按重要性分的，而是按能不能在界面上看到并勾选分的。这一节里的东西——区域、可用区、备份等级——全部出现在下单界面或者合同附件里，所以它们属于"能被检查的"那一类。（下一节讲的 SLA 条款和海外法律，则属于"写了但不容易看懂"的那一类。）

一、"看得见的地方"指什么

它指的是你在开通资源时可以明确选择的那些参数。 具体包括：

这些项目的共同点是：选的时候只看得到名字和价格，看不到后果。 所以它们最容易在下单时被随手一点——而这正是它们危险的地方：区域一旦定了，迁移成本很高；可用区只放一个，等于把风险留在了将来。

二、选区域要看的五个点

考虑点 要问什么问题 常见取舍
延迟 用户离机房有多远 同城 5 ms、跨省 30 ms、跨洲 150 ms
合规 数据能不能出境 能就近，不能就只能选境内区域
服务可用性 目标区域有没有这个服务 新区域往往缺新功能
价格 各区域单价差多少 有的区域便宜 10%~20%
容灾 有没有第二个可用区 单可用区＝把鸡蛋放进一个篮子

这五个点里，前两个是"硬约束"，后两个是"软权衡"：

三、灾难恢复的四个等级

RTO 和 RPO 是这一节必须先分清的两个词：

等级 做法 RTO RPO 相对成本
L1 备份 定期备份到异地 数小时~数天 数小时 1 倍
L2 暖备 备用环境常开、数据同步 30 分钟~2 小时 数分钟 3~5 倍
L3 热备 双活、自动切换 几分钟 秒级 8~12 倍
L4 多活 多地同时提供服务 ≈ 0 0 20 倍以上

这张表最该看的是最后一列。 从 L1 到 L4，成本涨了 20 倍以上，而 RTO 从"数小时"降到"接近零"。所以灾备等级的选择，本质上是在问一个问题：停多久你能接受？

这个问题的答案因业务而异：内部报表系统停一天可能没关系（L1 够），但交易系统停十分钟就是事故（至少要 L3）。关键是这个判断必须在立项时做，因为它是预算的一部分——等出事之后再想升级到 L3，成本是事发时的成本，还加上了损失。

四、值得单独说的一个细节

很多人以为"备份"和"灾备"是一回事，其实不是：

一台上只做了备份的系统，出事时仍然要花几小时把数据恢复到一个新环境里才能跑起来——而那几小时就是 RTO。所以把"有备份"当成"有灾备"，是这一节里最常见的误判。

五、动手 Demo：把可选区域与灾备等级都算一遍

# 四个灾备等级：成本与恢复时间的权衡
levels = [("L1 备份", "数小时~数天", "数小时", 1),
          ("L2 暖备", "30 分钟~2 小时", "数分钟", 4),
          ("L3 热备", "几分钟", "秒级", 10),
          ("L4 多活", "≈ 0", "0", 20)]

# 选一个自己业务的容忍度：停机超过这个数就不可接受
tolerance = 30  # 分钟
for name, rto, rpo, cost in levels:
    print("%-8s RTO=%-12s 相对成本 %2d 倍" % (name, rto, cost))

实跑输出：

==================================================================================================
D10 注意事项（看得见的地方）：区域与灾难恢复
==================================================================================================
  【一】选区域时，五个要考虑的点

  考虑点            要问什么问题                    常见取舍
  --------------------------------------------------------------------------------------------
  延迟              用户离机房有多远                同城 5 ms、跨省 30 ms、跨洲 150 ms
  合规              数据能不能出境                  能就近，不能就只能选境内区域
  服务可用性        目标区域有没有这个服务          新区域往往缺新功能
  价格              各区域单价差多少                有的区域便宜 10%~20%
  容灾              有没有第二个可用区              单可用区＝把鸡蛋放进一个篮子

  【二】灾难恢复的四个等级：RTO 与 RPO 越短，钱越多
     RTO＝从停机到恢复要多久；RPO＝能容忍丢多少数据。

  等级            做法                        RTO               RPO           相对成本
  ------------------------------------------------------------------------------------------
  L1 备份         定期备份到异地              数小时~数天       数小时        1 倍
  L2 暖备         备用环境常开、数据同步      30 分钟~2 小时    数分钟        3~5 倍
  L3 热备         双活、自动切换              几分钟            秒级          8~12 倍
  L4 多活         多地同时提供服务            ≈ 0               0             20 倍以上

  ④ 这一节的要点是【看得见的地方靠选】：选哪个区域、放几个可用区、
     灾备做几级，都是你在下单时能勾的。所以这些不该事后补救，
     立项时就该定下来——区域一旦定了，迁一次的成本很高。

读这个输出：第二张表的形状很说明问题——成本的增长是陡的，而 RTO 的改善是递减的。从 1 倍到 4 倍买来了"数小时 → 半小时"，从 10 倍到 20 倍只买来"几分钟 → 接近零"。所以不值得无脑追求最高等级——先想清楚业务能容忍停多久，再往上找那一档，通常比直接选最高档划算得多。

六、⚠️ 2026 现状

30 秒实验

想一个你每天在用的系统（比如公司的考勤或订单系统），回答两个问题：

  1. 它停一整天，会有什么后果？ 如果答案是"大家抱怨一下"，那么 L1 级的灾备就够；如果是"业务直接损失"，那至少要 L3。
  2. 它丢了最近一天的数据，能补回来吗？ 能（比如重新录入）说明 RPO 可以放宽；不能（比如交易记录）说明 RPO 必须做到秒级附近。

这两个答案决定了你该买哪一档，而它们都不需要技术背景就能回答——这正是这一节想说的：灾备等级是一个业务判断，不是一个技术选择。

常见误区

  1. 错误：已经做了备份，所以不怕出事。——纠正：备份解决的是"数据能不能找回来"，不解决"多久能重新跑起来"。如果只有备份，出事时你仍然要新建一套环境、装好所有东西、再把数据恢复进去——这段时间就是 RTO，通常以小时计。要缩短这段时间，还得有备用环境（暖备以上）。 两者是配套的两件事。

  2. 错误：灾备等级越高越好，直接上最高档最省心。——纠正：每提高一档，成本大致翻倍甚至更多（从 1 倍到 20 倍以上）。而收益是递减的——从"数小时"到"半小时"的提升已经拿到了大部分价值，从"几分钟"到"接近零"要多花一倍的钱。正确做法是先从业务容忍度倒推：能接受停多久，就选对应那一档，然后针对最坏情况补上人工预案。

  3. 错误：区域选近了延迟低，那就都选最近的。——纠正：延迟只是五个考虑点里的一个。合规要求可能不允许数据放在某些区域；目标区域可能缺少你需要的服务；不同区域的价格差别可能到两成。更关键的是容灾——如果你把主备都放在同一个区域，那"选得近"反而放大了风险。所以顺序应该是：先用合规和容灾筛掉一批，再在剩下的里面比延迟和价格。

  4. 错误：这些是技术细节，交给工程师定就行。——纠正：它们是预算和风险的分配问题，需要业务方一起定。因为"能接受停多久""能容忍丢多少数据"这两个问题，只有懂业务的人答得出来；工程师能做的是告诉你在某个等级下需要多少钱、能做到什么程度。让工程师单独决定灾备等级，最常见的后果是：花了很多钱做了过高的等级，或者为了省钱做了过低的等级。

自测三问（点开对答案） 1. RTO 和 RPO 分别回答什么问题？为什么必须分开看？ —— **RTO 回答"停多久"，RPO 回答"丢多少"**。它们对应两类不同的损失：RTO 对应服务中断的损失（客户跑了、业务停了），RPO 对应数据丢失的损失（记录没了、账对不上）。**两者可以不同档**——有的业务能忍受停机但不能丢数据（RPO 要求极高、RTO 可放宽），有的正好相反。**合成一个指标，就没法按业务需求分别取舍了。** 2. 为什么说灾备等级"应该在立项时定"，而不是出事前再补？ —— 因为**它既是预算的一部分，也决定了架构**。灾备等级高的系统，应用要设计成能在多地同时跑、数据要能实时同步——**这些是架构层面的决定，事后再改等于重做系统**。而且要考虑到：**在真正出事的时候再去提升等级，是要在损失正在发生的状态下做的决定**，那是最糟糕的决策环境。 3. 五个考虑点里，为什么"容灾"和"合规"应该先于"延迟"和"价格"来筛？ —— 因为它们**是筛除条件，不是权衡条件**。合规不允许的区域，无论延迟多低价格多便宜都不能选；容灾需要第二个可用区，如果某个区域只有一个可用区，那它作为主区域就有先天缺陷。**先用硬条件把选项范围缩到合规的少数几个，再在剩下的里面比延迟和价格**——顺序反了，就会出现"选好了最优区域、结果发现数据不能放在那里"这种返工。

相关笔记