AWS S3误操作，官方故障回顾及专家深度思考

继gitlab的误删除数据事件没几天，“不沉航母” aws s3（simple storage service）几天前也“沉”了4个小时，墙外的半个互联网也跟着挂了。如约，按aws惯例，aws给出了一个简单的故障报告《summary of the amazon s3 service disruption in the northern virginia (us-east-1) region》。这个故障简单来说和gitlab一样，也是人员误操作。先简单说一下这份报中说了什么。

故障原因 

简单来说，这天，有一个aws工程师在调查northern virginia (us-east-1) region上s3的一个和账务系统相关的问题，这个问题是s3的账务系统变慢了（我估计这个故障在amazon里可能是sev2级，sev2级的故障在amazon算是比较大的故障，需要很快解决），oncall的开发工程师（注：amazon的运维都是由开发工程师来干的，所以amazon内部嬉称sde-software developer engineer为someone do everything）想移除一个账务系统里的一个子系统下的一些少量的服务器（估计这些服务器上有问题，所以想移掉后重新部署），结果呢，有一条命令搞错了，导致了移除了大量的s3的控制系统。包括两个很重要的子系统：

一个是s3的对象索引服务（index），其中存储了s3对象的metadata和位置信息。这个服务也提供了所有的get，list，put和delete请求。

一个是s3的位置服务系统（placement），这个服务提供对象的存储位置和索引服务的系统。这个系统主要是用于处理put新对象请求。

这就是为什么s3不可访问的原因。

在后面，aws也说明了一下故障恢复的过程，其中重点提到了这点——

虽然整个s3的是做过充分的故障设计的（注：aws的七大design principle之一design for failure）—— 就算是最核心的组件或服务出问题了，系统也能恢复。但是，可能是在过去的日子里s3太稳定了，所以，aws在很长很长一段时间内都没有重启过s3的核心服务，而过去这几年，s3的数据对象存储级数级的成长（s3存了什么样数量级的对象，因为在amazon工作过，所以大概知道是个什么数量级，这里不能说，不过，老实说，很惊人的），所以，这两个核心服务在启动时要重建并校验对象索引元数据的完整性，这个过程没想到花了这么长的时候。而placement服务系统依赖于index服务，所以花了更长的时间。

了解过系统底层的技术人员应该都知道这两个服务有多重要，简而言之，这两个系统就像是unix/linux文件系统中的inode，或是像hdfs里的node name，如果这些元数据丢失，那么，用户的所有数据基本上来说就等于全丢了。

而要恢复索引系统，就像你的操作系统从异常关机后启动，文件系统要做系统自检那样，硬盘越大，文件越多，这个过程就越慢。

另外，这次，aws没有使用像以前那样outage的故障名称，用的是“increased error rate”这样的东西。我估计是没有把所有这两个服务删除完，有些用户是可以用的，有的用户则不行了。

后续改进 

在这篇故障简报中，aws也提到了下面的这些改进措施——

1）改进运维操作工具。对于此次故障的运维工具，有下面改进：

让删除服务这个操作变慢一些（笔者注：这样错了也可以有时间反悔，相对于一个大规模的分布式系统，这招还是很不错的，至少在系统报警时也可以挽救）；

加上一个最小资源数限制的safeguard（笔者注：就是说，任何服务在运行时都应该有一个最小资源数，分布式集群控制系统会强行维护服务正常运行的最小的一个资源数）；

举一反三，review所有和其它的运维工具，保证他们也相关的检查。

2）改进恢复过程。对于恢复时间过长的问题，有如下改进：

分解现有厚重的重要服务成更小的单元（在aws，service是大服务，小服务被称之为cell），aws会把这几个重要的服务重构成 cell服务。（笔者注：这应该就是所谓的“微服务”了吧）。这样，服务粒度变小，重启也会快一些，而且还可以减少故障面（原文：blast radius – 爆炸半径）；

今年内完成对index索引服务的分区计划。

相关思考 

下面是我对这一故障的相关思考——

0）太喜欢像gitlab和aws这样的故障公开了，哪怕是一个自己人为的低级错误。不掩盖，不文过饰非，透明且诚恳。cool！

1）这次事件，还好没有丢失这么重要的数据，不然的话，将是灾难性的。

2）另外，面对在us-ease-1这个老牌region上的海量的对象，而且能在几个小时内恢复，很不容易了。

4）对于高可用的运维，平时的故障演习是很重要的。aws平时应该没有相应的故障演习，所以导致要么长期不出故障，一出就出个大的让你措手不及。这点，facebook就好一些，他们每个季度扔个骰子，随机关掉一个idc一天。netflix也有相关的chaos monkey，我以前在的路透每年也会做一次大规模的故障演练——灾难演习。

5）aws对于后续的改进可以看出他的技术范儿。可以看到其改进方案是用技术让自己的系统更为的高可用。然后，对比国内的公司对于这样的故障，基本上会是下面这样的画风：

加上更多更为严格的变更和审批流程；

使用限制更多的权限系统和审批系统；

使用更多的人来干活（一个人干事，另一个人在旁边看）；

使用更为厚重的测试和发布过程；

惩罚故障人，用价值观教育工程师。

这还是我老生长谈的那句话——如果你是一个技术公司，你就会更多的相信技术而不是管理。相信技术会用技术来解决问题，相信管理，那就只会有制度、流程和价值观来解决问题（注意：这里我并没有隔离技术和管理，只是更为倾向于用技术解决问题）。

最后，你是要建一个“高可用的技术系统”，还是一个“高可用的管理系统”？欢迎留言和我们一起探讨。

原文发布时间为：2017-03-05

本文来自云栖社区合作伙伴dbaplus