容灾：企业灾备避坑指南

作者：张思远

系统挂了三天，老板却在关心另一台机器

上个月周五晚上十一点，我手机响了。一看是运维群里炸了锅——生产库主节点宕机，整个订单系统瘫痪。

当时我在烧烤摊上，签子还没放下。远程连上去一看，磁盘阵列两块盘同时报错，RAID5直接降级。折腾到凌晨三点，数据恢复了一半，剩下的只能等周一厂商上门。

老板凌晨六点发来一条语音，我以为是问恢复进度。点开一听，他说的是：“小张，咱们那台容灾机器，能不能先顶上？”

我愣住了。那台“容灾机器”是去年年底上的，当时老板觉得花钱买了个寂寞。现在出了事，第一个想起来的就是它。

容灾到底是个啥？

通俗点说，容灾就是给你的业务系统准备一个“备胎”——不对，比备胎高级多了。备胎只是让你能回家，容灾是让你在回家的路上还能正常接单、发货、收款。

正经的定义是：容灾（Disaster Recovery）指通过建立异地的数据备份和业务接管系统，在灾难发生时，确保业务能在可接受的时间内恢复运行。

注意两个关键词：异地和接管。

异地意味着物理隔离，你机房着火了、被水淹了、甚至整栋楼没了，你的业务还能在别的地方活着。接管意味着自动或半自动地顶上去，不需要你深更半夜跑到机房去插U盘。

容灾解决什么问题？

说白了，就一个问题：你的业务能停多久？

我见过太多企业，数据备份做得挺好，每天半夜定时备份，磁带、硬盘都规规矩矩。但真出了事才发现，备份≠容灾。备份只是让你有数据可以恢复，容灾是让你在最短时间内恢复业务。

举个例子。之前有个客户，做跨境电商的，数据量不小。他们的备份策略是每天凌晨2点全量备份，备份文件传到对象存储上。看起来挺完善对吧？

结果有一天，中午12点数据库主库的存储控制器挂了。他们按预案恢复，先要找到最近一次备份——是凌晨2点的，也就是数据最多丢10个小时。但这10个小时的订单、支付流水、客户信息，全没了。财务对不上账，客户投诉电话打爆，最后赔了十几万了事。

最关键的是，恢复过程花了6个小时。因为要把备份数据从对象存储拉回来，再恢复到新机器上，再启动应用，再验证数据一致性。6个小时，对于一个日订单量上万的平台来说，损失可想而知。

如果当时有容灾系统，RPO（数据恢复点目标）可以做到分钟级甚至秒级，RTO（业务恢复时间目标）可以压到半小时以内。也就是说，数据最多丢一分钟，业务最多停半小时。

我踩过的坑，希望你避开

坑一：容灾≠备份。备份解决的是“数据丢了怎么找回来”，容灾解决的是“业务停了怎么继续跑”。两者需要，但完全不是一回事。很多企业把备份当容灾用，出了事才发现远水救不了近火。

坑二：容灾方案不是买了就完事。我见过有企业花了大几十万上了容灾系统，但从来没演练过。等真出了事，发现切换脚本有bug、网络策略没配好、甚至容灾端的服务器密码都换了没人知道。结果容灾系统变成了摆设，该停多久还是停多久。

之前有个客户，上了某家的容灾一体机，平时也没太在意。结果一次机房断电（就只是断电，不是啥大灾难），要切换到容灾端，发现生产端和容灾端的数据同步早就断了，断了一个多月没人发现。原因就是同步链路的网络策略被防火墙升级时误改了，但监控告警没配好，没人收到通知。

坑三：容灾不是IT部门的事。容灾的最终目标是业务连续，所以业务部门必须参与RTO/RPO的制定。你IT说半小时恢复，业务部门说不行，我们最多只能停五分钟，那你就得重新设计架构。反过来也一样，业务部门觉得停一天没事，你非要上实时同步，那就是浪费钱。

具体建议

第一，先做业务影响分析。把系统按重要性分三级：核心交易类、重要支撑类、一般辅助类。核心系统要求RTO≤30分钟、RPO≤5分钟；重要系统RTO≤2小时、RPO≤15分钟；一般系统能一天内恢复就行。别一刀切，成本差很多。

第二，容灾演练至少每季度一次。不是走个过场，是真正把生产流量切到容灾端跑一小时，看看能不能扛住。我见过不少企业，演练时用的是模拟数据，结果真出事了发现真实流量比模拟流量大好几倍，容灾端直接被打挂。

第三，监控容灾链路。数据同步的延迟、中断、异常，一定要有告警。很多容灾系统平时看着正常，其实同步早就断了。定期检查同步状态，比什么都重要。

关于方案选择

说实话，容灾方案的选型挺复杂的。要考虑数据量大小、业务重要性、预算、团队技术能力。大厂有大厂的方案，中小企业有中小企业的玩法。关键是要匹配自己的实际情况，别盲目追求高大上。

我之前帮一家中型制造企业做过容灾规划，他们预算有限，最后用了数据库实时复制+异地备份的组合方案，RPO做到分钟级，RTO在两小时以内，成本控制在预算范围内。核心思路就是：不追求最完美的方案，追求最适合的方案。

话说回来，容灾这事，最怕的就是“临时抱佛脚”。系统没出事的时候，老板觉得这是浪费钱；真出了事，又嫌你恢复太慢。所以提前把方案做好、把流程跑通、把团队练熟，比什么都重要。

我自己的经验是，容灾方案定了之后，一定要让老板签字确认RTO/RPO指标。这样真出了事，大家按指标说话，不会扯皮。我之前就吃过这个亏，方案里写的RTO是2小时，结果真出事了老板说“我理解的是一小时”，最后责任全在我。

最后说一句，容灾这事儿，投入产出比不太好算，但你可以这么想：一次大的宕机事故，损失可能是容灾系统投入的十倍百倍。这个账，算得过来。

对了，我之前用过一套叫热备云的方案做异地容灾，整体用下来还算省心，切换演练也比较顺畅。不过具体选什么，还是要根据你自己的情况来定。