五个为什么(译文)

作者: 阮一峰

日期: 2009年8月21日

腾讯课堂 NEXT 学院

天晚上,我终于把 More Joel on Software 翻译完了。

谢天谢地,总算可以摆脱这本书了。

唯一的感觉就是特别倦怠......检查完译稿以后,我一分钟也没等,立刻用Email发给了编辑,然后倒头就睡,直到刚才起床。此书的编辑工作量很大,但愿一切顺利,可以在年底前上市。

下面的文章是此书的第35篇,也就是倒数第2篇。它介绍了一种很好的工作方法,就是说,当你遇到问题的时候,要一连问5个为什么,不停地问,直到找到根本原因为止,我觉得真的很值得借鉴。

======================

五个为什么

作者:Joel Spolsky

译者:阮一峰

原文网址:http://www.joelonsoftware.com/items/2008/01/22.html

发表日期 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一个人能被叫醒。

(完)

优达学城

uni-app

留言(28条)

After some internal discussion we all agreed that rather than imposing a statistically meaningless measurement and hoping that the mere measurement of something meaningless would cause it to get better, what we really needed was a process of continuous improvement.

我的翻译:几次内部讨论后,所有人都同意:我们不需要(给我们的服务标准)强制设定一个统计上毫无意义的指标,并去希望对这种无意义的东西的测量能够促使我们做的更好;我们真正需要的是一种能使我们不断改进的流程。

你的翻译:不为服务稳定性设置一个静态值作为目标,那是毫无意义的。我们觉得,如果有人希望通过测量某些无意义的指标来改进工作,那肯定是没用的。我们真正需要的是一个能够不断改进工作质量的流程。

你可能把“statistically”(统计上)看成“静态”了吧 :)

很好的文章啊,迫不急待想阅读这本书了。

啥时候出版,求签售

恭喜!

我一定买一本,很少见这么用心翻译的作者了。现在的一些翻译家还不如Google翻译来的通顺。

另外:
那是一条网络管理员Nagios发来的短消息,报告系统不正常。

我没有看到原文,但是我知道Nagios是一个很强大的开源网络管理系统。不排除有叫Nagios的人.

那是一条网络管理员Nagios发来的短消息,报告系统不正常。

翻成:那是网络管理员Nagios发来的一条短消息,报告系统不正常。

把“一条”放在“短消息”前面,是不是更好?

其实这种书还是要看原文的……
但是依然要鼓励译者付出的努力.
译者一定在翻译过程中科普了很多计算机方面的知识吧 哈哈~

Nagios 不能翻译成网络管理员呀。那是个监视系统。

这样专业的书籍翻译起来非常费力,这不是自己水平的原因。兄弟辛苦了,支持你!

五个为什么是日本人在全面质量管理(TQC)中提出的概念

辛苦了,不论是作为一个软件工程师,还是阮大哥的读者,我都会买一本来看的!

To 红叶枫了,Sutra :

不好意思,我没仔细检查,不知道Nagios是一个软件,以为是一个人名。……已经改正过来了。

To Frank:

确实看错了,已经改过来了。

To 敏恒:

对,你的表达更符合汉语习惯。我已经根据你的意见修改了。

期待书的出版,一定要入手一本~~

你好,我是一个托福考生,想问一下如何提高听力
我的听力特别差——我分析了主要原因就是听力中对单词反应比较慢。结果就是只能照着几个听到的词去猜题..
现在我没有很多时间了(大约完整的一个月练听力),所以想问一下有没有什么方法提高——什么办法都可以

帮忙说详细点,先谢过了


如果可以,回信到 psbacloud@hotmail.com

谢谢

很美妙的文章,能否转载?
一定会保留原文相关信息

祝贺

To Riveter:

从发音入手,把每个单词的发音务必读准。
然后就是朗读,大量朗读。

遇事连问五个为什么。貌似确是日本人首先提出来的。
其实,在中国,不过就是 打破沙锅问到底。
可惜,我们缺少严谨的逻辑体系,缺少大工业生产,因此,也就缺少这样精炼而对世界性的生产运动带去影响的理论。

曾经有个想法,中国的大学生都应该去工厂里干好好干几个月再说。所以,尽管对张瑞敏画蛇添足的在5S基础上提出6S(做好5S,safety不过是顺理成章的结果),但是对海尔坚持应届毕业生首先到车间几个月这点,还是觉得不错的。

carrier grade感觉翻译成“航母级”更好一些。。。

nagios是一个功能很强大的网络监控软件,当发生故障时可以发送短信报警,我感觉那个nagios很有可能是只这个软件。

carrier grade感觉翻译成“航母级”更好一些。。。
===================
不对,就是电信级.

这样的“小”IT公司只能用这样原始手段解决这样的原始可靠性问题。

自从人类社会进入工业化后,可靠性问题就既是技术问题,又是管理问题。必须分清楚那些可靠性问题需要靠技术手段,哪些又要靠人的管理(不是机器的管理)来解决。

我们一般惯常使用技术手段(也就是机器管理)来看待可靠性问题,其实在另一方面用人的管理一样能从更根本,更深层次地解决可靠性问题,只是这样的管理手段太微妙,难以写在教科书,写在公司条例中去操作罢了。

换个说法,抱着炸弹时刻准备牺牲自己的决死勇士比任何一艘航空母舰都要可靠得多,只是航母易得,勇士难求。

现在有了吗?如果有的话请告诉我哪里可以买到啊!谢谢!

我的邮箱:593942110@qq.com

“解决问题有两种方法”,指的是哪两种方法?

引用步行者的发言:

“解决问题有两种方法”,指的是哪两种方法?

我猜测作者的意思是:一种是把问题解决完事,而另外一种就是本文所说的“打破砂锅问到底”,找到产生问题的根源并制定措施来最大限度的减少甚至杜绝此种问题的再次发生。

引用红叶枫了的发言:

我一定买一本,很少见这么用心翻译的作者了。现在的一些翻译家还不如Google翻译来的通顺。

同感!!!

“carrier grade” 正确的译法应该是“运营商级”而不是“电信级”

我要发表看法

«-必填

«-必填,不公开

«-我信任你,不会填写广告链接