例行命令依然是一次生产环境变更
操作人员是在按照既定手册操作,而非临场发挥——但一次打错的输入依然造成了超乎寻常的影响范围,这正是为何即便是"例行"运维命令,输入验证和影响范围限制也同样重要。
案例研究 · 2017年2月
一条打错的命令 让互联网的一角瞬间瘫痪。
在一次例行调试命令中输入了一个错误参数,导致从AWS S3子系统中移除的服务器数量远超预期——而重启过程耗时比预想的长得多,因为受影响的系统已多年未曾完全重启过。
向下滚动查看时间线
约4小时
US-EAST-1区域的持续时间
1.5亿美元
对标普500公司造成的估计成本
速览要点
一张表看懂事情经过。
来源已在正文中标注链接,包括AWS官方发布的事后总结报告。
日期
2017年2月28日,约太平洋时间上午9:37开始。
故障原因
一名经授权的工程师按照既定手册对S3计费系统进行调试,执行了一条本应只移除少量服务器的命令——但其中一个输入项被错误地输入,导致移除的服务器数量远超预期,并使两个核心S3子系统离线,据AWS官方总结所述。
影响规模
此次中断在US-EAST-1区域持续了大约四个小时,并波及互联网的大片区域,因为大量与之无关的网站、应用程序,甚至AWS自身的其他状态工具都依赖S3提供存储或配置服务——AWS甚至无法更新自己的服务状态仪表盘,因为该仪表盘本身也依赖于受影响的区域。
恢复瓶颈
受影响的子系统经过多年运行已变得极为庞大,以至于从未在如此规模下完全重启过,因此重启过程耗时远超预期——这是一个容量规划和运维测试上的缺口,而非最初错误的重演。
公布的成本
《华尔街日报》报道了网络风险建模公司Cyence的估算,称此次中断给标普500公司造成的总成本约为1.5亿美元——这是一个被广泛引用但由第三方建模得出的数字,并非各公司披露数据的汇总。
为何代价如此高昂
此次事件的影响范围,是整个互联网的依赖关系图。
这里产生的成本几乎没有一分属于计费子系统本身的AWS客户——它们属于所有其他在不知不觉中深度依赖S3的人。
从未重启过的系统,就是从未被测试过的系统
恢复耗时超出预期,正是因为受影响的子系统此前从未在当前规模下重启过——未经测试的恢复路径,是容量增长悄然埋下的MTTR(平均修复时间)隐患。
第三方依赖在出问题之前是隐形的
与AWS计费子系统毫无直接关系的公司也纷纷瘫痪,因为它们自身的基础设施在不知不觉中依赖着同一个区域存储层——这提醒我们,应该切实梳理,而非想当然地假设,自身面对单一供应商某个区域故障时的实际影响范围。
常见问题
关于AWS S3中断事件的解答。
在云依赖或供应商风险案例中引用此事件时常见的问题。
这是针对AWS的攻击吗?
不是——AWS将其归因于一次例行调试过程中的内部操作失误,而非任何外部攻击。
为何1.5亿美元这一数字是第三方估算,而非AWS的官方数字?
AWS不会为自身的中断事件发布成本估算;1.5亿美元这一数字来自Cyence的网络风险建模,并由《华尔街日报》报道,因此它只是一个方向性的参考值,而非经过审计的总额。
AWS事后做了哪些改进?
AWS的官方总结提到了对其工具的改进,包括防止容量被移除至最低所需水平以下的保护机制,以及子系统重启时间的优化。
轮到您了