业务系统容灾不是买两台服务器就完事，而是围绕RTO/RPO目标，把备份、双活、切换演练三条线持续打磨的运营体系。平时不流汗，战时必流血,这是容灾准备最朴素的道理。
先搞清容灾要守的底线RTO和RPO
任何冗余设计都绕不开两个指标，RTO是系统从故障到恢复服务的时间，RPO是故障期间最多丢多少数据。多数业务系统把RTO控制在30分钟内，RPO控制在5分钟内，就能覆盖最常见的机房断电和服务器宕机场景，这两个数字直接决定你要花多少钱、上多复杂的架构。
| 容灾等级 | RTO目标 | RPO目标 | 典型投入 |
|---|---|---|---|
| 本地高可用 | 5-15分钟 | 0-5分钟 | 服务器双机+共享存储 |
| 同城双活 | 1分钟内 | 0 | 双机房专线互联+负载均衡 |
| 异地灾备 | 30分钟-2小时 | 15-30分钟 | 主备数据中心+数据同步 |
| 两地三中心 | 分钟级 | 秒级 | 双活+异地备份全都要 |
业内专家指出，金融和政务系统普遍要求同城双活加异地灾备，而大多数制造和零售企业做到本地高可用加异地备份就够用了，容灾目标定太高，运维成本会拖垮团队；定太低,故障来了又顶不住。
备份体系怎么搭才不白花钱
备份是容灾的地基，但统计显示相当一部分企业的备份从未做过恢复验证,真到恢复时才发现备份文件损坏或备份窗口太短根本没用。
异地灾备和同城双活有什么区别
这两个词常被混用，其实应对的故障完全不同。同城双活是两台设备同时对外提供服务，一个机房挂了另一个机房流量全接，切换时间按秒算，但救不了整个城市级别的灾难。 异地灾备是数据实时或准实时同步到几百公里外的机房，主中心彻底瘫痪时在异地拉起业务，能扛地震洪水，但RTO通常要半小时以上，生产环境建议优先做同城双活，成本可控且见效快；核心数据再定期同步到异地做冷备,两条腿走路才稳。
中小企业容灾方案价格大概多少
这是采购最爱问的问题。一套基础的容灾方案起步价在10万到30万元之间，包含两台服务器、一台存储设备、备份软件授权和一年的实施服务，若要做同城双活，需要再加一条专线、一套负载均衡和数据库集群改造，预算会到50万以上，云上方案更灵活，按量付费的云主机加对象存储做异地备份，一年几万块就能起步,适合预算有限但不想裸奔的公司。
备份体系建议按三层来搭：
- 本地备份：每天凌晨全量，每15分钟增量日志，保留7天版本
- 同城备份：数据同步到同城另一机房，用于机房级故障恢复
- 异地归档：核心数据每周打包传到异地对象存储，应对区域性灾难
数据库备份要定期演练恢复，恢复出来的数据要在测试环境跑一遍查询和业务校验，确认数据完整性和时间点正确，备份脚本要写清楚备份文件命名规则、保留周期、备份日志检查命令,顺手写个定时任务每天检查备份产物大小和日志状态。
演练这东西不能嘴上说说
多数团队有容灾预案，但没真正验证过。容灾演练的意义在于把文档变成肌肉记忆,真出故障时不用翻手册就能条件反射地操作。
业务系统容灾演练多久一次才靠谱
行业共识认为，核心系统每季度做一次小规模切换演练，每半年做一次全量容灾演练，每年至少做一次不通知的故障注入演练，演练不是把备份拉起来看一眼就完，要设计完整流程：模拟主库宕机、应用切换、流量回切、数据校验、问题复盘，每次演练都要记录切换耗时、数据差异、脚本报错点,这些问题才是演练真正的收获。
演练建议从低频开始：
- 第一次演练只切一台非核心应用，验证网络和脚本基本可用
- 第二次演练同时切换数据库和中间件，模拟真实故障场景
- 第三次演练需要业务部门参与，验证整个对外服务的连续性
- 之后每季度按场景轮换演练，覆盖不同故障类型
回切往往是演练里最容易翻车的环节，主库恢复后，要先把增量数据反向同步，再切回生产，顺序错了会造成数据覆盖。演练时一定要把回切步骤当作正式流程来走,回切失败比切换失败更常见。
顾好双活链路和云上冗余
很多系统平时跑得欢，一搞双活就出幺蛾子，根本原因在于数据库、缓存、消息队列、文件存储这些有状态组件没做分层冗余设计，数据库层用主从复制加自动故障转移，缓存层用集群模式多副本，消息队列做分区多副本，文件存储挂分布式存储，每个组件都要有自己的容灾方案,单独拎出来能扛故障。
云上的冗余配置比自建机房省心,但要注意几个关键点：
- 专有网络下至少创建两个可用区，云主机均衡部署在两个可用区
- 数据库开启跨可用区自动备份和秒级恢复能力
- 负载均衡后端挂不同可用区的服务器，健康检查间隔设3秒，失败重试2次就摘除节点
- 容器服务开启多可用区节点池，Pod调度打散到不同可用区
云厂商提供了能力清单，但你的业务不一定利用了，ECS快照要定时创建，RDS的备份要开启日志备份，对象存储要开启跨区域复制，这些开关都在控制台里,没开等于没有容灾。
监控告警不能只盯CPU和内存。应用层要监控接口错误率、超时比例、线程池活跃数；数据层要监控主从延迟、慢查询数量、连接数水位，告警规则要有阈值和持续时间双重条件，避免抖动误报，Web服务要配置Nginx的
max_fails和fail_timeout参数,让故障节点快速下线。
没写在纸上的制度等于没有容灾
技术架构再完善，没人执行也白搭,容灾准备最终要落到人员和流程上。
- 值班表要有主备联系人，数据库、网络、应用三条线的负责人要明确，电话保持畅通
- 应急手册要写清楚故障分级标准、升级路径、每个角色的职责，故障等级从P1到P4逐级定义
- 每两周做一次容灾技术碰头会，review备份状态、同步链路延迟、演练遗留问题
- 新员工入职必须参加容灾开关和步骤培训，老员工转岗要交接清楚
行业内有不少企业花钱做了容灾项目，但两年没演过练，架构师换了三任，应急预案还是第一版，专线断了半年都没人发现。容灾不是项目，是日常运营，每次配置变更、版本升级、容量调整都要重新评估对容灾的影响。
Q&A
数据库备份的恢复时长怎么验证
先计算备份集大小和恢复耗时，在测试环境实际跑一次全量恢复，记录从发起恢复到数据库可查询的完整时间，再把目标RTO减去恢复耗时，得出切换操作的缓冲时间，若恢复耗时超过30分钟，需要启用增量备份加归档日志的方案,缩短恢复窗口。
同城双活机房的专线带宽和延迟要求是多少
业务写请求要同步到两个机房，专线延迟通常要求小于2毫秒，带宽要按峰值流量的两倍规划，数据库日志同步是带宽消耗大户，需要单独为同步流量划分带宽,避免和业务流量抢资源。
多年没做容灾演练的系统从哪开始补课
先梳理最核心的数据库和应用架构，画清楚数据流向和依赖关系，再挑一台非核心应用做切换测试，验证基础脚本和网络连通性，跑通一次完整切换后再逐步扩大范围,不要一上来就搞全链路切换。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/634554.html
