前段时间，谷歌云刚惹了个大麻烦， UniSuper基金的私有云帐户由于谷歌云的“错误配置”而被意外删除，导致50多万会员一周无法访问退休金账户。UniSuper和谷歌云首席执行官Thomas Kurian发表联合声明道歉，称事件“极其令人沮丧、极其令人失望”。虽然UniSuper最终恢复了服务，但花费这么长时间的等待，着实是令人唏嘘。
针对这种重大故障，本文就来探讨下，作为SRE 我们该如何制定有效的DR（Disaster Recovery）容灾恢复计划。
容灾恢复计划 - 概览
通常，DR恢复策略是为响应故障导致的业务中断而实施的一组预定义操作。这些可能是自然（地震、洪水、飓风、火灾等）或云提供商区域范围的中断。
云上业务Disaster Recovery 策略一般会混合使用“备份和还原”和“热备用” 等方法。 为了加快恢复速度， 云上业务的infra基础设施、数据后端和应用程序基础设施可预先配置故障转移DR区域，并设置必要的容量预留。故障转移DR区域在正常情况下可处于关闭状态。
区域示例
云厂商 | 区域 | 国家 | 备注 |
Cloud AWS US | USEast(N.Virginia) | USA | us-east-1 |
Cloud AWS USDR | USWest(Oregon) | USA | us-west-2 |
Cloud AWS EU | Europe(Frankfurt) | Germany | eu-central-1 |
Cloud AWS EUDR | Europe(Ireland) | Ireland | eu-west-1 |
Cloud AZURE US | WestUS(California) | USA | WestUS |
Cloud AZURE USDR | EastUS(Virginia) | USA | EastUS |
容灾恢复目标
容灾恢复计划设定了两个目标：
-RPO （恢复点目标）定义了可能因故障而丢失的最大数据事务量;
-RTO （恢复时间目标）定义在故障转移区域还原生产服务的最长时间;
示例
Product | Recovery Point Objective(RPO) | Recovery Time Objective(RTO) |
云上业务 | 12 hours | 12 hours |
故障决策时间点
Time | Checkpoint | Description | Whom to warn? |
T0 | 故障发生 | RTO开始时间点 | |
T0 + 21 min | SLO Violation | SLA 丢失若服务还未恢复 | SRE经理 |
<= T0 + 100 min | 确认DR是否部署 | 决定DR恢复是否开始执行 | CTO, CPO, SVP Products,SRE or PM |
T0 + 120 min | DR Deployment | DR部署启动 | DR Decision Group |
T0 + 180 min | Assessment recommendation | 预估故障备份区域就绪时间，定期更新状态 | |
<= T0 + 11hours | DR 启用 | DR Decision group 确认启用容灾备份区域 | CTO, CPO, SVP Products,SRE or PM |
故障恢复团队与决策组
DR团队可以由以下人员组成：
-1位容灾恢复主管
-DR恢复团队：
o1+ SRE
o1+ QA
o1+ 开发（如果需要）
-故障处理团队
o1+ SRE
o1+ 开发（如果需要）
o1+ 信息安全（如果需要）
o1+ 云/产品提供商（如果需要）
故障恢复角色定义
on-call SRE （L1）角色，负责：
故障处理团队 （L2）角色，负责：
需要有“容灾恢复主管”角色，负责：
成立专门的"DR 决策组"角色，负责：
故障恢复流程图
（清晰图后台私信获取）
故障恢复DR决策思路
总结
本文分享了云上业务在发生故障事件时的应急响应计划。该计划包括明确的恢复策略、目标、团队责任分工、沟通方案和决策流程,旨在确保业务能够有效地应对并从灾难中恢复过来,最大限度地减少对客户服务的影响。
