容灾切换：企业灾备避坑指南

作者：钱萌萌

容灾切换：一场演练，把运维逼到崩溃边缘

上周跟一个老同事吃饭，他刚跳槽到一家互联网金融公司做运维总监。聊起前阵子的容灾演练，他苦笑着说：“差点把头发都薅光了。”

事情是这样的。他们公司在郊区机房搭了一套灾备环境，硬件、网络、数据同步全都弄好了，合同也签了，年检也过了。结果真刀真枪演练的时候，才发现一个致命问题——切换手册写得不够细。

“切换手册写了二十多页，可真正操作时，光DNS那一块就卡了四十分钟。后来发现，核心交易系统有个IP地址写死在配置文件里，压根没走域名解析。”

他说的这个场景，我太熟悉了。

容灾切换到底是个啥？

先别急着上概念。咱们打个比方。

容灾切换，说白了就是“主战场出了问题，副战场顶上”的过程。就像你上班常走的那条路堵死了，你得绕道走另一条路，但前提是你早就知道那条备选路怎么走、路上有几个红绿灯、哪段容易出状况。

放在IT系统里，这个过程分两层：

第一层是技术层的切换。 存储、数据库、应用服务、网络路由，都要从生产中心切到灾备中心。这一层靠的是技术工具和自动化脚本。

第二层是业务层的接管。 系统切过去了，业务能不能跑起来？数据全不全？用户能不能正常访问？这一层考验的是流程和组织协调能力。

很多公司把精力全砸在第一层，第二层基本靠“到时候再说”。结果就是——系统切过去了，业务起不来，或者起来了，数据丢了一大截。

真实场景：那场让人崩溃的演练

再回到我那位老同事的案例。

他们公司做的是小额贷款业务，核心系统有几十个微服务，数据落在MySQL里，每天增量数据大概几十个G。灾备中心用的是同城双活架构，数据通过半同步复制实时同步过去。

演练那天，他们模拟的是机房整体断电场景。按理说，这个场景应该是最简单的——不用考虑网络分区、脑裂这些复杂情况，直接切换就行。

但实际操作时，问题一个接一个冒出来：

数据同步延迟居然有十几秒。半同步复制在正常情况下延迟不到一秒，但那天的业务高峰期，有几个大事务执行时间特别长，导致备库延迟一直没追上。演练时一切过去，发现最后那十几秒的交易数据根本没同步过来。

这个发现让全场安静了好几秒。大家心里都清楚，如果是真实灾难场景，这十几秒意味着什么——那可不是丢几笔交易记录的问题，是可能涉及资金损失和法律纠纷的。

后来复盘时发现，问题出在监控告警上。他们只监控了数据库主从同步的线程状态，没监控延迟秒数，导致延迟十几秒了，值班人员完全无感。

一个关键误区：把演练当演戏

说实话，我见过太多公司把容灾演练搞成了“走过场”。提前通知、挑业务低峰期、所有相关人原地待命、演练脚本反复预演……结果就是演练永远能通过，但真出事了照样抓瞎。

之前有个客户，做制造业ERP的，每年都搞两次容灾演练，回回都“顺利通过”。但有一次真出了故障——机房空调漏水导致电力系统跳闸，他们紧急启动容灾切换，结果花了三个多小时才把业务恢复。

为什么？因为演练时，他们永远是在“计划内”的状态下操作。所有系统都是健康的，所有数据都是一致的，所有人员都是准备好的。

但真实灾难不会给你这些条件。它可能发生在凌晨三点，可能在你刚好升级了某个组件之后，可能在你刚调整了网络架构还没来得及更新文档的时候。

避坑提醒一： 演练一定要加“意外变量”。比如故意不通知核心人员、随机挑一个业务高峰时段、在演练前悄悄改一下网络配置。让演练尽可能接近真实战场。

切换这件事，最怕的是“半自动”

现在很多厂商都在推“一键切换”，听起来很美，但实际落地时，你会发现真正的瓶颈往往不在技术，而在人和流程。

我遇到过最典型的场景：系统切换脚本跑完了，应用也起来了，但业务部门打电话过来说“交易查询慢得没法用”。查了半天，发现是灾备中心的数据库参数没调优，生产环境的缓冲池是64G，灾备环境只配了16G。

这种问题，脚本是发现不了的，只能靠人来判断。

避坑提醒二： 容灾切换不只是技术活，一定要让业务部门参与验证。切换完成不等于万事大吉，要有一套完整的业务验证清单——核心交易能不能做、报表能不能出、对外接口通不通。每项都要打勾确认。

说说我自己踩过的坑

前几年，我给一家政企客户做过一次容灾项目。当时选的是同城双活方案，数据同步用的是存储层复制。方案评审时，一切都显得很完美——RPO接近零，RTO控制在十分钟以内。

结果第一次真实切换时，发现一个大问题：存储复制只做到了LUN级别，但数据库服务器上挂载的文件系统，在灾备端挂载时居然出了文件系统不一致的错误。折腾了半天，最后是靠人工修复文件系统才把数据库拉起来的。

后来我才想明白，问题出在当初做架构设计时，只关注了数据同步层面，没考虑到主机层面文件系统的一致性检查。这个坑，一开始确实没想到。

所以现在我做容灾方案，一定会问三个问题：

客户的核心链路里，有没有写死的IP地址？数据库的同步机制，到底是复制日志还是复制存储块？灾备端的主机配置和生产端差多少？

这三个问题，任何一个没搞清楚，切换时都可能翻车。

最后说点实在的

容灾切换这件事，说难也难，说简单也简单。难在细节，简单在思路——把每一次演练都当成真实灾难来对待，把每一个不确定因素都提前搞清楚。

之前用过一套叫热备云的数据保护方案，里面带了容灾编排的功能，能把切换流程固化下来，减少人工操作带来的不确定性。但工具只是辅助，真正决定成败的，还是你对系统细节的掌握程度。

如果你所在的公司正在做容灾建设，或者正准备搞第一次真实切换演练，我的建议是：别急着追求高大上的技术方案，先把自己系统的家底摸清楚。数据流怎么走的、依赖关系是什么、有哪些隐藏的坑——这些搞清楚，比什么都强。

毕竟，容灾切换不是为了应付检查，而是为了在真正的灾难来临时，你能从容应对。