AWS S3 服务中断：为什么几个人手输错一个参数，就能让大半个互联网的图片加载不出来？
工具的自动化程度很高，但护栏只做到了「提醒」，没做到「拦住」
AWS S3 服务中断：巅峰期全球规模最大的公有云服务商，其对象存储服务是互联网基础设施的关键组成，承载了大量网站、应用与备份数据；终局是因运维操作输入参数错误导致大量存储与索引服务器被误移除，核心区域服务中断约四小时，波及大量互联网服务与其自家控制台。
全球规模最大的公有云服务商，其对象存储服务是互联网基础设施的关键组成，承载了大量网站、应用与备份数据
因运维操作输入参数错误导致大量存储与索引服务器被误移除，核心区域服务中断约四小时，波及大量互联网服务与其自家控制台
2,876 votes cast
1 plans · 1 insights
投稿会先进入待审，通过后才进入公开目录和站点地图。
Root Causes Consensus Poll
Vote for the primary fatal error that caused this enterprise to collapse.
工具缺少阻止越界输入的强制校验
提示存在但不足以拦住错误参数，自动化把错误放大
关键操作缺少分级审批
高影响范围的容量操作没有按影响面分级管控
状态页依赖被监控的服务本身
对外沟通渠道与被监控系统同源，故障时失去信息出口
单区域依赖程度过高
大量客户与其自家服务集中在同一区域，风险未被充分分散
Timeline: peak to collapse
误操作执行
容量调整操作中输入参数超出预期范围，大量存储与索引服务器被同时移除
服务大面积中断
核心区域的对象存储服务不可用，大量依赖它的网站与应用出现故障
控制台受影响
由于内部状态页也依赖同一服务，客户在一段时间内无法从官方渠道获取状态信息
整改
公司为相关操作增加输入范围的强制校验与更细粒度的操作限制
Four-Dimensional Retrospective Breakdown
Background & Golden Era
公司以高可用与弹性为核心卖点，其对象存储服务被广泛用于网站静态资源、备份与应用数据，许多互联网公司的架构深度依赖这一服务巅峰期的成绩单是：全球规模最大的公有云服务商，其对象存储服务是互联网基础设施的关键组成，承载了大量网站、应用与备份数据。此时的它拥有渠道、品牌与资本的合力，看起来没有任何理由会输。
Fatal Turning Point Miscalculation
在一次例行容量移除操作中，工程师输入的参数超出了预期范围，导致远超计划数量的服务器被同时下线；相关工具虽然有提示，但缺少能阻止这类输入越界的强制校验底层架构的缺陷被增长掩盖了很多年，真正爆发时表现为线上事故、体验崩塌与迭代停滞，修复成本远高于当年重做的代价。
Internal Culture & Bureaucratic Hubris
技术决策长期被短期交付目标绑架，「先上线，以后再改」变成永久状态，没人对架构健康度负责。
The Collapse & Aftermath
因运维操作输入参数错误导致大量存储与索引服务器被误移除，核心区域服务中断约四小时，波及大量互联网服务与其自家控制台。AWS S3 服务中断的结局不是某一次意外，而是上面这些判断在数年里不断叠加、又始终没有被纠正的必然结果。
Battle-Tested Actionable Survival Rules
Distilled practical DOs and DONTs forged from costly corporate catastrophes.
高影响操作的安全护栏必须是硬性拦截，不能只是提醒
人会犯错，所以要把错误拦在动手之前。
- •对高影响操作设置输入范围的强制校验
- •让对内对外状态页独立于被监控的服务
- •不要把「有提示」当作有防护
- •不要在沟通渠道上与被监控系统共用依赖
Revival Simulation: If you were the CEO at the inflection point, how would you save it?
History cannot be rewritten, but executive decision-making can be honed. Propose decisive divestitures and strategic bets, and let entrepreneurs & VCs vote on feasibility.
先给高影响操作装硬护栏，再谈容量自动化
Critical intervention point：2017 年 2 月 28 日误操作导致核心区域大规模中断后
- •暂停高影响范围的自动化容量操作
- •停止把状态页部署在被监控的同一服务上
- •停止让提示性校验承担防护职责
- •对高影响操作设置输入范围强制校验与分级审批
- •把对外状态页与监控体系部署在独立环境
- •客户与自家关键服务逐步分散到多个区域
可靠性投入按影响面分级配置，关键操作的安全护栏列为上线前置条件。
误操作在执行前被硬性拦截，即使发生也能通过独立渠道快速对外沟通，避免大范围服务中断。
Expert Post-Mortem Insights
Firsthand diagnostic analyses from entrepreneurs, VCs, alumni, and analysts.
这次事故的原因朴素到近乎尴尬：操作人员输入的参数超出了预期范围，工具按参数执行了远超计划的移除操作。工具里其实有提示，但提示拦不住人。真正需要的是把「输入范围」变成硬约束——超过阈值就直接拒绝执行或强制走审批。另一个被忽视的角度是：官方状态页也依赖同一服务，于是故障期间客户连「出了什么事」都查不到。
越是危险的自动化操作，越需要一层不给解释余地的护栏。
Business Post-Mortem Memo · AWS S3 服务中断
为什么几个人手输错一个参数，就能让大半个互联网的图片加载不出来？
# Business Post-Mortem Memo：AWS S3 服务中断 > 为什么几个人手输错一个参数，就能让大半个互联网的图片加载不出来？ > Period: 2017 - 2017 | Industry: Enterprise SaaS > Peak: 全球规模最大的公有云服务商，其对象存储服务是互联网基础设施的关键组成，承载了大量网站、应用与备份数据 > Final: 因运维操作输入参数错误导致大量存储与索引服务器被误移除，核心区域服务中断约四小时，波及大量互联网服务与其自家控制台 ## Overview 工具的自动化程度很高，但护栏只做到了「提醒」，没做到「拦住」。巅峰期全球规模最大的公有云服务商，其对象存储服务是互联网基础设施的关键组成，承载了大量网站、应用与备份数据；终局是因运维操作输入参数错误导致大量存储与索引服务器被误移除，核心区域服务中断约四小时，波及大量互联网服务与其自家控制台。 ## Top-voted root causes 1. [Product & Tech] 工具缺少阻止越界输入的强制校验 (946 votes) 2. [Org & Culture] 关键操作缺少分级审批 (795 votes) 3. [Strategy] 状态页依赖被监控的服务本身 (643 votes) ## Actionable lessons ### 高影响操作的安全护栏必须是硬性拦截，不能只是提醒 > 人会犯错，所以要把错误拦在动手之前。 - ✅ DOs: - 对高影响操作设置输入范围的强制校验 - 让对内对外状态页独立于被监控的服务 - ❌ DON'Ts: - 不要把「有提示」当作有防护 - 不要在沟通渠道上与被监控系统共用依赖 ## Revival plans ### 先给高影响操作装硬护栏，再谈容量自动化 — 良略编辑部 Intervention: 2017 年 2 月 28 日误操作导致核心区域大规模中断后 - Must cut: - 暂停高影响范围的自动化容量操作 - 停止把状态页部署在被监控的同一服务上 - 停止让提示性校验承担防护职责 - Breakthrough moves: - 对高影响操作设置输入范围强制校验与分级审批 - 把对外状态页与监控体系部署在独立环境 - 客户与自家关键服务逐步分散到多个区域 - Expected outcome: 误操作在执行前被硬性拦截，即使发生也能通过独立渠道快速对外沟通，避免大范围服务中断。 ## Community insights ### 自动化不会犯错，它只会忠实地执行你输进去的错。 — 良略编辑部 (工程师) 这次事故的原因朴素到近乎尴尬：操作人员输入的参数超出了预期范围，工具按参数执行了远超计划的移除操作。工具里其实有提示，但提示拦不住人。真正需要的是把「输入范围」变成硬约束——超过阈值就直接拒绝执行或强制走审批。另一个被忽视的角度是：官方状态页也依赖同一服务，于是故障期间客户连「出了什么事」都查不到。 - Alternative Move if Replayed 越是危险的自动化操作，越需要一层不给解释余地的护栏。 --- Source: 良略 · https://www.lianglue.com/c/aws-s3-outage