容灾概述：什么是容灾、为什么需要容灾、容灾的等级标准
大家好，我是你们的老朋友。今天咱们正式开讲《高可用容灾架构实战手册》的第一章——容灾概述。
说实话，我做了十几年运维，见过太多“系统挂了、数据丢了、老板疯了”的场面。每次复盘，大家都会问同一个问题：“当初为什么没做容灾？”
嗯，今天我们就来把这个问题彻底聊透。
什么是容灾？
容灾，说白了就是“给系统买保险”。
你想想看，你的业务跑得好好的，突然机房断电了、光纤被挖断了、甚至整个数据中心被洪水淹了——这时候怎么办？
容灾就是提前准备好一套备用环境。主站点挂了，备用站点能立刻顶上。用户几乎感觉不到异常。
我习惯把容灾分成两个层面：
- 数据容灾：保证数据不丢。比如数据库的异地备份、实时同步。
- 业务容灾：保证服务不停。比如在另一个城市部署一套完整的应用集群。
我在项目中遇到过一家金融客户，他们觉得“每天备份一次就够了”。结果某天凌晨主库硬盘坏了，恢复数据花了6个小时。那6个小时里，用户无法交易，投诉电话打爆了客服。后来他们找到我，第一句话就是：“早知道当初听你的，做个异地容灾。”
核心观点：容灾不是“万一出事”才用的，而是“出事是必然，只是时间问题”。
为什么需要容灾？
这个问题我问过很多团队。答案五花八门，但总结下来就三点：
- 天灾人祸躲不过：地震、火灾、挖断光缆、黑客攻击……这些事每天都在发生。你不是运气差，是概率问题。
- 业务连续性要求：现在的用户可没耐心等你恢复。系统宕机5分钟，用户可能就跑到竞争对手那里去了。
- 合规与监管：金融、医疗、政务等行业，监管明确要求必须做容灾。不做？罚到你怀疑人生。
我记得有一次帮一家电商公司做容灾评估。他们的CTO说：“我们业务量不大，没必要搞那么复杂。”结果双十一当天，流量暴涨，数据库扛不住挂了。恢复用了40分钟，损失了上千万的订单。后来CTO自己跟我说：“容灾不是成本，是投资。”
我的建议：别等到出事了才后悔。容灾的投入，相比业务中断的损失，九牛一毛。
容灾的等级标准（SHARE 78 / Tier标准）
说到容灾等级，业内最经典的就是SHARE 78标准。它把容灾分成了7个等级，从Tier 0到Tier 6。
我习惯用一张图来展示这个体系：
这张图很直观。等级越高，数据越安全，但成本也越高。你想想看，从Tier 0的“啥也不做”到Tier 6的“零数据丢失”，中间差了十万八千里。
具体每个等级的含义，我整理了一张表：
| 等级 | 名称 | 说明 | 典型场景 |
|---|---|---|---|
| Tier 0 | 无备份 | 没有任何数据保护措施 | 测试环境、个人项目 |
| Tier 1 | 磁带备份 | 定期将数据备份到磁带，异地存放 | 传统企业归档 |
| Tier 2 | 备份+异地存储 | 备份数据定期传输到异地 | 中小型企业 |
| Tier 3 | 电子链接 | 通过专线或网络实时传输数据 | 金融、电商 |
| Tier 4 | 快照+实时复制 | 使用快照技术，数据实时复制到异地 | 银行核心系统 |
| Tier 5 | 双站点+数据一致性 | 两个数据中心同时运行，数据强一致 | 大型互联网公司 |
| Tier 6 | 零数据丢失 | 任何故障下数据完全不丢失 | 证券交易、军事系统 |
注意：等级越高，成本呈指数级增长。别盲目追求Tier 6，适合自己业务场景的才是最好的。
RPO与RTO核心指标
聊容灾，绕不开两个核心指标：RPO 和 RTO。
我习惯这样理解：
- RPO（Recovery Point Objective）：你能容忍丢多少数据？比如RPO=1小时，意味着最多丢1小时的数据。
- RTO（Recovery Time Objective）：你能容忍停多久？比如RTO=30分钟，意味着系统必须在30分钟内恢复。
举个例子你就明白了。假设你的数据库每10分钟备份一次。如果主库在9:05挂了，恢复后数据只能回到9:00的状态。那5分钟的数据就丢了。这就是RPO=10分钟。
至于RTO，我见过最夸张的是某支付公司，要求RTO=0。说白了就是“一秒都不能停”。他们怎么做？双活架构，两个数据中心同时提供服务。一个挂了，另一个无缝接管。
关键公式：RPO决定你丢多少数据，RTO决定你停多久。两者越小，成本越高。
我在项目中遇到过一家创业公司，他们一开始把RPO设为24小时。结果某次故障丢了半天数据，用户数据全乱了。后来他们咬着牙把RPO改成了5分钟，成本翻了一倍，但再也没出过数据丢失的问题。
嗯，这里要注意：RPO和RTO不是拍脑袋定的。你需要根据业务重要性、预算、技术能力综合评估。我习惯先问业务方三个问题：
- 系统挂了，你能忍多久？
- 数据丢了，你能忍多少？
- 你愿意花多少钱来避免这些？
答案出来了，RPO和RTO也就清晰了。
我的经验：别把RPO和RTO定得太死。留点余量，比如业务说能忍1小时，你按45分钟设计。这样即使出点小意外，也能兜住。
好了，第一章的内容就到这里。容灾不是技术问题，而是意识问题。你想想看，系统不出事是运气，出了事能扛住才是本事。
下一章我们聊聊具体的容灾架构模式，比如主备、双活、多活。到时候见。
公众号:蓝海资料掘金营，微信deep3321