本文经作者同意授权转载 作者：陈皓 来源：酷壳-CoolShell.cn 继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不可访问的原因。 在后面，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）改进运维操作工具。对于此次故障的运维工具，有下面改进：
2）改进恢复过程。对于恢复时间过长的问题，有如下改进：
下面是我对这一故障的相关思考 0）太喜欢像Gitlab和AWS这样的故障公开了，哪怕是一个自己人为的低级错误。不掩盖，不文过饰非，透明且诚恳。Cool！ 1）这次事件，还好没有丢失这么重要的数据，不然的话，将是灾难性的。 2）另外，面对在US-EASE-1这个老牌Region上的海量的对象，而且能在几个小时内恢复，很不容易了。 3）这个事件，再次印证了我在 声明：文章版权归原作者所有 部分文章转自互联网 如有侵权请联系 [邮箱地址] 删除 |
注册
登录
