AWS S3 服务中断：为什么几个人手输错一个参数，就能让大半个互联网的图片加载不出来？

# 商业复盘备忘录：AWS S3 服务中断

> 为什么几个人手输错一个参数，就能让大半个互联网的图片加载不出来？
> 周期: 2017 - 2017 | 行业: 企服与SaaS
> 巅峰: 全球规模最大的公有云服务商，其对象存储服务是互联网基础设施的关键组成，承载了大量网站、应用与备份数据
> 终局: 因运维操作输入参数错误导致大量存储与索引服务器被误移除，核心区域服务中断约四小时，波及大量互联网服务与其自家控制台

## 核心概览
工具的自动化程度很高，但护栏只做到了「提醒」，没做到「拦住」。巅峰期全球规模最大的公有云服务商，其对象存储服务是互联网基础设施的关键组成，承载了大量网站、应用与备份数据；终局是因运维操作输入参数错误导致大量存储与索引服务器被误移除，核心区域服务中断约四小时，波及大量互联网服务与其自家控制台。

## 社区公投头号死因
1. [产品技术] 工具缺少阻止越界输入的强制校验 (946 票)
2. [组织管理] 关键操作缺少分级审批 (795 票)
3. [战略决策] 状态页依赖被监控的服务本身 (643 票)

## 可执行教训
### 高影响操作的安全护栏必须是硬性拦截，不能只是提醒
> 人会犯错，所以要把错误拦在动手之前。

- ✅ 推荐做 (DOs):
  - 对高影响操作设置输入范围的强制校验
  - 让对内对外状态页独立于被监控的服务
- ❌ 绝不能做 (DON'Ts):
  - 不要把「有提示」当作有防护
  - 不要在沟通渠道上与被监控系统共用依赖

## 救亡方案
### 先给高影响操作装硬护栏，再谈容量自动化 — 良略编辑部
干预时点: 2017 年 2 月 28 日误操作导致核心区域大规模中断后
- 必须断腕:
  - 暂停高影响范围的自动化容量操作
  - 停止把状态页部署在被监控的同一服务上
  - 停止让提示性校验承担防护职责
- 破局动作:
  - 对高影响操作设置输入范围强制校验与分级审批
  - 把对外状态页与监控体系部署在独立环境
  - 客户与自家关键服务逐步分散到多个区域
- 预期结果: 误操作在执行前被硬性拦截，即使发生也能通过独立渠道快速对外沟通，避免大范围服务中断。

## 社区见解
### 自动化不会犯错，它只会忠实地执行你输进去的错。 — 良略编辑部 (工程师)
这次事故的原因朴素到近乎尴尬：操作人员输入的参数超出了预期范围，工具按参数执行了远超计划的移除操作。工具里其实有提示，但提示拦不住人。真正需要的是把「输入范围」变成硬约束——超过阈值就直接拒绝执行或强制走审批。另一个被忽视的角度是：官方状态页也依赖同一服务，于是故障期间客户连「出了什么事」都查不到。
- 如果重来一次的纠偏招式 越是危险的自动化操作，越需要一层不给解释余地的护栏。

---
来源: 良略 · https://www.lianglue.com/c/aws-s3-outage