首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >五个为什么(译文)

五个为什么(译文)

作者头像
ruanyf
发布2018-04-12 11:59:32
7610
发布2018-04-12 11:59:32
举报

昨天晚上,我终于把 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一个人能被叫醒。

(完)

本文参与 腾讯云自媒体分享计划,分享自作者个人站点/博客。
原始发表:2009年8月21日,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档