上周二，因为一条错误指令导致的 AWS 宕机事件，影响了大量流行的网站和服务。此事件对用户来说，是服务的中断；对 AWS 来说，是巨额的损失；对旁观者来说，是宝贵的经验。
编者按
想象一下：一个工作日的上午，你使用的云服务的可用性瞬间从平均水平跌至 0；丢包率则上升到 100%。作为一名用户，你会做出怎样的判断？这应该不是著名的 DDoS 攻击，因为在遭遇 DDoS 攻击时，丢包率与可用性是随着时间推移而发生变化的。而这种瞬间的停机现象应该是云服务商出现了故障。
上个周二，云计算鼻祖 AWS 就发生了这样的事故。AWS 美国东一服务区基础设施的出入流量瞬间消失。那么，AWS 是如何解决这次事故？接下来会有哪些优化举措？技术人应该从中学习到什么经验？
事件回顾
2 月 28 日上午（太平洋时间）AWS 发生了服务宕机事件。事件的起因是 AWS S3（云存储）团队在进行调试时输入了一条错误指令，本应该将少部分的 S3 计费流程服务器移除，可是最终意外移除了大量服务器。被错误移除的服务其中运行着两套 S3 的子系统，从而导致 S3 不能正常工作，S3 API 处于不可用状态。
由于 S3 负责存储文件，为 AWS 体系中的核心组成部分，这导致北弗吉尼亚日（美国东一）服务区中，依赖于 S3 存储服务的其他 AWS 的 S3 控制台、Amazon 弹性计算云（简称 EC2）新实例启动、Amazon 弹性块存储（简称 EBS）分卷（限于需要读取 S3 快照的数据）以及 AWS Lambda 均受到影响。
AWS 的修复动作
一条错误命令直接导致了 AWS 两套子系统无法工作：
- 第一套子系统为索引子系统（Index）：负责管理该服务区内全部 S3 对象的元数据与位置信息。此子系统为一切 GET、LIST、PUT 与 DELETE 请求正常运作的必要基础。
- 第二套子系统为位置子系统（Palcement）：负责管理新存储空间的分配并需要配合之前的索引子系统以实现正常运作。这套位置子系统用于在响应 PUT 请求时为新对象分配存储空间。
两套子系统容量被大量移除，发生故障重启，但是 S3 依然无法正常响应请求。位置子系统依赖于索引子系统，因此 AWS 选择了按照顺序修复两个子系统，再解决 S3 和其他服务的问题。
哪些用户受到了影响？
S3 于 2006 年发布，是 AWS 最早的诸多服务之一，官方曾称其具备 99.999999999% 的持久性（durability）和 99.99% 的可用性（availability）。
它的一些典型使用场景如下：
- 存储用户上传的文件，如头像，照片，视频等静态内容
- 静态网站的托管
- 当作一个的 key value store，承担简单的数据库服务功能
- 数据备份
- 大数据分析
S3 拥有很多明星用户：Airbnb（处理超过 10PB 的用户图像）、Nasdaq（支持 FinQloud 的监管记录保留 (R3) 数据存储解决方案和 Query）、Netflix（分发数十亿小时的内容）。
此次事故波及众多公司，外媒的统计名单中 A-Z 的 26 个字母全部占满，其中包括 Adobe、Docker、GitHub、Slack、GE、Quora 等知名公司。在此期间，部分 Apple 用户们也受到影响；不过苹果一直在打造自己的数据中心，报道称苹果预计斥资五千余万美元进行数据中心的扩建。
对 AWS 而言，这次事故意味着？
Thousandeyes 公司是 AWS S3 的使用者，产品营销高级主管 Nick Kephart 在接受采访中认为，根据 S3 服务水平协议，此次停机（持续达 3 小时）可能意味着 S3 已经无法达到协议中指定的 99.9% 正常运行阈值。因此，美国东一服务区内最具人气的 S3 服务以及其它受影响 AWS 服务可能给 Amazon 带来高达 10% 的月度营收影响。根据粗略估算，这一服务水平协议违约可能造成数百万乃至数千万美元的损失。
AWS 在 Amazon 公司的财务构成当中扮演着越来越重要的角色；2016 年第四季度，AWS 为其母公司贡献了高达 35.3 亿美元营收，利润则为 9.26 亿美元。
其实除了经济损失之外，这也不失为 AWS 的技术学习机会。
AWS 的技术反思
为什么这么久？
存储量庞大
AWS 在其官方声明中成虽然 S3 子系统的有故障承受能力，但是此次事故中涉及的两个子系统再数年来在大规模服务区未曾重启。S3 的服务规模快速提升，而对这些服务进行重启并运行必要安全检查以验证元数据完整性，这些流程最终所需时间远超 AWS 预期。对于此说法，曾经在 Amazon 工作过的陈皓表示认同，他称 AWS 没有公布的存储数量级相当惊人；要先恢复索引子系统再恢复位置子系统，就像个人的操作系统从异常关机后启动，文件系统要做系统自检那样，硬盘越大，文件越多，这个过程就越慢。
服务没有被拆分成更小
同时 AWS 表示，服务需要被进一步分解成更小的单元：S3 团队已经计划于今年晚些时候对该索引子系统进一步拆分，很可能立刻着手进行。
为什么 Dashboard 失效？
从此次事故开始直到上午 11：37（太平洋时间），AWS 服务运行状态仪表板（简称 SHD）上一直无法更新各项个别服务的运行状态，这是由于该仪表板的管理控制台运行依赖于 Amazon S3。因此，AWS 转而使用 AWS Twitter Feed（@AWSCloud）与 SHD 横幅通知文本发布状态更新，直到重新恢复在 SHD 之上更新个别服务状态的能力。AWS 表示其了解 SHD 在业务运行期间为客户提供提示信息的重要意义，因此目前已经将 SHD 管理控制台调整为跨多个 AWS 服务区运行。
改进措施？
AWS 在此次官方声明中不仅公布事故起因、解决过程，而且分析了技术问题并决定了改进措施。大致分为以下两个方面：
事故的发生：大量移除操作不应该如此容易
AWS 称其正在根据此项事故进行数项调整，尽管移除容量属于一项关键性操作实践；但在目前的情况下，AWS 使用的工具在移除容量时的执行速度过快，已经对此工具进行了修改以更慢进行容量清除。同时，AWS 增加了安全措施以防止任何子系统在容量移除后遭遇现有容量低于最低容量需求的情况。此外，AWS 也在审查当前使用的其它操作工具，以确保在其中引入类似的安全检查机制。
事故发生后：恢复时间不应该如此漫长
AWS 会采以多种技术以确保服务能从任何故障中迅速恢复，其中最为重要的举措之一在于将服务拆分成更小分区（AWS 将其称为 Cell）。通过将服务进一步分解为 Cell，工程技术团队能够评估并全面测试各类大规模服务或子系统的恢复流程。
吃瓜群众应该从中学到什么？
AWS 的官方声明最后一段写到：“最后，我们要对此次事故给客户造成的影响诚挚道歉。虽然我们对于 Amazon S3 长期以来的可用性表现感到自豪，但我们清楚这项服务对于我们的客户、其应用程序、最终用户以及业务的重要意义。我们将尽一切努力从这次事件中积累经验教训，并以此为基础进一步提升我们的服务可用性。”
那么，对于其他人而言，从这次事故中我们能学到什么呢？InfoQ 收集整合了三位技术专家陈皓、陈天、Nick Kephart 给出的思考整理如下：
要注意 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 能影响到的组件包括用户会话管理、媒体存储、内容存储、用户数据、第三方对象和自动化机制等。
在 Thousandeyes 公司的 Nick Kephart 看来，云用户应检查核心依赖关系，提升关键性服务的冗余水平。AWS 的系统在构建当中具备冗余特性，能够实现跨数据中心自动复制存储对象与文件。而作为另一种冗余层，云用户需要利用额外 AWS 服务区或者其它云服务供应商以彻底避免此类事故；不过这会增加大量管理复杂性与成本支出，因为跨环境间的数据同步工作需要由云用户负责打理。大多数企业并没有选择上述选项，可是单纯的数据备份在数小时的短周期内并不能发挥作用。
虽然面向云环境的迁移确实能够在稳定性与弹性方面为企业带来巨大帮助，但是各种不易被发现的依赖性也因此增加，单一服务失败可能引发大规模服务瘫痪。Nick 建议云用户的开发与运营团队审查与云服务供应商间的核心依赖关系，制定策略以监控各项服务可能受到的影响，同时调整现有架构以提升关键性用户的冗余水平。
故障演习很重要
对于这次事件，陈皓在其博客中表示美国东一区作为老牌的服务区拥有海量对象，能在数小时恢复已属不易，并且幸运的是没有丢失重要数据。
陈皓重申了其观点：一个系统的高可用的因素很多，不仅仅只是系统架构，更重要的是——高可用运维。并且，他认为对于高可用的运维，平时的故障演习是很重要的。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 这样向大众公开其故障及处理流程，哪怕起因是一个低级的人为错误，也不会掩盖、不会文过饰非。AWS 公布的后续改进方案都是为了让系统更加高可用，这是很技术范儿的表现。恐怕对比国内公司对于此类故障，基本上会是下面这样的画风：更多更为严格的变更和审批流程，限制更多的权限系统和审批系统，更多的人进行操作，使用更为厚重的测试和发布过程，惩罚故障人，用价值观教育工程师。
在陈皓看来——如果你是一个技术公司，你就会更多的相信技术而不是管理。相信技术会用技术来解决问题，相信管理，那就只会有制度、流程和价值观来解决问题。（注意：并非隔离技术和管理，只是更为倾向于用技术解决问题）
事故发生后，InfoQ 联系了 AWS 工作人员并表达了采访意愿。AWS 虽然最终婉拒，但是称媒体的客观报道可以督促其提升技术服务质量。
这段时间，IT 界尤其是大公司发生的技术故障并不少见。当 IT 技术服务越来越多的人的时候，宕机之事也自然也会影响并引得广泛的关注。众目睽睽之下，如 GitLab 和 AWS 这样保持坦诚踏实的态度，其实是在用另一种方式赢得对技术的尊重。没有人愿意看到问题的发生；但是问题出现后，最重要的解决反思并从中汲取教训：这难道不是技术人应有的傲骨吗？
参考文章
暂无签名
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论