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

朱少民 软件质量报道 2017-03-03


2天前仅仅在Github发生质量事故(不得不谈谈农历新年首次质量大事故:GitLab丢失数据 ) 一个月之后亚马逊云(Amazon S3 Cloud )出现严重的宕机(中断服务)!亚马逊云之前也出现过宕机,但一般在一个小时之内解决问题,而这次非常严重,宕机整整四个小时,和Github事故有些巧合,Github事故则是丢失整整四个小时的数据。

 

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

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

 

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


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

 

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

 

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

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

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

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

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

  • ......

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

  • 流程控制如何?

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

  • 系统灾备如何?

  • 之前做过故障转移(fail-over)、恢复性测试吗?

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

  • ......

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


本站仅按申请收录文章,版权归原作者所有
如若侵权,请联系本站删除
觉得不错,分享给更多人看到
软件质量报道 热门文章: