正如企事业单位盛产“临时工”一样，IT行业也有大量的背锅侠，远有挖掘机近有程序员，而随着云计算服务的兴起，云计算厂商大有成为新一代背锅侠的趋势——因为很多服务跑在云上，不管这些服务为啥挂了，都可以说是云计算厂商导致的。
粗略的看，这锅还真是云计算厂商背定了。远的如AWS宕机、Azure宕机，近的有Google宕机(还是在说完为啥永远不会宕机之后就宕了个爽)，国内也有阿里云、腾讯云、青云等的宕机事故。云计算厂商宕机之后，他们服务的客户肯定也瘫痪。
不过，也有一些服务幸免遇难，其原因很简单——自己做了灾备。从系统性角度来看，云计算是一个很显而易见的责任方，但如果做到了服务的高可用还真的可以无视云计算宕机，关键在于顶层设计!
IT黑天鹅事件不可避免
云计算成了当今互联网服务的核心基础。云计算服务商在谈论服务时总喜欢强调有多少个9的可用性，无论是云服务器、数据库还是存储。这不是云计算行业的独特发明，面向企业级客户的产品和服务，***卖点永远是稳定可靠，9的个数是某种定量化的表征，换一种更专业的说法叫SLA。
不过，SLA并非万无一失的保险柜，这个世界上，小概率事件永远会发生，有个规律叫“墨菲定律”，大意是你想到的最坏的事情它总会发生——庞大而复杂的IT环境，加上各种天灾人祸，出问题几乎无法避免。
云计算高可用+应用高可用=服务高可用
那么，一个非常现实又容易被忽略的问题来了：如何保证在云服务不可用的情况下，用户的应用架构仍然能够屹立不倒?
能够提出这一问题的云计算用户并不多，因为绝大多数人把云平台的可用性等同于自身业务架构的可用性，事实上这是两件事。
出事了别把责任一把推给云厂商，也要看看自己。某种程度上，你得做好即便云计算厂商挂了，你都不会挂。因为这是你对你自己客户的承诺。承诺不能转嫁别人。
2012年堪称亚马逊AWS的厄运之年，6、7两个月连续宕机影响一大票用户，其中不乏Netflix、Heroku、Pinterest这样的明星公司。那时候，舆论不光对亚马逊AWS大加讨伐，对云服务的前景也几乎失去了信心。
但也有清醒的声音。美国知名电脑周刊杂志eWeek 就发表资深科技记者
Mike Elgan评论文章说“云计算不是万灵丹，我们不过是租别人的计算机而已。因此自己数据中心可能出现的问题就算是转向了云计算也依然存在”，他建议“企业有自己的替代方案很重要”。
Netflix的技术人员就表示，不论在何种情况下，每个系统必须靠自己存活。他们在设计系统时考虑了其所依赖的其他系统的故障并且能够容忍故障。
灾备还有同城灾备、异地灾备以及多活
自己掌握主动权，自己掌握主动权，自己掌握主动权，重要的事情说三遍。
解决可用性问题，很容易想到的是灾备：从两地三中心到同城双活到异地多活，金融机构、政府、大中型企业一直秉持“不把鸡蛋放在一个篮子里”的思路，在灾备的路上越走越高精尖。
但是高精尖的背后是高昂的成本，对中小企业而言有些负担过重。事实上，在云计算上也有对应的服务：地域(Region)和可用区(AZ：Availabe Zone)。
地域就是物理意义上不同地方的机房，一般来说距离较远，相对来说会在用户需求量较大的地方部署地域机房;每个地域又被划分成多个可用区。可用区就好比资源池，它由一组物理和逻辑资源组成。
所以对于自己的云端业务，既可以分散到多个可用区，也分散到多个地域。建立在不同地域上的业务架构可用性高于可用区，但复杂度和成本也高，所以平衡很重要。
应用高可用可做的文章更多
除此之外，互联网界对于系统如何达到高可用是有一些基本共识的，比如：大系统小做，服务拆分;并发控制，服务隔离;灰度发布;全方位监控报警;核心服务，平滑降级。这些***实践，如果很好地落实，对于提高系统可用性非常有帮助。
这里面每一个领域都可以单独做文章，本文想特别提一个概念：分布式。分布式是互联网界的热词，虽然说得多，但真正理解的人少。
分布式通过一套协议，将多台机器连接在一起，减少了中心计算节点，从而完成计算。增加了网络，减少了共享，这为分布式系统带来了一些新的优点，比如高可用。
能够做到高可用的原因其实很简单，因为分布式系统是通过网络将大量计算机连接在一起来完成功能的，而每一台参与到网络内的计算机，都是一台全功能的计算机。因此，哪怕网络内只存在着一台计算机，从理论上来说，他也能完成全部计算，只是速度会稍微有一点影响。
分布式的思想***了互联网的发展，也让高可用不再昂贵得遥不可及。
业内越来越清晰地认识到云计算是一门信任生意，可以说云计算是在金融之后，更大的信任商业。只是，企业把IT基础设施托付给云服务商的时候，千万别忘了你才是这些系统的主人。
