2015年我在一家传统制造业公司负责IT基础架构那时候的灾备就是两台服务器加一台磁带机每天凌晨两点跑一次全量备份磁带定期送银行保管箱。后来公司业务上云我原以为云平台自带的高可用能让我省心不少直到有一次生产数据库误操作删了一张核心表我才意识到一件事云的高可用只解决机器坏了的问题解决不了数据没了和机房没了的问题。那之后我系统地把云环境下的灾备体系从头梳理了一遍踩了不少坑也沉淀了一套可以复用的方案。这篇文章不聊虚的直接讲云灾备怎么规划、怎么选型、怎么落地、怎么演练。如果你也在做业务上云或者已经在云上跑着核心系统但灾备还停留在每天打一份备份这篇文章适合你。我会把设计思路、核心指标、实操步骤和常见坑一次说清楚。1. 先想清楚云灾备到底在备什么1.1 云灾备和传统灾备的差异传统灾备的核心是复制把数据从生产中心复制到灾备中心要么靠存储层面的同步复制要么靠数据库层面的日志传输要么靠备份软件定期打包。整套体系里最贵的不是软件也不是带宽而是那个常年空转的灾备机房——设备要买、电要出、人要养回切流程几年才跑一次跑完发现文档早就和实际环境脱节了。上了云之后情况变了很多。云平台把基础设施变成了API虚拟机、磁盘、数据库实例都是可以随时创建的资源灾备中心不再需要一个物理存在的第二机房而是可以在另一个地域Region或者另一个可用区Availability Zone按需拉起一套环境。这带来的最大变化不是成本降低而是容灾的灵活性你可以为不同重要程度的系统配置不同等级的灾备不需要为了最核心的数据库把全部系统都做成双活。但云也引入了新的风险维度。账号被盗、配置误删、跨区域同步延迟、云厂商自身的故障这些都是传统灾备不太会遇到的问题。所以我做方案设计时习惯先把一句话问清楚这个系统如果真的丢了业务影响是什么这句话能过滤掉一半不合理的需求。1.2 两个决定生死的关键数字RPO与RTO任何灾备方案都绕不开两个指标RPORecovery Point Objective恢复点目标和RTORecovery Time Objective恢复时间目标。RPO回答数据最多能丢多少RTO回答服务最多能停多久。定指标的时候我见过两种极端。一种是大领导拍脑袋说我们要做到零丢失、秒级切换完全不考虑技术可行性和预算另一种是IT部门自己心虚什么都不敢承诺最后做出的灾备方案形同虚设。这两种都不可取合理的做法是用业务成本来倒推。举个例子一个B2C电商网站订单表是核心数据假设每小时的交易额是50万如果RPO是1小时意味着灾难发生时最多丢失1小时订单数据直接经济损失最多50万还要算上客户投诉、信任度下降的隐性成本。那么灾备方案的年度投入就应该和这个风险敞口匹配而不是简单地越贵越好。我自己的实践经验是RPO和RTO不要试图用一个方案覆盖所有系统而是把系统分级对待。核心交易库RPO做到接近零、RTO做到分钟级可以用数据库层的实时同步普通业务系统RPO做到15分钟、RTO做到2小时内用定期备份加快速恢复机制历史数据仓库RPO做到24小时就够了定时备份就能满足。分级之后方案落地就容易多了。1.3 常见的云灾备模式备份、容灾、双活很多人把备份和容灾混为一谈其实它们是两层东西。备份是数据有副本容灾是服务能接管双活则是两边都在跑。这三者的成本和复杂度是逐级上升的不能一上来就追求双活。备份模式最简单云上的虚拟机、数据库定期做快照或者导出存到独立的存储或者另一个地域的对象存储里。这种模式RPO取决于备份频率RTO取决于恢复的速度适合开发测试环境和次要业务。容灾模式需要在灾备端准备一套可以启动的环境平时不对外提供服务但数据库等核心组件通过同步机制保持数据基本实时一致一旦生产端故障把流量切到灾备端就能继续跑。双活模式最复杂要求两个数据中心同时对外提供服务负载均衡实时切换这在云上的实现难度和成本都很高一般只有金融、通信这类行业才会做。我刚做云灾备方案时犯过一个错误给所有系统都规划了容灾级别的配置后来发现预算根本撑不住管理复杂度也上去了运维团队天天被过量的同步任务拖住。后来改成分级设计重要系统容灾、一般系统备份、归档系统冷备整体预算降了将近一半覆盖的核心风险反而更扎实了。2. 方案设计的核心思路先分级再选型2.1 按业务重要度给系统分级前面提到分级这里展开讲一下实操方法。我一般会把所有系统拉一个清单逐项评估两个维度业务影响程度和数据丢失容忍度。业务影响程度看系统挂了之后对收入、合规、用户体验的影响数据丢失容忍度看业务侧能接受丢多少数据。两个维度综合打分把系统分成P0、P1、P2、P3四级。P0级是核心交易、支付、用户主数据这类系统一旦故障直接导致业务停摆法务和财务都会找你这类必须做实时数据同步加跨地域容灾。P1级是订单查询、商品管理、风控这类系统故障会影响核心链路但短时间内可容忍做准实时同步加快速恢复即可。P2级是报表、后台管理、内容管理这类系统中断半小时内业务侧感知不明显定期备份加自动化恢复就行。P3级是日志、归档、历史数据这类系统丢失不心疼价值也不高冷备甚至不备都可以。做分级的时候建议让业务部门参与打分而不是IT自己关起门来定。我有一个亲身体会定了P0的系统业务侧说其实他们可以接受15分钟的数据丢失反而把另一个我自己觉得不重要的系统提成了P0理由是合规审计需要。业务部门的参与能让方案避免自嗨也方便后面申请预算。2.2 同城、跨地域还是混合云确定了系统的分级之后接下来要选容灾架构的形态。云上的容灾架构主要有三种同城双可用区、跨地域双Region、混合云。同城双可用区的思路是在同一个城市的不同可用区部署两套环境可用区之间的网络延迟通常在1到2毫秒以内可以做存储层同步复制RPO接近零故障切换也快。但它防不了城市级灾难比如大地震、大面积停电这类事件整个城市都受影响同城再怎么做都没有用。所以P0级系统一般要求至少做到跨地域。跨地域双Region的做法的核心指标是同步延迟。同一个云厂商在国内的两个Region之间专线延迟通常在几十毫秒数据库层的半同步复制可以做到亚秒级延迟但无法做到真正的零丢失因为极端情况下同步日志还没来得及传过去生产端就挂了。这时候需要业务侧接受一个几秒到十几秒的RPO大多数业务是能接受的。混合云架构是把自己机房和云组合起来适合已有存量机房、数据敏感度高、不想完全依赖单一云厂商的场景。实现方式可以是在自建机房运行核心数据库通过专线同步到云上做容灾也可以反过来生产在云上、灾备在自建机房。混合云的难点在于链路可靠性和两边的运维一致性一个网络抖动就可能让同步断流。2.3 技术选型存储复制、数据库同步还是备份恢复选型是整个方案里技术含量最高的环节。我常用的判断依据是数据放在哪一层就优先在哪一层解决。底层是云硬盘就考虑块存储复制上层是自建数据库就考虑数据库日志同步用的是云数据库托管服务就优先用云厂商自带的跨Region同步能力如果只是文件和应用那做好定期备份就够了。块存储复制适合虚拟机整机保护比如云硬盘级别的异步复制它把整个磁盘的数据块复制到灾备Region好处是应用无感知坏处是只能做到分钟级RPO而且需要灾备端预留等容量的存储成本偏高。数据库日志同步适合核心数据库无论是自建的MySQL、PostgreSQL还是云数据库实例都可以通过主从复制或日志回放的方式保持灾备端数据接近实时RPO可以做到秒级甚至更低。备份恢复适合大批量非核心系统用云备份服务定期做快照或者文件备份平时不启动灾备环境恢复时再按需拉起成本最低。我见过不少团队放着云厂商现成的跨Region复制能力不用非要自己在两台ECS上搭主从同步美其名曰自主可控。结果从节点宕机没人处理、主从延迟没人看、位点偏移了也不知道真出问题时备库数据早就落后了。我的建议是能用托管能力就用托管能力云厂商的跨可用区部署、跨Region同步服务本身经过了大规模生产验证比自己搭的强。自建方案只保留在需要跨云厂商或者数据库类型不被托管支持的时候才用。2.4 成本控制灾备预算的四笔账云灾备的成本构成和传统灾备不太一样传统灾备是一次性采购成本加长期运维成本云灾备则是持续性的资源占用成本。我总结下来有四笔账要算清楚。第一笔是灾备端常驻资源。数据库同步、跨Region复制这些能力要求灾备端有一台运行中的实例无论是只接收日志还是半活状态都在持续产生计算和存储费用。P0级系统这笔钱省不掉P1和P2级系统可以考虑用按量付费实例平时不启动只在备份恢复时拉起。第二笔是数据传输费用。跨Region的数据复制会消耗公网或专线流量大日志量、大镜像的持续同步会是一笔不小的开销需要注意流量计费方式有些方案可以走云厂商的内网传输通道省掉部分流量费用。第三笔是备份存储费用。快照和备份文件积少成多尤其是多版本备份如果不设生命周期策略存储费用会线性增长。建议给备份设置合理的保留周期比如日备保留7天、周备保留4周、月备保留6个月。第四笔是演练和切换产生的一次性费用。每次容灾演练都会在灾备端拉起完整环境按小时计费这个费用不高但容易被忽略预算里要留出这部分空间。3. 操盘实录一套跨地域容灾方案的落地过程3.1 准备工作盘点现状与目标我以一套典型的电商业务系统为例讲一下落地过程。这套系统的架构是前端Nginx加微服务应用后端一套MySQL主库加Redis缓存部署在云厂商的华东Region。业务侧定的容灾目标是RPO不超过15秒RTO在30分钟以内要能扛住Region级故障。第一步先盘点现状。把所有依赖的资源列出来ECS实例清单、数据库实例规格、存储量、网络架构、对外入口的负载均衡配置、DNS解析方式。这个盘点看起来简单但很容易漏。我第一次做的时候漏掉了Redis后来演练时发现主库恢复之后缓存全空数据库被瞬间打爆这才补上了缓存的容灾方案。所以盘点时不要只看应用服务器和数据库中间件、消息队列、缓存、对象存储全都要纳入范围。第二步是设计目标架构。这里我选择的是跨Region容灾生产继续跑在华东Region灾备部署在华北Region数据库用云数据库的跨Region同步能力做实时同步应用层在灾备Region预置一套最小规格的ECS镜像平时不启动演练或灾难发生时扩容到生产同等规格再拉起。这种方式兼顾了成本和RTO目标。3.2 数据库层的实时同步配置数据库是容灾的核心数据同步做不好其他全是白搭。如果你用的是云数据库托管服务优先看云厂商是否提供跨Region的只读实例或者灾备实例功能。以我用的云数据库MySQL为例创建灾备实例时选择跨Region同步源实例的增量变更会实时回放到灾备实例事务提交后同步延迟通常在1秒以内。这里有几个参数和细节需要注意。第一同步链路建立后要持续关注延迟监控正常情况下延迟应该在几百毫秒以内如果发现延迟持续走高首先看源实例的binlog是否设置了足够长的保留时间我遇到过binlog只保留24小时导致灾备实例断链后无法追平的情况。第二要确认灾备实例的规格不能低于源实例的某个比例否则大事务回放时会产生资源竞争拖慢同步速度。第三日常运维中不要在灾备实例上执行任何写操作一旦手动写了数据复制链路就会出错我踩过这个坑一台灾备实例被DBA顺手改了参数导致复制中断了三天才被发现。自建数据库场景下MySQL主从复制也是成熟方案配置主库开启binlog并设置server-id灾备端配置为从库。比较关键的是要确认binlog_format设置为ROWstatement格式在大事务、函数操作等场景下会导致主备数据不一致。另外要重点监控从库的Seconds_Behind_Master指标这个指标归零才代表追平了。3.3 应用层与流量切换方案应用层容灾的核心问题是灾备Region的环境平时不启动灾难发生时怎么快速拉起并接住流量。我的做法是提前做一套标准化的应用镜像代码、运行时、基础配置全部固化到镜像里灾备Region创建ECS时直接从镜像批量拉起再通过启动脚本从配置中心拉取最新的应用配置。流量切换是整个容灾流程里最容易出错的环节。生产流量入口如果是云厂商的负载均衡灾备切换时要么手动把DNS解析切到灾备Region的负载均衡要么用云厂商的全局流量管理服务做自动切换。DNS切换的生效时间取决于DNS TTL设置我建议把核心域名的TTL预先调低到60秒否则切换时等DNS缓存过期就要等很久。这个细节看着不起眼关键时刻能省下宝贵的恢复时间。存储类的数据也要考虑。如果应用依赖对象存储存放图片、文件生产Region的对象存储需要开启跨Region复制否则数据库切过去了图片还是访问不了。传统文件服务器也一样要么用分布式文件系统自带跨站点能力要么定期把增量文件同步到灾备Region。这一步很容易被漏掉我在一次演练中发现数据库和应用都恢复正常了但商品图片全部404排查半天才想起来对象存储的复制策略没配。3.4 非核心系统的备份策略配置P1、P2级系统不需要做实时容灾但备份策略要配好。云平台一般都有云备份服务支持对ECS整机做定期快照、对数据库做定期备份。配置备份策略时我的建议是快照频率按RPO需求设置保留份数按恢复窗口设置不要贪多。一个参考配置是P1级系统做每日快照加每周全量备份快照保留7份每周备份保留4份P2级系统做每周快照保留4份日志和归档数据做每月冷备转存到低频访问存储或归档存储。备份文件最好复制一份到另一个Region防止Region级故障时备份也跟着丢了。这一步成本不高但很多人没想到。备份不能只配不看。我曾接手过一套系统的检查备份任务配置了三个月一查日志发现最近两个月全部失败原因是某天磁盘空间满了之后旧的备份文件没有自动清理新备份一直排队失败。所以备份任务的状态监控一定要接入告警系统失败必须有人看到。4. 日常运维监控、演练、持续改进4.1 容灾演练不演练的容灾都是心理安慰容灾方案做完了如果不演练真到灾难发生时大概率切不过去。原因很简单文档里写的步骤和实际环境一定有偏差网络权限变了、密码换了、依赖的服务没启动各种小问题平时不会暴露灾难时全部集中爆发。我经历过一次完全没有演练的容灾切换光是一个数据库密码过期就让恢复时间多花了40分钟。我的建议是P0级系统每季度做一次完整容灾演练P1级系统每半年做一次。演练不要只做纸上谈兵式的桌面推演要真刀真枪在灾备Region把环境拉起来、把数据同步过去、把流量切过去、再把业务跑一遍。演练选在业务低峰期进行提前通知业务团队配合验证。演练之后的复盘更重要。每次演练都会暴露问题可能是同步延迟过高、应用启动依赖了生产环境的地址、配置文件里有硬编码的IP。把这些问题逐一记下来形成整改清单在下次演练前必须完成。我见过一个团队连续三次演练都在同一个环节卡住——应用启动时去连一个内网DNS而灾备Region根本没有这个服务如果没人复盘整改这个问题会一直存在下去。4.2 监控告警与巡检清单灾备系统的核心指标需要持续监控。数据同步延迟是最重要的指标之一延迟超过阈值要告警备份任务的成功率要每日核查灾备端资源的使用率要监控防止长时间不启动导致磁盘、内存被其他任务占满容灾切换依赖的密钥、证书要定期检查有效期避免切换时发现证书过期。我习惯把巡检做成一份清单每周花半小时过一遍。清单内容包括数据库同步链路状态和延迟、备份任务执行记录、灾备端ECS磁盘空间、跨Region复制状态、DNS TTL配置是否被改动、容灾文档里的密码和密钥是否还能用。这份清单看似简单但它能保证你随时对灾备体系的状态心里有数。4.3 架构演进后的持续更新业务架构不会一成不变每上线一个新系统每做一次技术改造都要重新评估灾备方案是否还覆盖到位。我给自己定了一条规矩任何生产变更都必须回答一个问题——这个变更对容灾方案有没有影响。最典型的例子是引入消息队列。很多系统上线MQ之后只给数据库做了容灾却忘了MQ里的积压消息也是数据。如果生产Region挂了MQ里的消息丢了下游消费者可能感知不到但业务数据其实不完整了。这类隐蔽的数据丢失很难发现排查成本也高所以变更评审时就要把灾备方案一并考虑进去。5. 常见问题与排查技巧实录5.1 灾备端数据库同步延迟持续走高现象是灾备实例的同步延迟从几百毫秒逐渐升到几十秒甚至几分钟。排查思路先从源库入手看是不是有大事务在跑。一个大事务在源库执行了几分钟同步到灾备端也要回放这么久期间延迟自然高这种情况一般不需要处理大事务结束后延迟会逐渐回落。如果源库没有大事务再看灾备实例的规格是不是偏小灾备端CPU和IO打满会导致回放速度跟不上源库的写入速度这时需要升级灾备实例规格。还有一种常见原因是源库binlog保留时间太短灾备实例短时间断链后无法从保留的binlog继续追同步只能重新初始化同步链路这个恢复过程耗时较长所以binlog保留时间至少要设置为灾备容忍断链时长的两倍以上。5.2 演练恢复时发现应用连不上数据库这个问题的根源通常是应用配置里的数据库连接地址写的是生产Region的内网地址灾备Region拉起应用后网络不通自然连不上灾备数据库。解决办法是在应用配置里抽象一层数据源地址比如通过环境变量或者配置中心动态指定不要硬编码生产环境的IP。更稳妥的做法是灾备演练时准备一套完整的配置清单包括数据库地址、缓存地址、消息队列地址全部切换到灾备环境对应的值。这个问题在第一次演练时必然会暴露好消息是它修起来不难只要把配置管理规范化就行。5.3 备份恢复速度达不到预期明明按频率做了备份真恢复时却花了很长时间。原因有很多种最常见的是数据量远大于当时的预期全量备份文件好几个TB恢复时要从备份存储拉取数据网络带宽成为瓶颈。另一个原因是恢复目标机器的规格偏低CPU、内存不够导致数据库初始化缓慢。我的建议是恢复前先评估数据量和目标规格必要时临时提升ECS规格加快恢复速度恢复完成后再降回去。还有一点平时演练时就要实测恢复耗时拿到基础数据之后才能对RTO目标有底。5.4 云上账号权限问题导致无法切换容灾切换时需要操作灾备Region的资源如果云上账号体系是RAM子账号权限配置不到位切换时才发现当前账号没有创建ECS、修改安全组、操作负载均衡的权限场面会非常尴尬。建议把容灾切换所需的权限提前配置好做成专门的容灾角色或授权策略并定期验证该角色的权限有效性。另外要注意密钥和证书的管理登录灾备服务器的密钥对、数据库的访问凭证都要提前确认在灾备Region可用。5.5 灾备文档和实际环境脱节这是一个普遍问题。容灾文档写于半年之前实际环境里新增了两台应用服务器、改了负载均衡策略、换了数据库参数文档还停留在旧版本。等到切换时看着文档操作每一步都对不上越做越慌。解决这个问题没有捷径只能把文档维护纳入日常运维流程每次生产变更后同步更新容灾文档并在季度演练时用最新文档完整走一遍流程发现差异当场修正。踩过这么多坑之后我个人体会最深的一点是云灾备方案的设计并不难难的是持续让这套体系保持在可用状态。技术在变、业务在变、架构在变灾备方案也需要跟着变。与其追求一套一步到位的大而全方案不如搭一套分级合理、定期演练、持续改进的实用体系。哪怕初始方案简单一些只要每次演练都在进步、每个问题都被记录和修复这套体系在关键时刻会比一叠厚厚的方案文档可靠得多。
