2017年2月28日上午9点37分，美国东海岸的工程师按下一个回车键。接下来的4小时里，从Slack到Pinterest，从Quora到Imgur，半个互联网的图标开始转圈。
最讽刺的是，亚马逊自己的服务状态页面也挂了——它存在哪？存在S3上。系统崩溃时连"系统已崩溃"都通知不了，像火灾报警器装在同一个保险丝盒里。
一个整数引发的连锁反应
AWS事后报告写得克制：「调试过程中的人为失误」。翻译一下：某位工程师想关掉一小部分S3计费子系统的服务器，却在命令行里多敲了一个数字。
这个失误触发了级联删除。不是几台，是远比预期多得多的服务器被标记为"移除"。S3 US-EAST-1区域的核心子系统开始像多米诺骨牌一样倒下，速度比任何自动熔断机制都快。
修复花了4小时，不是因为找不到问题，而是因为系统设计的假设是"核心服务不会全挂"。重启需要手动步骤，而手册里没写"如果整个区域没了怎么办"。
代价账单与行业觉醒
直接经济损失估算在1.5亿美元到1.6亿美元之间，包括AWS退款和客户业务中断。但对行业的影响远超数字：那天之后，"韧性工程"从运维团队的PPT术语变成了董事会议题。
Netflix的混沌工程团队后来承认，他们当时正在测试区域故障转移，结果测试变成了实战。Trello的工程师在Reddit吐槽：「我们的备份策略假设S3不会同时失效，这个假设今天破产了。」
AWS的整改清单很长：限速机制、灰度发布、把状态页迁出S3。但最根本的变化是承认——再自动化的系统，最后一道防线还是人。而人会打错数字。
7年后的今天
现在的云架构师面试题里，"如果AWS US-EAST-1消失"成了必问题。多区域部署从"最佳实践"降级为"底线要求"，成本增加了，但没人敢再赌一个区域永不出事。
那个多敲的数字从未公开。AWS保护了当事人，只说是"一名授权员工"。但每个用过命令行的人都知道那种感觉：光标在闪，你在想"这个参数对吗"，然后手比脑子快。
2017年的那个周二证明了一件事：支撑现代互联网的，不是魔法，是无数行有人类指纹的代码。而人类会犯错。你的多区域备份策略，最近一次演练是什么时候？
热门跟贴