昨天晚上，我终于把 More Joel on Software 翻译完了。
谢天谢地，总算可以摆脱这本书了。
唯一的感觉就是特别倦怠......检查完译稿以后，我一分钟也没等，立刻用Email发给了编辑，然后倒头就睡，直到刚才起床。此书的编辑工作量很大，但愿一切顺利，可以在年底前上市。
下面的文章是此书的第35篇，也就是倒数第2篇。它介绍了一种很好的工作方法，就是说，当你遇到问题的时候，要一连问5个为什么，不停地问，直到找到根本原因为止，我觉得真的很值得借鉴。
======================
五个为什么
发表日期 2008年1月22日，星期二
2008年1月10日的凌晨3点30分，一阵急促的嘟嘟声惊醒了我们的系统管理员Michael Gorsuch，当时他正在位于布鲁克林的家中睡觉。那是一条网络管理员Nagios发来的短消息，报告系统不正常。
Michael Gorsuch从床上爬起来，不小心踩到了正在床边酣睡的他的狗，把狗也弄醒了。那条狗气呼呼地窜到客厅里，在地板上撒了一泡尿，然后又回来继续睡觉。这个时候，Michael Gorsuch已经在另一间房间里打开了电脑，发现在他负责的三个机房中，有一个位于曼哈顿闹市的机房连不上去。
这个特别的机房位于曼哈顿繁华地区一幢很安全的大楼里，面积很大，由Peer 1公司负责管理。它配备了发电机，以及足够使用好几天的柴油，还有大量的蓄电池，保证在自备发电机启动前，能够提供几分钟的电力，防止出现访问中断。它还有巨大的空调设备，多个高速互联网出口，以及非常务实、负责的工程师，他们总是以一种单调、稳重、井然有序的方式进行工作，而不会用花俏、刺激、时髦的方式做事，所以那是一个非常可靠的机房。
像PEER 1这样的ISP，喜欢使用一个叫做"服务级别协议"（Service Level Agreement，简称SLA）的术语，承诺保证他们服务的正常运行时间（uptime）。典型的SLA往往这样写："保证99.99%的时间正常运行"。你可以做一下算术，地球围绕太阳公转一圈的时间是525949分钟（或者以一年365天计算，就是525600分钟），这就允许他们每年有52.59分钟的故障时间。如果故障时间多于这个数字，SLA通常会写清楚提供某种形式的赔偿，但是说实话，赔偿的金额往往是微不足道的......比如，你购买了一年的服务，他们就按照发生故障的分钟数，把相应的使用费退还给你。我记得有一次，某一个机房发生故障，整整两天都不能访问，给我们造成了几千美元的损失，结果我从ISP那里得到的唯一赔偿，就是10美元的退费。所以，SLA保证条款其实是没用的。而且正是因为赔偿金额微不足道，许多ISP开始打广告，声称正常运行时间高达100%。
过了十分钟，Michael Gorsuch连上了曼哈顿的机房，一切似乎都恢复正常，他就又回去睡觉了。
大约到了清晨5点，这个问题又出现了。这一次，Michael Gorsuch打电话到PEER 1在温哥华的网络运营中心NOC。对方开始调查，做了一些测试，但是没有发现任何异常。5点30分，一切好像又恢复了正常。但是，Michael Gorsuch还是不放心，不敢再回去睡觉了。
清晨6点15分，曼哈顿机房彻底无法连通。PEER 1在他们那一边找不到任何异常。Michael Gorsuch穿好衣服，搭地铁进入曼哈顿。服务器本身好像没有出问题，都在正常运行。PEER 1的网络连接也是好的，问题出在交换机。Michael Gorsuch取下了交换机，将我们的路由器直接连到了PEER 1的路由器。真是奇妙，我们的服务器又可以重新访问了。
这时，天已经亮了，我们在美国的客户开始上班了，他们会感到一切正常。但是我们在欧洲的客户，却已经发来了电子邮件，抱怨不能连上我们的服务器。Michael Gorsuch花了一些时间做事后分析，发现事故原因是交换机上一个简单的设置。交换机能够使用多种网速进行工作（每秒10M比特、100M比特或者1000M比特），你可以手动设置网速，也可以让交换机自动选择与所在网络相适应的网速。我们这台交换机就设在了自动选择档，问题就出在这里。通常情况下，交换机的这个设置会正常工作，但不能保证一定不出故障，1月10日的凌晨，它就发生故障了。
Michael Gorsuch其实早知道这个设置可能会引发故障，但是安装交换机的时候，他忘了手动设置网速，所以交换机上的设置一直是出厂时的自动档。这个设置也能正常工作，直到出了问题为止。
Michael Gorsuch并没有因为解决了问题而感到高兴，他给我写了一封电子邮件：
我知道自从推出"FogBugz在线服务"以后，我们并没有一个正式的SLA条款，但是我觉得应该拟定一个供内部使用（至少如此吧）。这样我就能衡量，我自己（甚至整个系统管理团队）是否达到了业务管理目标。我本来已经开始着手写了，但是一直没有完成，经过今天早上的事故后，我会尽快完成它。
SLA条款通常用"正常运行时间"来定义，所以我们需要定义"FogBugz在线服务"的"正常运行时间"到底是多少。确定以后，我们就要把它转化成一系列政策，然后再把政策转化成一整套的监控/报告脚本，每隔一段时间就检查一次，看看我们是否达到了业务管理目标。
好主意！
但是，SLA也不是包治百病的良药，它也存在一些问题。最大的问题就是缺乏制定标准必需的统计资料，因为服务中断的情况很少发生，所以你得不到足够的数据，无从知道多长的运行时间才算是"正常的"。如果我没有记错的话，自从六个月前我们推出"FogBugz在线服务"以来，包括这一次在内，只发生了两次服务的突然中断。其中只有一次，是由于我们的过失而造成的。互联网上大多数正常运行的在线服务网站，一年中只发生两次、也许三次服务中断。正是因为服务中断很少发生，所以每次中断的时间长度就开始变得真的很重要，这才是网站之间出现巨大差异的地方。突然之间，你正在谈论的问题就变成了，如何才能最快地派一个人找到发生故障的设备，然后替换掉它。为了得到非常高的正常运行时间，你等不及派人去换掉出问题的设备，也等不及工程师去检查哪里出了问题，你必须事先就考虑到每一个可能出错的地方，但是这实际上不太可能做到。能够将你置于死地的，不是意料到的突发状况，而是意料之外的突发状况。
要想得到真正高的服务稳定性，成本是极其高昂的。俗称"六个9"的服务稳定性（99.9999%的时间正常运行），意味着每年下线时间不能超过30秒。这真的有点接近荒谬了。即使有人声称，他们已经投资了上千万美元，建立了超一流的大型超冗余"六个9"系统，即使这样，也无法排除出现严重故障的可能性。某一天当他们醒来的时候，我不知道是哪一天，但是会有这么一天，他们发现一种异乎寻常的故障以一种异乎寻常的方式发生了，比如三个机房都遭到了电子脉冲EMP炸弹的袭击，他们只能拼命捶自己的脑袋，眼睁睁看着服务中断14天。
请这样想，如果你的"六个9"系统由于某种神秘原因，突然下线了，然后你花了一个小时，找到了原因并将其修复，即使这样，你也已经把直到下个世纪的服务中断时间额度都用光了。即使是公认的最可靠系统，比如AT&T的长途电话服务，也会出现长时间的服务中断（1991年中断了6个小时），这意味着它们的服务稳定性只能到达一个令人羞于启齿的"三个9"水平（99.9%的时间正常运行）......AT&T的长途电话服务被认为是"电信级"（carrier grade）的系统，是服务稳定性的黄金标准，你的系统会比它更稳定吗？
提高服务稳定性的最大困难，就是"黑天鹅难题"（problem of black swans）。这个名词是由Nassim Taleb提出来的（www.edge.org/3rd_culture/taleb04/taleb_indexx.html），他这样定义："黑天鹅代表外来因素，是一个超出正常预料的事件。"几乎所有的互联网服务中断，都来自于意料之外的突发事件，属于极其小概率的非主流意外。这类事件是如此罕见，以至于常规的统计方法----比如"故障间隔平均时间"----都失效了。"请问新奥尔良市发生特大洪水的平均间隔时间是多少？"
测量出每年服务中断的分钟数，并无助于预测你的网站第二年会中断服务多久。这让我想到了今天的民用航空业。美国的全国运输安全委员会NTSB的成就非常卓越，所有常见的飞机坠毁的原因都已经被消除了，结果就导致如今每一次发生飞机坠毁，事故的原因看来似乎都属于非常令人意外的、独一无二的"黑天鹅因素"。
服务稳定性有两个极端，一个是"极端不可靠"，服务一次又一次地中断，简直愚蠢至极；另一个是服务稳定性"极端可靠"，你花了几百万美元，终于将每年的"正常运行时间"增加了一分钟。在这两个极端之间，存在一个服务稳定性的最佳位置，即所有被预计到的突发情况都已经事先做好了准备。你预计到硬盘可能会发生故障，就事先做好了准备，所以当硬盘真的发生故障的时候，你的服务就不会中断。你预计到DNS服务器可能会发生故障，就事先做好了准备，所以当DNS服务器真的发生故障的时候，你的服务就不会中断。但是，意料之外的突发情况，也许就会让你的服务出现中断。这种局面就是我们能够期望的在两个极端之间达到的最佳位置了。
为了达到这个最佳位置，我们借鉴了日本丰田公司创始人丰田佐吉（Sakichi Toyoda）的思想，他提出了五个为什么。当某个地方出错的时候，你就问为什么，一遍遍地追问，直到你找到根本性的原因为止。然后，你就针对根本性的原因，开始着手解决问题，你要从根本上解决这个问题，而不是只解决一些表面的症状。
我们早就提出过"解决问题有两种方法" ，"五个为什么"同我们的提法很接近，所以我们就决定开始采用这种方法。下面就是Michael Gorsuch列出的思考过程：
我们与PEER 1纽约机房的连接中断了。
为什么？----我们交换机里的网线接口好像不工作了。
为什么？----与PEER 1的网络运营中心交换意见后，我们判断这个问题很可能是由于网速/双工模式不匹配（speed/duplex mismatch）造成的。
为什么？----交换机的网速开关设在了自动调节档，而没有被手动设置在一个固定档。
为什么？----许多年前，我们就清楚地知道有可能发生此类故障。但是，我们始终没有写出一份书面的技术说明文档，用于指导和检查交换机在生产环境中的设置。
为什么？----我们总是很狭隘地看待技术说明文档，觉得只有在找不到系统管理员的情况下，才需要去看它，或者觉得只有运营团队中那些不负责系统管理的成员，才需要看它。我们没有认识到，应该把它作为技术操作的标准和确认清单。
"如果我们事先就写好一份书面的标准操作流程，安装完交换机后，再根据书面流程一一核对安装步骤，这次的服务中断事故就不会发生，" Michael Gorsuch写道。"或者假定我们已经有了一份书面的操作流程，但是写得不够完整，那么等到事故发生以后，我们就需要对这份文档进行相应的补充升级，确保类似的事故以后不再发生。"
经过几次内部讨论以后，我们所有人都同意，不为服务稳定性设置一个静态值作为目标，那是毫无意义的。我们觉得，如果有人希望通过测量某些无意义的指标来改进工作，那肯定是没用的。我们真正需要的是一个能够不断改进工作质量的流程。所以，我们决定不向我们的顾客提出一个SLA条款，而是搭建一个网志。在这个网志上面，我们将实时记录每一次的服务中断，提供完整的事后分析，询问五个为什么，找到根本性的原因，告诉我们的顾客为了防止类似故障再次发生，我们所采取的举措。就拿这一次的交换机事故来说，我们采取的变化就是，在内部文档中写入详细的操作步骤和检查清单。以后再在生产环境中安装交换机的时候，所有操作步骤都必须严格按照文件中写好的步骤完成。
我们的顾客可以访问这个网志，看看故障的原因到底是什么，以及我们正在怎样改进我们的服务。我们希望，我们的顾客能够因此增强信心，相信我们的服务品质正在稳步提高。
与此同时，如果我们的顾客感到我们的故障对他造成了影响，他就可以向我们要求补偿，客服人员会给他的账户延长使用期限或者退款。我们让顾客自己决定到底该补偿多少，最多可以延长使用期限一个月，因为不是每个顾客都会注意到发生了服务中断，更不要说遭受损失了。我希望我们的这些做法，能够提高我们的服务稳定性，到达一种我们可以接受的程度，即我们的目标就是，我们遇到的所有引起服务中断的故障，都是真正由于极其罕见的、无法预料的"黑天鹅因素"而引起的。
附言。对，我们需要再招聘一名系统管理员，以免深更半夜再发生故障的时候，只有Michael Gorsuch一个人能被叫醒。
（完）
