去年年底，Netflix技术博客上发表了这么一篇文章，题为“转向亚马逊网络服务过程中学到的五个教训”（5 Lessons We’ve Learned Using AWS）。亚马逊网络服务（Amazon Web Services，以下简称AWS）无疑是所谓的“云计算”的杰出代表。因此，这篇文章实际上也可以看成是给任何想要转向“云”的网站的关键性建议。当然，这些建议的确很棒！下面是一条最让我震惊的：

译者注：Netflix是一家美国公司，在美国、加拿大等地提供互联网随选流媒体播放，以及DVD、蓝光光碟的在线租赁业务。该公司成立于1997年，总部位于加利福尼亚州的洛斯盖图。1999年开始订阅服务。到2009年，该公司可提供多达10万部DVD电影，并有1000万的订阅用户。

我们时常把Netflix在AWS里的软件架构称作为“蓝博”。不管怎么样，哪怕不借助任何外力，每个系统都要有自我实现成功的能力。我们在设计每一个分布式系统时，对我们所依赖的其他系统的容错能力总是会充分考虑的。

译者注：蓝博（Rambo）是电影《第一滴血》里男主角的名字，他是一个所向披靡的孤胆英雄的形象。

如果我们的推荐系统当机了，我们对客户响应的质量肯定会下降，但我们仍然是有应必答的。虽然在这种情况下做不了个性化的推荐，但我们会把最流行的电影推荐给客户。如果我们的搜索系统突然慢得让人无法忍受，但这绝对不会妨碍用户以流媒体的方式观看电影。

我们的工程师最早在AWS里创建的一个系统其实是“混世魔猴”。这只猴子的工作就是捣蛋，它要随机杀死我们系统架构里的组件或服务。如果我们不持续检验我们在失败面前自我恢复乃至成功的能力，那这个系统很有可能就是会在关键时刻掉链子。

猛一看，你肯定觉得这条建议太疯狂！但我们必须面对它。我不确定会有多少公司认同这样的做法，更别说有多少公司会真的去尝试了。如果在你工作的地方，有人部署了一个后台程序或服务，专门用于随机杀死你的服务器集群里的服务或进程，请举手！

如果这个人还没被你的公司解雇，请举起你的另外一只手！

但凡大脑正常的人，怎么会愿意去结交一只“混世魔猴”呢？

其实，有时候你没的选择；“混世魔猴”会自己找上门！Stack Exchange网络曾经碰到过一个诡异的问题，我们也为此苦苦挣扎了几个月。这个问题是：每隔几天，Oregon网络中心的某台服务器总会突然对来自外部网络的任何请求停止响应。没有原因；毫无道理；而且必须经过缓慢的关机、重启之后才能恢复，期间还会让服务器出现蓝屏现象……

我们花了几个月——真正是几个月的时间——去追踪这个问题。我们还把可能的原因列了很长的一个清单，一项一项去排除：

• 交换网络端口
• 更换网线
• 使用一个不同的路由器
• 尝试多个版本的网卡驱动程序
• 尝试各种操作系统和驱动程序级别的网络设置
• 简化我们的网络配置，并且关掉TProxy代理服务以使用更为传统的X-FORWARDED-FOR
• 更换虚拟化软件供应商
• 改变我们的TCP/IP主机模型
• 安装内核升级包
• 寻求高级供应商客户支持团队的帮助
• 其他尝试（我现在已经忘记了，因为我现在已经从这种痛苦中解脱了）

在整个事件过程中，我们的团队成员是如此地受挫，以致于一度几乎要打起来。（团队成员都是远程工作的，怎么“打”？我们都用Skype。你懂的……）这能怪我们吗？每隔几天，我们的几台服务器中的一台会随机地出现当机。“混世魔猴”老是来捣乱！

不过，即使在我们最受挫的时刻，我意识到我们还是做了一些积极的改变：

• 对于一些重要的功能，以前我们只用一个服务器，现在我们改成两个。
• 如果某些服务没有合理的容错或应变方案，我们补上一个。
• 我们对系统做了全面的检查，去掉了一些不必要的组件，直至一个足以运维我们的服务的最小集合。
• 我们采取了一些权变措施，使得我们的系统即使在我们之前认为很关键的服务突然失效的时候，也能永远处于运行状态。

时间一天一天过去，我们每周都使我们的系统更加冗余一点点，因为我们必须这么做。尽管整个过程很痛苦，但事实摆在面前，实际上“混世魔猴”帮了我们一个大忙，它迫使我们变得极具弹性。赶快行动起来吧！不要等明天，也不要指望将来更远的某一天，更别说“以后再说吧”，立刻行动起来！

当你结交“混世魔猴”之后，你很快就会发现，每件事情发生的背后总是有原因的（除了那些完完全全随机发生的事情）。“避免失败最好的办法就是不断地失败。”明白这句话的道理了吧，虽然它听起来很疯狂！