云联信息：容灾演练，别等真出事才第一次跑

2026-11-05 1次浏览

很多公司有容灾方案，文档写得完整，但从没实际演练过。真出事时才发现，切换脚本跑不通、备份恢复要八小时、联系方式早就过期。容灾能力和文档厚度没有关系，只和演练次数有关。

先定恢复目标

多久必须恢复、能接受丢多少数据，这两个数字决定架构投入。业务方说不清这两个数，容灾方案就只能凭技术拍脑袋，做完也不对路。

假设主库整台机器没了、整个可用区不可用，看流程能不能走通。只演单机故障，遇到区域级问题还是会傻眼，而区域故障恰恰是最需要预案的场景。

演练时安排一个没参与设计的人，照着文档操作。写文档的人自己操作，会不自觉地补上文档里缺的步骤，问题永远暴露不出来。

记录从发现故障到业务恢复的总时长，拆分成发现、决策、操作、验证四段。哪一段最长，就是下一步要优化的地方。

切换之后，抽查几笔业务数据，看主从数据是否一致、有没有丢单。只看服务起没起，不看数据对不对，等于只演练了一半。

切到备用环境跑两天，再切回来。回切往往比切换更容易出问题，因为备用环境的数据要往回同步，方向一变，很多细节都不一样。

每次演练后更新预案：改掉的步骤、补充的联系人、修正的命令。预案不更新，第二次演练还会踩同样的坑。

半年一次能保证人员变动后仍有人熟悉流程。一年一次太稀疏，中间换了人，预案基本等于重新学。

周末凌晨或者节假日做演练，对业务影响最小。如果只能在工作日做，提前告知客服和业务方，准备好话术，避免用户咨询时没人能解释。

容灾不只是切换服务，还包括能不能从备份恢复数据。切换成功了但数据恢复不了，等于业务停了。演练时把数据恢复单独作为一项，计时、验证、记录。

负责容灾的工程师离职，预案就要重新过一遍，让接手的人照着走一遍。很多预案失效，不是因为技术变了，而是因为没人知道文档放在哪里。

提前一天通知业务负责人、客服主管和值班工程师，说明演练时间、影响范围、回滚方式。有人不知情，看到告警就手动重启，演练结果全被搅乱。

有负责人、有时间表、有结论、有后续动作。走形式的演练，第二年还是同样的问题，钱花了能力没长。

容灾能力是练出来的，不是写出来的。云联信息【资深云服务专家微信：cloud7591】通常建议客户第一次演练就按最坏情况来，允许失败，把失败的地方一条条补上，第二次就会顺畅得多。