一个简单的误操作可以毁灭互联网？

2天前， 仅仅在Gitlab发生质量事故（不得不谈谈农历新年首次质量大事故：GitLab丢失数据 ） 一个月之后，亚马逊云（Amazon S3 Cloud ）出现严重的宕机（中断服务）！亚马逊云之前也出现过宕机，但一般在一个小时之内解决问题，而这次非常严重，宕机整整四个小时。

在其主要服务中断大约48小时后，亚马逊找出造成问题的原因，并在今天通报了结果。居然是——亚马逊云web服务（AWS）的一些糟糕的工程师仅仅做了一个oopsie操作，就导致互联网搞崩溃：

在美国时间（PST）2月28日上午9:37，已获得授权的S3团队某个成员使用已建立的脚本（playbook）执行命令，该命令旨在删除S3计费过程所需要使用的S3子系统之中的少量服务器。不幸的是，命令的其中一个输入不正确，从而导致比预期更大的服务器集合被删除。

平常，我们买饮料时，你也可能按错了按钮，我们要可乐，你缺给了我们雪碧，那还好。但这次亚马逊事故，却不一样。这个可怜的亚马逊工程师，也仅仅敲错了一个键（和Gitlab事故也很巧合，仅仅是一个简单命令的误操作），却让AWS服务中断整整四个小时。要知道，全球互联网流量中大约有三分之一的流量要经过AWS服务器，可见问题多严重，那几个工程师很可能会被开除，卷着铺盖回家。

在行业内人士眼中，亚马逊提供的云服务产品非常稳定，公司的运维能力也很强，但是这次仅仅一个简单错误的操作就导致AWS服务中断几个小时，说明了我们的互联网如此脆弱，这也是给我们（云服务热）浇了一盆冷水，让我们警醒，云服务质量很关键，需要有更强的容错性和安全性，需要配置良好的保护和警示机制。

理论上，一系列故障保护措施可以将这类错误的影响控制在局部，但亚马逊说，涉及的一些关键系统多年没有完全重新启动，并且“花费比预期更长的时间”重新上线。

在这次灾难事件发生后，亚马逊会对云平台的运维会做些改变，例如会修改运维工具，不会像以前那样一次能删除大量的服务器。但一个工程师犯了一个简单错误（实际上，人总是会犯错误的），却导致重大质量事故，原因究竟何在？可能没有那么简单，可能还有许多未知的问题没有被解决，例如：

• 服务重新启动为什么会如此慢？

• 整个云平台是不是存在“单点失效”这样严重的问题？

• S3云平台是不是真正意义上基于全球的分布式系统？

• 删除关键服务器，没有审核和警示机制？

• ......
  

无论持续集成、DevOps多牛，终归我们需要回归质量管理的本质，还是需要审视我们的工作：

• 流程控制如何？

• 有没有review 和 audit (复查与审核) 机制？

• 系统灾备如何？

• 之前做过故障转移（fail-over）、恢复性测试吗？

• 其它命令的容错测试做得如何？
  

• ......
  

平台越大，影响越大，这时质量管理的投入也应该匹配。