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和用户共同面对的难题,而容灾这个事儿,靠天靠地也得靠自己。

相关文章
相关标签/搜索