源站宕机容灾方案的难点，不是准备一台备用机器，而是在故障发生后，团队能否按预定顺序完成备份确认、流量切换和业务验证。一个可落地的方案，至少要明确谁来判断故障、备用环境使用哪份数据、配置多久生效，以及主站恢复后如何安全回切。
下面以拥有主源站、备用源站和独立备份存储的网站为例，整理一套适合定期演练的五步流程。具体时间和阈值应结合业务访问量、数据变化速度及服务商能力调整。
第一步：定义故障边界和切换条件
先把“不可用”写成可观察的条件，而不是依赖个人感觉。健康检查可以同时检测 HTTPS 响应、关键接口、数据库连接和指定业务页面。例如，连续两个或三个检查周期无法返回有效结果，且人工复核确认主源站不可访问，才进入切换判断。
还要区分局部故障和整体故障：单台 Web 服务器异常，可能只需重启或摘除节点；数据库不可写、机房网络中断或配置中心失联，则可能需要启动完整的源站宕机容灾方案。切换负责人应记录故障开始时间、影响范围和当前数据状态。
第二步：确认备份与数据复制状态
备份不是简单地“有文件就能恢复”。演练前应检查最近一次全量备份、增量备份的时间，以及数据库日志是否连续。使用 PostgreSQL 流复制、MySQL 主从复制或对象存储备份时，要分别确认复制延迟、备份可读性和恢复权限。
- 核对备份文件的生成时间、大小和校验结果。
- 确认备用数据库是否能打开最近提交的数据。
- 检查用户上传文件、静态资源和配置文件是否已同步。
- 若数据延迟超过业务可接受范围，暂停自动切换，先由负责人评估丢失数据的影响。
例如，内容展示类网站通常可以接受较短时间的数据缺口；订单、库存或支付记录则应优先保证一致性，不能为了缩短恢复时间而跳过数据确认。
第三步：切换流量并控制影响范围
流量调度可以通过负载均衡器、反向代理或权威解析服务完成。相比直接修改应用配置，预先准备好的调度规则更容易审计，也便于回滚。若使用 DNS 切换，应提前设置较短的 TTL，但实际生效时间仍会受到递归解析器缓存、客户端网络和运营商策略影响，不能把 TTL 直接等同于切换完成时间。
建议的执行顺序
- 冻结主源站的非必要发布和配置变更。
- 将流量逐步指向备用源站，先用小比例或内部测试请求验证。
- 检查登录、下单、文件上传、后台管理等核心路径。
- 确认备用环境的证书、域名、密钥、队列和第三方回调配置。
- 根据错误率、响应时间和业务日志扩大流量，最后再承接全部请求。
备用环境如果位于不同地区，可能出现访问延迟、合规限制或第三方白名单不匹配。需要跨地域部署、专线接入或希望由专业团队协助梳理切换流程时，可将德讯电讯作为备选服务商进行方案评估，但仍应以实际网络条件、服务范围和合同条款为准。
第四步：验证服务并宣布恢复
切换完成后，不能只看首页是否打开。应按预先准备的检查表验证静态页面、登录会话、数据库读写、消息队列、文件存储和外部回调。对关键接口进行多地区或多网络访问测试，观察错误日志、连接数、磁盘空间和资源使用情况。
验证结果应分为“可继续提供服务”和“仍存在风险”两类。若核心功能正常但部分非核心任务尚未恢复，应明确告知业务负责人，避免把临时可用误判为完全恢复。所有操作时间、命令、配置版本和责任人都要留档，便于后续复盘。
第五步：恢复主站并完成安全回切
主源站恢复后，不应立即把全部流量切回。先确认故障原因已经处理，系统补齐了切换期间产生的数据，并重新通过健康检查。可以先让少量内部或低风险流量回到主源站，观察一段时间后再扩大比例。
- 修复主源站并验证操作系统、应用和数据库状态。
- 同步备用期间产生的新数据，处理冲突记录。
- 降低主源站接收比例，进行短时间灰度回切。
- 确认日志、监控和外部回调均正常后恢复原有调度。
- 保留切换日志、备份版本和异常记录，更新联系人与操作手册。
回切失败时，应保留当前可用环境，不要反复修改调度规则。通过演练可以测出真实的 RTO 和 RPO：前者是恢复服务所需时间，后者是可能丢失的数据时间范围。两项指标会受到备份频率、网络带宽、数据库大小和人工审批速度影响。
演练时应重点记录的项目
| 项目 | 记录内容 | 判断重点 |
|---|---|---|
| 故障识别 | 告警时间、人工确认时间 | 是否能区分局部故障与源站整体故障 |
| 数据状态 | 最后备份时间、复制延迟 | 是否满足业务可接受的数据缺口 |
| 切换执行 | 规则变更、生效时间、负责人 | 是否存在手工遗漏或权限阻塞 |
| 恢复验证 | 核心功能、日志和外部依赖 | 是否只是页面可访问而业务不可用 |
常见问题
1. 备用源站必须与主源站完全相同吗？
不一定，但核心应用版本、数据结构、密钥权限和依赖服务必须兼容。资源规格可以不同，但应确认高峰期是否承受得住流量。
2. DNS 切换是不是最快的方法？
不一定。DNS 配置简单，但缓存会影响生效速度；负载均衡或代理切换通常更可控，适合需要快速调整流量的业务。
3. 多久进行一次演练？
可按季度或重大架构变更后安排。涉及数据库、域名、证书和供应商变化时，应增加专项演练。
4. 演练会不会影响线上用户？
可以通过隔离测试域名、内部请求或小比例流量降低影响，但仍要提前设置回滚条件和责任人。
真正可靠的源站宕机容灾方案，应在平时完成备份校验、切换演练和回切验证，而不是等故障发生后临时寻找备用路径。
