Amazon刚刚经历的云服务停机事故引发业界对云技术的又一番争论。
就在上周日上午时段，Amazon Web Services数据中心遭遇一起相当严重的意外事故。
美国东部时间清晨六点，该公司负责承载AWS东弗吉尼亚区域负载的名为DynamoDB的大规模NoSQL数据库发生使用率暴涨状况——顺带一提，东弗吉尼亚州区域为该公司历史最悠久、规模***的九个全球性区域之一。到当日上午七点五十二分，AWS判断出问题根源：该数据库的元数据管理机制出现问题，直接影响到其服务的分区与表。
Amazon Web Services
Amazon Web Service的运行状况仪表板所示之上周日故障事件时间流程，其中包含引发问题的根本原因。
由于AWS服务使用极为复杂的互连机制，因此该问题滚雪球般影响到了总计117项受运行状况仪表板监控的服务类别当中的34项。从Elastic Comupte Cloud(即弹性计算云，简称EC2)到虚拟机、到Glacier存储服务再到Relational Database Service(即关系数据库服务)皆受到波及。根据媒体报道所言，其它采用AWS方案的企业客户亦遭到影响，其中包括Netflix、IMDB、Tinder、Pocket以及Buffer等知名公司。
截至上周日中午，AWS方面报告称问题已经得到解决，但在其期间Twitter及其它社交平台上出现了大量投诉与抱怨之声。
美国当地时间2011. 4 月 21 日早晨，位于北弗吉尼亚州的亚马逊 EC2，RDS 服务器出现了技术问题，导致网络延迟及链接错误。亚马逊的此次 “云端” 技术故障导致多个知名应用出现大规模停顿。受害者包括：Foursquare，Quora，HootSuite，Reddit 。
我将这次技术故障称为：云震，云端大地震。
IDC 的分析师 Matthew Eastwood 说：“这是对云计算的一次特别提醒。” 云震是对云计算理念的一次警告。以往云所宣称的 “永不宕机的可靠性” 其实只是一种期望。
简单的去理解云，它是一种以最终计算能力和存储能力为产品的信息服务，和以往机房提供的服务不同，客户无需关心计算能力和存储能力的由来。然而这项服务的根基仍然是机房服务。客户可以不关心云的运营，然而将这个概念扩展到 “任何人无需关心云的运营” 就不可取了。今天亚马逊关心的不到位，就要客户和终端用户为这样的不到位买单。
针对 “云不是完美的” 这项事实，全球的信息专家发出了各种设想，意在云震之后完善这个理念，让各种服务继续飘在云端。
那么我们该从此次事故当中吸取哪些经验教训?下面请大家一同探讨其中的三项重点。
1.云服务巨头也有失蹄的时候
Amazon Web Services是目前公有IaaS云领域当之无愧的王者——虽然微软公司似乎也在这类业务身上砸下重金，但似乎仍然无法动摇Amazon的强势地位。上周日的事故则提醒我们，即使是规模***、经验最为老到的云服务供应商，也仍然有可能遭遇意料之外的突发状况。
2.时刻准备迎接停机事故
考虑到即使是市场上成熟程度***的云方案也仍然有可能——或者说实际遭遇到长达六个小时的服务停机，客户应当提前为此做好准备。AWS长久以来一直建议客户对自有系统进行架构规划，从而更加主动地应对可能出现的虚拟机或者其它服务停机。
DownDetector.com网站统计图表显示，Netflix公司上周日早晨的错误报告频率远高于正常状况。不过根据该公司的一位发言人所说，其服务并没有受到显著影响。
作为Amazon公司旗下规模***且***知名度的云服务客户之一，Netflix公司通过发言人强调称，此次停机事故给其服务造成的影响被控制在了***程度，这是因为其以自动化方式将工作负载从出现问题的美国东部区域设施迁移到了其它运行正常的区域。任何使用AWS承载关键性业务应用的客户都应当对系统架构进行调整，从而确保其能够在相关云服务出现意外状况时做好应对措施。Netflix公司还开发出了一系列开源工具，旨在帮助自身系统进行随机崩溃测试。尽管Netflix方面并不承认其客户因此次事故受到严重影响，不过第三方停机追踪站点却发布报告称，Netflix在上周日早间遭遇到远超过正常水平的服务中断频率。换言之，即使是做好了充分准备的高水平客户，也没办法完全避免云服务中断造成的影响。
3.“莫谓言之不预”
福布斯网站的一位博主认为，此次服务中断并不会改变云计算的未来普及趋势。我个人基本同意这种看法。如果大家身为AWS的拥护者，那么肯定会从积极的角度看待此次事件，例如中断事故的发生频率远低于以往，如果客户采取AWS推荐的***实践、那么这些意外也不会造成太大影响等等。
不过换个角度来看，像上周日这样的服务中断状况将成为有力证据，促使那些不愿将工作负载交给公有云打理的客户抱持更加顽固的心态。
事实上中断事故是不可避免的，其可能出现在公有云服务中、任意供应商处甚至连企业自己负责运行的内部数据中心也不放过。而这正是IT事务的本质与宿命，所以一味强调公有云存在可用性问题确实不太客观。
原文作者： Brandon Butler
原文标题：3 Big takeaways from Amazon’s latest cloud outage
针对云相差应对思路：
一般情况下，小型企业受限于资金或技术能力等因素，不太会有专门的IT团队和资源对自己的服务和数据进行高可用部署或者容灾部署，那么这个时候，就更应该做好充分的预案，才能避免下一次再次出现的时候手忙脚乱。
第一：应急预案
- 首先通知业务相关干系人
每种业务是否有对应的接口人；
相应接口人的联系方式是否正确，更新是否及时。
- 故障或者告警到达一定级别，开始对系统降级
是否有降级方案；
降级方案是否适用；
降级方案是否进行过测试。
千万不要降级方案平时没有测试过，出事的时候拿来就用。降级这种事，如果技术部门心里都没底，如何保证出事时方案一定就可用。所以，降级方案也一定要演练！！！
- 流量迁移
快速把故障区域的流量迁移到其他可用区域或者云服务商。
第二：问题发生时，故障检查
1. 分别确定前端和后端服务是否正常运行；
2. 确定线业务是否有异常；
3. 后台任务是否正常：例如队列消费，定时任务的执行等。
4. 分析日志是否异常；
5. 梳理故障服务器上部署有哪些服务，以及这些服务的影响范围
第三：暴风过后，怎么调整
- 系统预警生效了么？
值班人员有没有值守岗位
核心关键系统，必须要制订值班制度
运维、研发人员是否在第一时间收到告警
如果没有收到，那么是为什么没有收到，是没有告警，还是告警覆盖缺失？
如果收到，是否及时按应急预案进行了操作
- 挑一个大的云服务商？
像阿里云，腾讯云这样的大品牌，虽然广告推广铺天盖地，但是在架构和服务上，与一些其他名气小一些的云服务商基本差不多，在针对性服务上甚至可能还不如一些专业做云服务的公司。具体取舍，需要用过才知道，不过最好就是选取一个备用的云服务商，万一down了一家，还有一家可以顶上去。比如主业务系统跑在阿里云上，备用系统就可以跑在性价比高一点的易迈云上面。
没有绝对的安全和可靠，这些都是相对的。
- 不相信云服务商的，自己搞一套机房。
投资成本：这个成本是否在可接受范围
可用性：自己托管在IDC机房的安全性和可靠性真的比云厂商高吗？
维护成本：需要一个庞大的IT团队来维护
- 异地多活，不要有单点故障存在。
在生产系统中，核心重要的系统一定要部署在两台服务器以上，避免出现单点故障。并且这2台部署服务器必须在不同可用区（或者干脆不同的数据中心），因为不同的可用区之间的电力、网络是独立的。
- 数据备份
数据备份有冷备、热备、本地备份、异地备份，更重要的是数据备份要具有可用性，而且一定要有可用性。
总之，在云平台上部署业务，并不是买几台云服务器部署上去就高枕无忧了，要根据自己的业务情况选择不同的方案。
后话：
对阿里云来说，这不是第一次故障，也不会是最后一次故障。对其他云服务提供商而言，阿里云发生的故障也会在自己身上不断重演。但对上云企业来说，“事故”的一次次发生不断地教训了自己，上云不能全靠云服务提供商，自己要考虑IT系统的高可用性，要考虑做容灾。
最后，数据一定要备份！！！ 要备份！！！要备份！！！！！！
