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