一、容灾概述：什么是容灾、为什么需要容灾、容灾的等级标准（SHARE 78）、RTO与RPO核心指标
大家好，我是这次课程的主讲人。在正式开始之前，我想先聊聊我自己的一个经历。
几年前，我负责的一个电商平台，在双十一大促前夕，核心数据库所在的机房因为空调故障导致温度飙升，最终触发了硬件保护机制——整个集群直接宕机。你想想看，几千万的流量瞬间归零，业务方电话打爆了我的手机。那次事故持续了整整4个小时，直接经济损失我就不说了，更惨的是用户信任度的崩塌。
从那以后，我深刻明白了一个道理：容灾不是可选项，而是必选项。今天这一章，我们就来聊聊容灾的那些事儿。
什么是容灾？
容灾，说白了就是当灾难发生时，系统还能继续提供服务。这里的「灾难」范围很广——可能是机房断电、光缆被挖断、服务器硬盘损坏，也可能是人为误操作、恶意攻击，甚至是地震、洪水这种自然灾害。
我个人习惯把容灾理解为「给系统买一份保险」。你平时可能觉得它没用，但真出事的时候，它能救命。
容灾 ≠ 备份
很多人容易混淆这两个概念。备份是把数据复制一份存起来，而容灾是让整个系统在灾难后能快速恢复运行。备份是容灾的一部分，但容灾还包括了网络切换、应用重启、流量调度等一系列动作。
为什么需要容灾？
这个问题我问过不少刚入行的朋友，他们的第一反应往往是：「我们系统很稳定啊，不会出事的。」
嗯，我以前也这么想。直到我在项目中遇到过几次「不可能发生」的事故：
- 某次机房升级，施工队不小心把主备两个机房的电源线一起剪断了
- 还有一次，运维同学执行脚本时手滑，把生产库的表结构给删了
- 更离谱的是，某云厂商的区域性故障，导致我们整个集群不可用
你看，这些都不是小概率事件。在微服务架构下，服务数量动辄上百个，任何一个环节出问题，都可能引发雪崩效应。容灾的核心目的就三个：
- 保证数据不丢——这是底线
- 保证业务不停——这是目标
- 保证快速恢复——这是能力
我的建议：不要等到出事了再考虑容灾。在系统设计阶段就把容灾方案纳入架构，成本最低，效果最好。我曾经见过一个项目，上线两年后才开始补容灾，改得那叫一个痛苦。
容灾的等级标准：SHARE 78
说到容灾等级，业界有个经典标准叫 SHARE 78。这是1978年由SHARE组织（一个大型机用户团体）提出的，虽然年代久远，但至今仍是容灾设计的参考框架。
SHARE 78 把容灾分为7个等级，从低到高依次是：
| 等级 | 名称 | 描述 | 典型场景 |
|---|---|---|---|
| Tier 0 | 无容灾 | 没有任何备份和恢复计划 | 个人开发环境 |
| Tier 1 | 冷备份 | 数据定期备份到磁带或磁盘，恢复时需要手动操作 | 小型企业非核心系统 |
| Tier 2 | 热备份 | 数据实时备份到异地，但应用需要手动启动 | 中型企业核心数据库 |
| Tier 3 | 电子链接 | 数据通过专线实时同步，应用可快速切换 | 金融行业交易系统 |
| Tier 4 | 活动备用站点 | 备用站点持续运行，可随时接管业务 | 大型电商平台 |
| Tier 5 | 双向镜像 | 两个站点同时提供服务，数据双向同步 | 银行核心系统 |
| Tier 6 | 零数据丢失 | 多站点实时同步，任何故障数据零丢失 | 证券交易系统 |
你可能会问：「那我该选哪个等级？」
我的回答是：看业务需求，别盲目追求高等级。Tier 6 虽然好，但成本也是Tier 1的几十倍。我见过一些公司，明明是个内部OA系统，非要搞两地三中心，结果运维成本高得离谱，最后反而因为太复杂出了更多故障。
避坑指南：我曾经帮一个客户做容灾评估，他们花了300万买了高端存储做双活，结果发现业务对RTO的要求其实只有4小时。说白了，用冷备份+自动化脚本就能搞定，成本不到30万。所以，先搞清楚需求，再选方案。
RTO与RPO：容灾的两个核心指标
聊容灾，绕不开两个关键指标：RTO 和 RPO。这两个词你肯定听过，但真正理解它们的人不多。
RTO（Recovery Time Objective）—— 恢复时间目标
RTO 指的是从灾难发生到系统恢复运行所允许的最大时间。说白了就是：你能容忍系统停多久？
- 对于搜索引擎，RTO可能是几分钟
- 对于银行核心系统，RTO可能是秒级
- 对于内部报表系统，RTO可能是几小时
我习惯把RTO理解为「业务忍耐极限」。超过这个时间，业务就受不了了。
RPO（Recovery Point Objective）—— 恢复点目标
RPO 指的是灾难发生时，允许丢失多少数据。说白了就是：你能容忍丢多少数据？
- RPO=0：数据零丢失，任何操作都不能丢
- RPO=1小时：最多丢失1小时的数据
- RPO=1天：每天备份一次，最多丢一天的数据
记住这个公式：
RTO 决定你的恢复成本（越短越贵）
RPO 决定你的备份成本（越短越贵）
两者共同决定了你的容灾方案
RTO 和 RPO 的关系
这两个指标不是独立的，它们相互影响。举个例子：
如果你要求 RPO=0（数据不丢），那你就得做实时同步，成本自然高。但如果你能接受 RPO=1小时，那每小时做一次增量备份就行，成本低很多。
同样，RTO 越短，意味着你需要更快的切换机制，比如自动故障转移、预热的备用节点等，这些都需要投入资源。
我的经验：在制定容灾方案时，我通常会先和业务方确认两个数字：
- 「系统最多能停多久？」—— 这就是 RTO
- 「最多能丢多少数据？」—— 这就是 RPO
然后根据这两个数字倒推技术方案。千万别反过来，先选技术再定指标，那样很容易过度设计。
小结
这一章我们聊了容灾的基本概念。总结一下：
- 容灾是让系统在灾难后能快速恢复，不是简单的备份
- SHARE 78 提供了7个容灾等级，从Tier 0到Tier 6，等级越高成本越高
- RTO 是恢复时间目标，RPO 是恢复点目标，两者是容灾设计的核心输入
下一章，我会结合实际案例，讲讲如何根据 RTO 和 RPO 来设计具体的容灾方案。到时候我会分享一个我亲手操盘过的两地三中心项目，里面有不少坑，值得你留意。
嗯，今天就到这里。记住一句话：容灾不是成本，是投资。你永远不知道灾难什么时候来，但你可以决定灾难来了之后怎么办。