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