故障原因

简单来说，这天，有一个 AWS 工程师在调查 Northern Virginia (US-EAST-1) Region 上 S3 的一个和账务系统相关的问题，这个问题是S3的账务系统变慢了（我估计这个故障在Amazon里可能是Sev2级，Sev2级的故障在Amazon算是比较大的故障，需要很快解决），Oncall的开发工程师（注：Amazon的运维都是由开发工程师来干的，所以Amazon内部嬉称SDE-Software Developer Engineer 为 Someone Do Everything）想移除一个账务系统里的一个子系统下的一些少量的服务器（估计这些服务器上有问题，所以想移掉后重新部署），结果呢，有一条命令搞错了，导致了移除了大量的S3的控制系统。包括两个很重要的子系统：

1）一个是S3的对象索引服务（Index），其中存储了S3对象的metadata和位置信息。这个服务也提供了所有的 GET，LIST，PUT 和DELETE请求。

2）一个是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 上的海量的对象，而且能在几个小时内恢复，很不容易了。

3）这个事件，再次映证了我在《关于高可用的系统》中提到的观点：一个系统的高可用的因素很多，不仅仅只是系统架构，更重要的是——高可用运维。

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

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

a）加上更多更为严格的变更和审批流程，

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

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

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

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

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

最后，你是要建一个 “高可用的技术系统” ，还是一个 “高用的管理系统”？ ;-)

（全文完）

1. ReCAPTCHA

reCAPTCHA  允许你的网站集成一个Advanced CAPTCHA 系统，这个系统可以帮助你阻止一些垃圾信息。可视化的CAPTCHA 同样也有一个有用的声音功能。另外，在reCAPTCHA 服务里，这个PHP库也包含了一个给 “Mailhide” 服务用的API，这个可以把你的邮件地址隐藏于一些抓邮件地址的程序。

这个API是免费并且非常容易使用的，你需要做的就是申请一个API的KEY。

下载 ReCAPTCHA | 获取一个API Key | 相关文档

2. Akismet

Akismet 是一个免费的服务项目，对于一些小型的网站它是完全免费的，对于一些大型的网址，他是部分免费的。这个库也是提供了处理一些和垃圾信息相关的功能。它主要通过比对自己数据库中已存在的被认定为垃圾的信息，而做出决定的。当然，数据库中的垃圾信息可能通过各个网站举报，大家供享的。这是一个每天都在更新，每天都在改进的库。许多许多的WordPress都装有这个库。

实施Akismet

3. Services_JSON

JSON 是一个非常小巧敏捷的PHP库，它主要用于把一些数据格式转成易于人们阅读的格式。并不是所有的人都会喜欢PHP5 （因为自PHP5.20后其中已经集成了JSON），所以，这个小PHP库可以在低版本的PHP中让你得到 JSON 的功能。

查看 Services_JSON

4. Smarty

Smarty 是一个网面模板引擎，它主要是把程序和界面分开。Smarty 提供了许多强大的功能，比如循环，变量，以及一个强大的缓存系统。这个库不是一个新库了，其已经发展了很多年了，虽然只有3个release版，但应该是比较成熟了。

下载 Smarty | 查看文档

5. pChart

这是一个强大的画统计图的PHP库，像一些饼图或是柱状图，pChart 还允许你通过SQL查询语句或是手动的输入数据来创建一个统计图。当然它需要GD库的支持以便创建图片。这个库一看就是有很多非常专业的美工设计过，因为它可以让你的统计图显示的相当漂亮。

下载 pChart | 相关文档 | 查看演示

6. SimplePie

SimplePie  允许你可以容易地 pull 一些信息，比如RSS feeds。它同样可以被集成于不同的平台和语言。并且可以通过很多不同的方法来处理远端的feed。

下载 SimplePie | 相关文档 | Extending SimplePie to Parse Unique RSS Feeds

7. XML-RPC PHP

我们的应用程序有时需要一些类似于 “ping” 的功能去探测一下其它站点，如BLOG的 trackbacks。一般来说，这都是通过一个叫做XML-RPC的协议来完成的。XML-RPC PHP 库可以让你的站点集成这些功能。

下载 XML-RPC PHP | 相关文档

8. Amazon S3

Amazon 提供了一个“云服务”叫”S3″. 这个PHP库可以让你不需要第三方的插件就可以上传大的文件。

下载 Amazon S3 PHP 类

9. PHPMailer

很多应用都需要对外发送邮件，但是PHP的mail() 函数并不是特别好用。于是 PHPMailer 应运而生，这是一个功能强大的类，其允许你发送不同格式的邮件，并支持附件和自定义邮件头。

下载 PHPMailer | 相关文档

文章：来源