Amazon S3 云存储莫名消失的原因：一个脚本引发的冷笑话
一枚码工同仁写了一个脚本准备删除几个host，但是这个脚本不小心犯了个很大的错误，最终把几乎s3在us east 1区的所有host都删了，类似于当年nvidia的死亡脚本：一个空格引发的悲剧（详解如何看懂悲催的技术人员冷笑话）。这个脚本价值好几个亿啊！
美国时间 2 月 28 日，由于亚马逊 AWS 弗吉尼亚州数据中心出现故障，使得其云服务 S3 出现了较高的错误率，直接影响到成千上万个在线服务。
据悉，受到影响的网站服务有 Netflix、Airbnb 、Slack、Spotify 等，部分丢失了镜像，部分处于半运行状态。大批使用 S3 来存储图片的媒体网站，以及 Runkeeper、Trello 和雅虎网络邮箱都无一幸免。甚至包括智能家居控制系统如亚马逊自身旗下的 Alexa 也正在挣扎着保持能够上线，而 Nest 的应用程序则在一段时间内完全无法连接到恒温器和其他智能设备。
直到美国太平洋时间14:08 后，亚马逊才在网站上宣布，S3 恢复正常。Amazon亚马逊公司在周四把导致这一现象的原因归咎于人为失误。
S3云存储计费系统的团队在试图解决一些付款系统的小bug之际。一位工程师本来想移除一小部分服务器，没想到失误搞大了，因输入了错误的命令，使一组服务器被删除，而删除的服务器支持另外两个S3子系统也意外的被删除。此次事故影响的服务器比预期更多，避免不了引发了一系列故障，最终导致S3和其他Amazon服务器短暂瘫痪。
由于AWS为不少大型网站和应用提供云服务支持，这一问题似乎波及了一众公司或机构：
Adobe的服务、亚马逊的Twitch、Atlassian的Bitbucket、Buffer、Business Insider、Chef、Citrix、Codecademy、Cousera、Cracked、Docker、Expedia、Expensify、Giphy、Heroku、Home Chef、iFixit、IFTTT、Imgur、http://isitdownrightnow.com、Lonely Planet、Mailchimp、Medium、微软的HockeyApp、News Corp、Pantheon、Quora、Razer、Signal、Slack、Sprout Social、Travis CI、Trello、Twilio、Unbounce、美国证券交易委员会以及其他许多公司的服务。Airbnb、Down Detector、Freshdesk、Pinterest、SendGrid、Snapchat的Bitmoji和Time Inc等网站也变得非常缓慢。
根据Cyence公司（一家专门估算网络风险的初创公司），AWS中断使S＆P 500指数公司的指数为1.5亿美元。Apica Inc.是一家网站监控公司，该网站的前100家零售商中的54家网站的网站性能下降了20％以上。
亚马逊解释：“虽然这个过程以及运行必要的安全检查所花的时间超过了预期，但我们已经修改了此工具并增加保护措施，以防止服务器容量下降太快或低于最低水平。”
AWS S3服务中断的简要说明
我们想为大家透露另外一些信息，解释2月28日上午出现在北弗吉尼亚（US-EAST-1）区域的服务中断事件。
亚马逊简单存储服务（S3）团队当时在调试一个问题，该问题导致S3计费系统的处理速度比预期来得慢。太平洋标准时（PST）上午9：37，一名获得授权的S3团队成员使用事先编写的playbook，执行一条命令，该命令旨在为S3计费流程使用的其中一个S3子系统删除少量服务器。
遗憾的是，输入命令时输错了一个字母，结果删除了一大批本不该删除的服务器。不小心删除的服务器支持另外两个S3子系统。其中一个系统是索引子系统，负责管理该区域所有S3对象的元数据和位置信息。这个子系统是服务所有的GET、LIST、PUT和DELETE请求所必可不少的。第二个子系统是布置子系统，负责管理新存储的分配，它的正常运行离不开索引子系统的正常运行。在PUT请求为新对象分配存储资源过程中用到布置子系统。删除相当大一部分的容量导致这每个系统都需要完全重启。
这些子系统在重启过程中，S3无法处理服务请求。S3 API处于不可用的状态时，该区域依赖S3用于存储的其他AWS服务也受到了影响，包括S3控制台、亚马逊弹性计算云（EC2）新实例的启动、亚马逊弹性块存储（EBS）卷（需要从S3快照获取数据时）以及AWSLambda。
S3子系统是为支持相当大一部分容量的删除或故障而设计的，确保对客户基本上没有什么影响。我们在设计系统时就想到了难免偶尔会出现故障，于是我们依赖删除和更换容量的功能，这是我们的核心操作流程之一。虽然自推出S3以来我们就依赖这种操作来维护自己的系统，但是多年来，我们之前还没有在更广泛的区域完全重启过索引子系统或布置子系统。
过去这几年，S3迎来了迅猛发展，重启这些服务、运行必要的安全检查以验证元数据完整性的过程所花费的时间超出了预期。索引子系统是两个受影响的子系统中需要重启的第一个。到PST 12：26，索引子系统已激活了足够的容量，开始处理S3 GET、LIST和DELETE请求。到下午1：18，索引子系统已完全恢复过来，GET、LIST和DELETE API已恢复正常。S3 PUT API还需要布置子系统。索引子系统正常运行后，布置子系统开始恢复，等到下午1：54已完成恢复。至此，S3已正常运行。受此事件影响的其他AWS服务开始恢复过来。其中一些服务在S3中断期间积压下了大量的工作，需要更多的时间才能完全恢复如初。
由于这次操作事件，我们在做几方面的变化。虽然删除容量是一个重要的操作做法，但在这种情况下，使用的那款工具允许非常快地删除大量的容量。我们已修改了此工具，以便更慢地删除容量，并增加了防范措施，防止任何子系统低于最少所需容量级别时被删除容量。这将防止将来不正确的输入引发类似事件。我们还将审查其他操作工具，确保我们有类似的安全检查机制。我们还将做一些变化，缩短关键S3子系统的恢复时间。我们采用了多种方法，让我们的服务在遇到任何故障后可以迅速恢复。最重要的方法之一就是将服务分成小部分，我们称之为单元（cell）。工程团队将服务分解成多个单元，那样就能评估、全面地测试恢复过程，甚至是最庞大服务或子系统的恢复过程。
随着S3不断扩展，团队已做了大量的工作，将服务的各部分重新分解成更小的单元，减小破坏影响、改善恢复机制。在这次事件过程中，索引子系统的恢复时间仍超过了我们的预期。S3团队原计划今年晚些时候对索引子系统进一步分区。我们在重新调整这项工作的优先级，立即开始着手。
从这起事件开始一直到上午11：37，我们无法在AWS服务运行状况仪表板（SHD）上更新各项服务的状态，那是由于SHD管理控制器依赖亚马逊S3。相反，我们使用AWS Twitter帐户（@AWSCloud）和SHD横幅文本向大家告知状态，直到我们能够在SHD上更新各项服务的状态。我们明白，SHD为我们的客户在操作事件过程中提供了重要的可见性，我们已更改了SHD管理控制台，以便跨多个AWS区域运行。
最后，我们为这次事件给广大客户带来的影响深表歉意。虽然我们为亚马逊S3长期以来在可用性方面的卓越表现备感自豪，但我们知道这项服务对客户、它们的应用程序及最终用户以及公司业务来说有多重要。我们会竭力从这起事件中汲取教训，以便进一步提高我们的可用性。（*该说明编译来源云头条 ID:YunTaoTiao）
云计算厂商还是尽量不要标榜自己的服务可用性99.999999%,然而剩下的哪一点点点挂掉的几率还是存在的。AWS在云计算行业内已经是首屈一指了，然而也并不能真正做到永远不出问题。或许我们在没有永远靠谱的情况下，只能选择尽量靠谱。
©转载请联系本公众号
更多精彩阅读请点击：
IT 战略家
这里不打算迎合任何人的三观
但可以保证提供有深度的思考
把握趋势，洞见未来
长按二维码关注