总部发起，美业业务线推动双机房落地。本文从落地背景、方案选择、关键点和 SOP 产出四个部分，整理双机房建设的核心思路。
一、为什么做双机房？
双机房建设的核心目标很明确：
数据不丢失，业务不停机。
但真正推动落地，不能只讲技术目标，还要回答三个问题：业务是否划算、组织是否具备能力、基建是否支撑得住。
1. 业务价值 ROI 划算
- 商家规模：业务体量越大，停机影响面越大，双机房的收益越明显。
- 102.4 赔偿：故障可能触发赔偿，直接带来财务损失。
- 竞品丢数据：行业已有竞品因数据丢失影响商家信任，这是最现实的警示。
2. 组织能力
- 组织是否具备常态化演练机制？
- 团队是否具备故障发现、决策、切换、恢复的能力？
- 双机房不是一次项目，而是长期运行能力。
3. 基建能力完善
双机房落地依赖配套基建：
- 发布平台
- 监控告警平台
- 服务治理平台
- 容灾恢复能力
这些平台决定了故障时能否快速切流、快速恢复、快速验证。
二、方案选择：没有最优，只有匹配
双机房方案选择主要看两个维度：
- 地域：同城还是异地？
- 是否提供服务：备份还是多活？
常见方案包括：
| 方案 | 特点 | 适用场景 |
|---|---|---|
| 同城备份 | 成本较低，同城容灾，平时不承载或少量承载流量 | 初期容灾建设 |
| 同城多活 | 低延迟，同城故障可切换，复杂度中等 | 同城高可用要求高 |
| 异地多活 | 地域级容灾，复杂度最高，数据一致性挑战大 | 业务连续性要求极高 |
| 两地三中心 | 生产中心 + 同城灾备 + 异地灾备 | 金融级容灾 |
方案选择没有绝对优劣，关键是匹配：
- RTO / RPO 目标
- 成本预算
- 业务规模
- 团队运维能力
- 机房之间 RT
- 数据一致性要求
三、关键点：基础设施、数据、应用三层联动
双机房不是简单加一个机房，而是基础设施、数据、应用三层系统性改造。
1. 基础设施层
基础设施层要解决的是：从物理上规避故障。
关注点包括：
- 电力
- 网络
- 灾害域
- 机房 RT
机房 RT 尤其关键。它直接影响数据同步方式、双写策略、数据库选型和故障切换速度。
2. 数据层
数据层是双机房最核心、最复杂的部分。要同时考虑一致性和可用性。
一致性
重点组件：
- MySQL
- HBase
- KV
- etcd
不同组件一致性模型不同，需要分别设计：
- 强一致数据：优先保证不丢，必要时牺牲部分可用性。
- 最终一致数据：可接受短时间不一致，但要有补偿机制。
- 配置 / 元数据：关注 quorum、租约和跨机房 RT。
可用性
重点组件：
- NSQ
- ES
- 发号器
可用性设计常见手段：
- 双写：正常时双机房写入，但必须处理幂等、顺序、冲突和补偿。
- 机房封闭：故障时封闭某个机房，避免脏写、脑裂和数据不一致。
- 降级：搜索、消息等非核心链路可降级，优先保住交易和资金链路。
数据层的原则是：先定一致性等级，再定同步和切换策略。
3. 应用层
应用层要解决的是：故障转移和流量切换。
关键能力包括：
- 服务治理
- 注册中心
- 配置中心
- 网关 / GSLB / DNS 调度
- 故障转移
- 流量切换
- 回滚与验证
流量切换不能只靠人工，要尽量自动化、可观测、可回滚。
四、产出：故障演练 SOP 与故障恢复 SOP
双机房最终要沉淀为可执行的流程，而不是只停留在架构图。
1. 故障演练 SOP
包括：
- 演练目标
- 演练范围
- 角色分工
- 触发条件
- 操作步骤
- 验证指标
- 回滚方案
- 复盘机制
2. 故障恢复 SOP
包括：
- 故障发现
- 故障定级
- 决策机制
- 流量切换
- 数据校验
- 机房封闭 / 解封
- 恢复放量
- 事后复盘
SOP 的价值在于：故障发生时，团队不需要从零讨论，而是按既定流程快速执行。
五、总结
双机房建设是一项系统性工程：
- 业务上，要算清楚 ROI；
- 组织上，要建立常态化演练能力；
- 基建上，要依赖发布、监控、治理和容灾平台；
- 方案上，要根据地域、是否提供服务、RTO / RPO 选择匹配方案；
- 技术上，要抓住基础设施、数据、应用三层关键点；
- 最终，要沉淀为故障演练 SOP 和故障恢复 SOP。
一句话总结：
双机房不是多一个机房，而是让数据不丢、业务不停、组织能战。