如今 2017 年，云是重要业务技术选型的***选择。使用云也为管理基础设施带来了很多益处，包括提升灵活性、可扩展性，同时降低了 IT 成本。但是上周我们目睹了 AWS S3 停机故障 ，看来即使是最可靠的服务提供商也可能遇到倒霉的一天。 服务不可用直接导致了数百万的收入损失，以及难以估量的公司品牌负面影响。尽管如此，你依然可以采取一些预防措施来减少这种事件的负面影响。
事故报告
亚马逊 Web 服务(AWS)是当今被广泛使用的的云基础设施服务，占据全球40%以上的市场份额。一直以来 AWS 的服务质量都高于其服务质量协议(SLA) ，达到99.9%的正常运行时间。但是上周发生的 AWS 简单对象存储服务(S3)故障说明没有什么服务是***无懈可击的。
在星期二上午 11:30 左右，AWS 美国东一区(US-EAST-1)的 S3 存储服务宕机，并且迅速产生了巨大的影响。 服务恢复后，AWS 发布了一个声明，有意思的是，我们从官方声明中发现，这次故障既不是人为破坏的，也是不是系统损坏的原因，而仅仅是由简单的错误输入命令导致。 难以置信吧?但确实是，一个完全无意的命令输入错误 [1]，这导致像 Adobe，Slack，Expedia，甚至是美国证券交易委员会，都遭受了严重的性能影响，据悉还有小的在线电商网站因此被拖垮。
目前很难准确估量在这将近 5 个小时的宕机过程中造成的财产损失，但据不完全统计，已经造成了数千万的财产损失，数十万的用户受到影响。
事故真相
整个事故过程中，虽然许多依赖美国东一区 S3 服务的公司在宕机期间受到严重影响，但仍然有一些公司部分或全部业务毫不受影响。 这是为什么? 有几个因素发挥作用。
隐藏的依赖
S3 服务已经成为大多数基于云的分布式系统中至关重要的组件。正因为其被广泛使用，同时大量复杂的服务或系统构建在它之上，所以当 S3 服务不可用时加剧了事故影响范围和深度。对于那些直接或间接依赖(S3 服务) 的系统，S3 服务都会成为潜在的影响因素。
网络性能监控公司 Thousand Eyes 归纳了 3 种可能被所依赖的 S3 服务影响的表现形式：
- 如果一个公司的静态网页直接或单独托管在宕机的 S3 服务器上，那么将变得完全不可用。很不幸，Lululemon Athletica Inc 是这类公司之一。
- 如果页面中的某些元素(脚本、资源)直接或间接依赖于 S3 服务，则会发生部分失效。比如Slack，事故造成它的文件上传功能变得不可用。
- 应用程序的关键服务可能依赖于受影响的 S3 或其他 AWS 服务，这将导致应用部分或完全无法使用。8th Light 的创始人之一介绍了他对 AWS Lambda 功能的使用，通过它可以实现 rate limit 功能以限制用户恶意请求，但在宕机期间它变得无法使用，因为该功能依赖 S3 服务。***他给出了一条建议：“清楚的认识你依赖的依赖。“
滑稽的是，事故刚开始发生时，AWS 无法将 S3 服务状态更新到仪表板上，因为它也依赖于 S3 来存储。这意味着出现故障的服务在宕机期间显示为正常?!这就是我们说的隐藏的依赖!
这里我们强调的是要知道风险在哪里，并做有针对性得规划。 将每个远程依赖关系都看作是潜在的故障点这会有所帮助，特别是以这次 AWS 事故为例，对远程依赖关系的分析首先将会帮你反思是否真的有依赖的必要。
装满鸡蛋的篮子
AWS 的数据中心(zone)遍布全球 16 个不同的国家地区。在美国，有四个地区：北弗吉尼亚州、俄亥俄州、俄勒冈州和北加利福尼亚州，剩下的则分布在欧洲、亚洲、南美洲和澳大利亚。
在 AWS 上部署/使用服务时，可以选择要部署到哪个独立区域。显而易见，通过跨地区、或者跨云服务提供商来创造冗余，将提供最健壮的业务连续性。在这次事故中，只有一个区(美国东一区)受到影响，但对那些资源/服务/依赖集中在这个区的公司来说，这便成他们的噩梦。
为故障而设计
前面提到，一些公司在这次事故中损失较小。这是因为他们部署服务时，带着某一天某些事会出错的预期，从而更有针对性得做准备。
虽然 AWS 正在处理此次事故的后续事宜，但是亚马逊的零售部门(amazon.com)，尽管依赖 S3，但在事故期间并没有受多大影响。诚然，亚马逊在任何时候都会采取所有必要和建议的预防措施，以确保其旗舰产品的健壮。
如何为故障做规划和预防，我们可以参考 Netflix。他们内部使用一套被称为猴子军团(Simian Army)的云测试工具，这些工具专门用于模拟系统上的破坏，以便捕获可能导致服务中断或性能问题的任何潜在故障点。通过规划一系列可能遇到的小问题和大问题，Netflix 能够预测他们系统面对问题时反应，并依此建立各种保护措施，以确保系统在故障期间依然可以提供服务。
应对故障的准备措施不应采取”一刀切“的方法。亚马逊和 Netflix 都拥有海量的数据、数亿用户，他们的预防措施和解决方案可能有很大不同。在决定如何防止第三方故障时，应考虑诸如数据容量，针对不同情况进行防护的性价比，以及计算损失风险等因素。
对于较小的规模，解决方案可能不是完全预防，而是如何优雅的降级。这意味着需要对应用中各个功能进行不同优先级的容错。例如网络故障时，对于需要远程访问的资源降级成从本地文件/缓存中获取。
S3事故也暴露了网络架构设计的缺陷，AWS 官方提出了未来防止这类事故的举措，也表态采取更多的预防措施来保护客户们的业务不受损失是十分重要且明智的。
好了，上星期我们学到了“一个错误输入可以使得一部分互联网不可用”，现在我们学到了更好更充分的准备和预防，可以***程度减少故障再次发生时的损害和影响。
