6月27日阿里云出现故障，导致用户在访问阿里云官网控制台和使用部分产品功能出现问题。
阿里云表示，故障从北京时间27日16:21左右开始，到16:50开始陆续恢复。故障起因是上线一个自动化运维新功能时，执行了一项变更验证操作，触发了一个未知代码bug，错误代码禁用了部分内部IP，导致部分产品访问链路不通。
阿里云称，“对于这次故障，没有借口，我们不能也不该出现这样的失误！我们将认真复盘改进自动化运维技术和发布验证流程，敬畏每一行代码，敬畏每一份托付。 ”
云厂商宕机故障，这些年一直不是什么新闻
2017 年 2 月 28 日，云计算巨头 AWS S3 故障，事件的起因是 AWS S3（云存储）团队在进行调试时输入了一条错误指令，本应该将少部分的 S3 计费流程服务器移除，可是最终意外移除了大量服务器。被错误移除的服务其中运行着两套 S3 的子系统，从而导致 S3 不能正常工作，S3 API 处于不可用状态。
由于 S3 负责存储文件，为 AWS 体系中的核心组成部分，这导致北弗吉尼亚日（美国东一）服务区中，依赖于 S3 存储服务的其他 AWS 的 S3 控制台、Amazon 弹性计算云（简称 EC2）新实例启动、Amazon 弹性块存储（简称 EBS）分卷（限于需要读取 S3 快照的数据）以及 AWS Lambda 均受到影响。
2017 年 3 月 22 日，微软云服务又一次宕机了。Outlook、 Hotmail、 OneDrive、 Skype 和 Xbox Live 都出现了网络故障，全球用户都无法登录。英国海岸和美国海岸城市的 Outlook 邮箱系统的用户受到的影响特别严重，同样悲惨的还有西欧与美国海岸线的美国 OneDrive 用户，西欧和巴西的 Skype 用户，及 Xbox 的英国、美国、西欧用户。Azure 用户的一天也不好过，一大批工程师无法登录系统。这不是微软最近第一次出现这种问题，上次是 3 月 7 日。
2015 年 6 月 6 日，QingCloud 广东 1 区全部硬件设备因遭遇雷暴天气引发电力故障，造成 QingCloud 官网及控制台短时无法访问、部署于 GD1 的用户业务暂时不可用。在业务恢复后，青云方面披露了合作运营商针对事故的调查原因：
1. 直击雷导致电力系统出现瞬时浪涌，UPS 启动自我保护，从而释放电流导致瞬间断电；
虽然机房配备了四级防雷，但主要是防止感应雷，对于此次直击雷，机房完全没有招架之力。
2014 年 11 月 2 日，腾讯云服务器出现了六分钟的访问故障。腾讯云平台部方面表示，此次访问故障主要是上海和广州机房的服务器出现故障，机房网络出口抖动造成的，而网络抖动是源于运营商网络信道阻塞，导致用户连接服务器出现丢包等现象。“这是网络上游的问题，并非机房本身硬件故障，所以无法避免该情况的发生。”云平台部方面负责人如是说。
纵观以上云厂商宕机案例，有的是天灾（机房被雷劈了），有的是人祸（误删除操作），但可以肯定的是：宕机这事儿，预计在很长的一段时间里都无法避免。那么对于吃瓜群众们来说，看完热闹了，要看会什么门道呢？
以 AWS S3 故障为例。
要注意Error Handling
当问题出现时，一个普通的 S3 GET 返回什么：
所以AWS 告诉你Internal Error 了。
从 error handling 的角度，在写代码的时候都应该捕捉这个异常，然后做合适的错误处理。很遗憾的是，S3 这样的服务是如此基础，就像互联网的水和电一样，大家默认为它永远不会出错。因此，好多工程师干脆不做错误处理。
除了代码编写层面的处理，当云服务商的宕机发生时，尽量控制它影响面。像 Trello连 landing page 都一并挂掉实在不可取，因为起码 S3 影响不到的页面，如 landing page，用户注册 / 登录页面，应该还保持正常服务；而像 Quora的服务，其实是可以准备一个静态化的镜像，一旦出问题，起码让读者可以无障碍地阅读。
尽可能地把动态内容缓存起来，甚至静态化
Redis cache、Nginx cache、HAProxy、CDN 都是把内容缓存甚至静态化的一些手段。尽管多级缓存维护起来是个麻烦，但当底层服务出现问题时，它们就是难得的战略缓冲区。cache 为你争取到的半个小时到几个小时几乎是续命的灵芝，它能帮你撑过最艰难的时刻（这次 S3 宕机前后大概 4 小时，最严重的时候是 11点到1点），相对从容地寻找解决方案，紧急发布新的页面，或者迁移服务，把损失降到最低。否则，只能像这次事件中的诸多公司一样，听天由命，双手合十祈祷 AWS 的工程师给力些解决问题。
云用户应检查核心依赖关系，提升关键性服务的冗余水平
S3是多种Amazon服务的核心组成部分之一。无论是利用其进行简单文件存储、对象存储抑或是用于存储网站或者应用程序中的内容，其间复杂的依赖性都必须会引发级联效应。S3能影响到的组件包括用户会话管理、媒体存储、内容存储、用户数据、第三方对象和自动化机制等。
云用户应检查核心依赖关系，提升关键性服务的冗余水平。AWS的系统在构建当中具备冗余特性，能够实现跨数据中心自动复制存储对象与文件。而作为另一种冗余层，云用户需要利用额外AWS服务区或者其它云服务供应商以彻底避免此类事故；不过这会增加大量管理复杂性与成本支出，因为跨环境间的数据同步工作需要由云用户负责打理。大多数企业并没有选择上述选项，可是单纯的数据备份在数小时的短周期内并不能发挥作用。
虽然面向云环境的迁移确实能够在稳定性与弹性方面为企业带来巨大帮助，但是各种不易被发现的依赖性也因此增加，单一服务失败可能引发大规模服务瘫痪。云用户的开发与运营团队审查与云服务供应商间的核心依赖关系，制定策略以监控各项服务可能受到的影响，同时调整现有架构以提升关键性用户的冗余水平。
故障演习很重要
对于这次事件，能在数小时恢复已属不易，并且幸运的是没有丢失重要数据。
一个系统的高可用的因素很多，不仅仅只是系统架构，更重要的是——高可用运维。并且，他认为对于高可用的运维，平时的故障演习是很重要的。AWS 平时应该没有相应的故障演习，所以导致要么长期不出故障，一出就出个大的让你措手不及。比如，Facebook每个季度扔个骰子，随机关掉一个IDC一天。Netflix 有 Chaos Monkey，路透每年也会做一次大规模的故障演练——灾难演习。
这种容错的操练适合大一些且工程团队有余力的公司。为什么Netflix 重度使用 AWS，却在历次 AWS 的宕机中毫发无损？其实Netflix之前也深深地被云的「不稳定性」刺痛过，而如今他们的 Chaos Monkey（之后发展为 simian army）服务，会随时随地模拟各种宕机情况，扰乱生产环境。比如说对于此次事件的演练，可以配置 simian army 去扰乱 S3：simianarmy.chaos.fails3.enabled = true。
这样，这群讨厌的猴子就会在不知情的情况下随机把服务器的 /etc/hosts 改掉，让所有的 S3 API 不可用。如此就可以体验平时很难遇到的 S3 不可访问的场景，进而找到相应的对策（注意：请在 staging 环境下谨慎尝试）。
处理危机的方式能看出一个公司的高度
GitLab、AWS这样向大众公开其故障及处理流程，哪怕起因是一个低级的人为错误，也不会掩盖、不会文过饰非。
如果你是一个技术公司，你就会更多的相信技术而不是管理。相信技术会用技术来解决问题，相信管理，那就只会有制度、流程和价值观来解决问题。没有人愿意看到问题的发生；但是问题出现后，最重要的解决反思并从中汲取教训：这难道不是技术人应有的傲骨吗？
你觉得呢？