CSP巨头都会翻车，云用户需要自己的灾备计划

老司机翻车史

这个春天对于云用户来讲，绝对是提心吊胆过日子的季节，为什么这么讲？

看看还未过完的2017年3月，AWS和Azure这两个老司机都相继翻车了。

3月1日，AWS S3服务中断4小时，全球超15万个使用S3服务的网站都受到影响，墙外的互联网哀鸿遍野。

3月16日，AWS的好基友Azure出现云存储问题，Azure全球28个数据中心里边有26个出现故障。

如果手头有一本云平台故障台账，继续往回翻，你会得出一个结论：CSP无论大小无一幸免。

但即便如此，云平台偶尔一次抽疯也不会改变云架构稳定性高于传统IT架构的事实，如果你手头有云计算市场份额的数据，那么结论的后半部分是，上云是大势所趋，用户的云上之路已经越走越远。

当诸位冷静下来，理性看待云计算稳定性这个话题的时候，作为用户本身，除了依赖CSP的SLA之外，我们自己也应该具备Design for failure的认知。

Design for failure

AWS S3可用性指标是99.9%，并且它的设计原则之一就是Design for failure（为故障而设计），Design for failure这个理念由AWS提出，厂商们在IaaS和PaaS层面会充分考虑容灾机制。

咱们经常看到厂商提及自身具备跨地域级别容灾、机房级别容灾、集群级别容灾、服务器级别容灾和磁盘级别容灾，这其实也是AWS S3提出的99.999999999%数据可靠性指标的根据之一。

AWS和Azure血淋淋的教训已经让部分用户交了学费，我们再来复盘AWS S3故障后哪些用户会收到影响：

• 某项业务单独运行在S3服务器上，比如网站服务，那么不好意思，404这个坑就等你跳了。

• 某项业务中的脚本或资源依赖于S3服务，比如我在S3上放了一个网络直播服务，嘿嘿，就别想着打赏了，还是404。

• 某个应用软件的服务依赖于S3服务，后果同上。

显而易见，我们应该避免将鸡蛋放在一个篮子里，我们的业务依赖云上的哪些服务，这个依赖关系得自己梳理，完了之后还要根据自身SLA要求进行冗余容灾，也就是给这些依赖点建立冗余机制，这也是少数云上用户跨Region/CSP部署业务的理由之一。

云容灾责任共担模型

笔者一直强调云安全责任共担模型，其实云容灾也是如此，容灾也应当遵循责任共担模型。

业界No.1的AWS都做不到零故障，完全依靠厂商大伙就不能指望了。

在故障不可避免的前提下，我们自己需要采取更多手段来降低云平台故障对业务的影响。换句话说，底层容灾交给CSP，但是上层就得靠自己了。

这意味着云用户也需要制订自己的灾备计划（DRP）或者业务连续性计划（BCP），而这个灾备计划建立在云平台会发生故障的假设之上：

1.意外事故计划策略说明：比如AWS S3发生故障后，由公司哪个团队去负责处理，执行什么流程和步骤，由哪些部门配合，需要什么工具和资源，这些都是通过事先讨论并确认的。

2.业务影响分析：受影响业务哪一部分需要优先处理，比如用户侧业务恢复优先级高于后台侧，另外还需要确定两个参数，分别是RTO和RPO，RTO是业务能断多久可以接受，RPO是业务能恢复到哪个时间点能接受。

3.预防性措施：前面讲的跨域部署业务就是典型措施之一。

4.恢复策略：即如何恢复业务的流程步骤，比如重做系统、重启服务或导入数据等。

5.紧急情况响应：比如你的网站数据库被勒索软件黑了，这时该怎么处理？

6.测试和培训：计划只有能有效执行才有用，灾备计划需要定期测试，相关人员也需要定期培训和演练。

7.计划维持：DRP是活的，它需要根据业务变更及时进行更新，通常而言DRP每季度进行一次更新。

换句话说，上面的灾备计划其实就是云计算用户侧的Design for failure。

在巨头纷纷翻车的今天，云服务稳定性是需要CSP和用户共同面对的难题，而容灾这个事儿，靠天靠地也得靠自己。