小灵通漫游未来 (已有 119,786 人访问过博主空间)

https://www.backchina.com/u/279512

大年三十的事故 – 变更管理的故事 [2009-09-19]

作者:小灵通漫游未来  于 2010-3-23 23:13 发表于 最热闹的华人社交网络--贝壳村

通用分类:职场内外|已有1评论

关键词:

农历新年大年三十。我一觉睡到十一点才起床。多伦多这个鬼天气, 一年中有六个月是冬天,四个月在下雪。现在外面是白雪皑皑,反正今天请假了,现在国内应该是午夜了,打开电视看看国内的庆祝活动吧。再看看本地,虽然天还 冷,唐人街也有舞狮舞龙的。

在这样一个大型企业集团设计维护IT基础设施的工作真不是太轻松。去年赶在圣诞节前把公司近两百个传媒网站搬进了它们的新家,十几部“片”(blade)服务器同时从网络存取系统(NAS)上读取网站内容,系统根据各网站流量自动申请资源,负荷平衡器 (Load Balancer)负责根据活跃服 务器数动态把网页申请转向活跃服务器.... 系统从网络结构,服务器选型安装,存储设备,代码修改,系统测试,网站测试,一直到最终切换,整整花了半年多时间。经过多少个不同部门紧密 合作,多少个不眠之夜,总算成功的拔掉了旧服务器的网线,因为切换而造成的新闻发布冻结时间为零,网站下线时间也为零。整个部门都为这次系统切换计划的天 衣无缝而洋洋得意。在设计过程中曾被质疑NAS的使用, 被认为是单点失败, 但是经过多次的商量讨论,同时邀请了供应商的参与,用双通道进入NAS,确保对NAS的读取万无一失。切换之后,从外界用户看来,网站除了速度提高以外,其他变化都没有,而拥有网站各媒体,除了注意到某些代码因为软件系统的 升级被优化修改外,也没有任何工作习惯的改动。与网站拥有者的交流是我上一个月的工作重点,保证旧代码不会从开发员的桌面上进入新系统造成网页出错。农历 新年到了,特意请了2天假,在家好好休息 一下。

中午十二点,电话 响了,是公司事故管理部门的。报告有用户投诉一个杂志网站显示不了。跟他在电话上的时候又听他那里邮件提示音不断,他就一个一个读给我听,一个电台站掉 了,两个, 三个,一个电视台,又一个电台,再 一个杂志,十分钟后他不耐烦的说:“们,我想你们的传媒站恐怕都掉了!” 我跑到计算机前面,查了几个重要网站,告诉他报一个最高级严重性的事故给我们部门处理。

电话打到我的组里,所有的人都战战兢兢,报告web服务器工作正常,应用服务器工作正常。找到网络部门,报告 Load Balancer 发现所有探针都返回404错误,只有很少的几次探测有效,但下次又立即报错。这时候我们部 门有人半开玩笑的说:“道真的是单点失 败?” 我想到NAS,于是要求事故管理部门通知管理NAS的存储组,请操作人员参与电话会议。

负责这块NAS操作的人叫John,虽然有多年的工作经验,可是做事往往喜欢急功近利,不按照程 序。存储组的同事说,John今天去了处于 附近一个卫星城市的机房,手机不通。这时我想起前天电话会议上,他提出今天要去机房。难道这跟他有关? 于是我要求翻查今天的变更管理档案以了解他今天的改动内容。可是 今天变更申请里面,没有查到他的名字。

这时组里有人确认了NAS服务器目前处于维护模式,只允许单线读取。我于是请他们把所有的“片”部关机,再一部一部的打开,把重要网站内容复制到刀片的硬盘上临 时恢复部分服务。半小时之后部分网站开始服务,但是因为无法正常更新,新闻网站只能提供上午的信息,彻底破坏了新闻网站的实时性。

下午两点,事故管理部门终于把John叫到了电话会议上,我问他今天进机房的目的,他说在对同一个NAS系统的另外分区进行操作, 因为那个分区目前没有投入使用,他没有填写变更申请。我表示不同 意,因为这是成品系统,任何误操作都可能造成损失, 一定要把操作细节步骤,甚至取消改动的步骤清清楚楚写在变更档案里面,而且在操作时严格按照步骤执行。这样万一出现 问题,也有分析依据和尽快恢复。事故管理和变更管理部门的同事也同意我的意见。

但是现在问题已经出现,我们怎么解决呢?我请组里的同事做记录, 询问John是不是误操作碰到了网站内容的分区。他的回答是:“I did nothing (我什么也没做啊)”。既然这样,那就是NAS系统出问题了。我们紧急呼叫供应厂家要求他们立刻派人来协助维 修。厂家通知我们,他们在德克萨斯的工程师已经启程,应该在天黑之前到多伦多。并且已经要求附近的仓库把替换设备直接运送到我们机房。我要求John 留在机房协助厂商的工程师。

在等厂家工程师的时候,我们的网站内容复制工作也在进行,越来越 多的网站逐渐恢复服务静态内容。我也借这个时间了解John今天在机房的操作。我了解到他的是要在成品系统上的另外一个分区进行操作,可是,这个操作并没有在开发系统上试验 过。我表示理解他的性急,但是希望他以后能遵守操作规程,在模拟系统上先试验,把操作步骤记录在案到开发系统上测试操作步骤,然后申请变更管理在成品系统 上正式操作,因为变更管理申请需要有操作步骤,验证步骤和取消步骤才能够被批准,很多人把这个过程认为是瓶颈,试图绕开。我借了一句家乡话跟他说,“是你知道中文里有一说叫做‘刀不误砍柴工’这样能最大限度的降低错误几率”我要求John 在协助厂家工程师的时候,详细了解他们检查排除故障的过程以便 今后遇到类似问题可以尽快解决。

已经是下班时间了, 另外一个部门的同时给我打电话:“说, 老大啊,我在回家的 路上呢,给你听听收音机”他把车载收音机开 响,广播里播音员磁性的声音通过听筒传过来“某高速公路车流也非常缓慢...本台给您提供最新的交通状况,平时我们会邀请你们随时浏览我们网站得到最近更新,可是今天我们网站出现了些技术问题,我们的技术人员正在极 力抢修”我心里暗想,等我休假完了去找那播音员算帐去。

厂家工程师赶到进入机房的时候,已经是晚上十点了。他们跟John简单了解了情况之后对NAS系统进行了初步检查,结论是系统没有问题,只是因为某些错误配置 引起系统恐慌才进入维护模式的。我问他们有没有系统日志记录误操作的过程,哪里出现的错误,他们没有回答,说先把故障排出再说。

已经进入大年初一了,NAS 系统终于恢复了正常操作模式。操作系统组已经换了一批值班操作人 员了。这时请求他们恢复对NAS的连接,然后 把所有网站服务的数据源转回使用NAS。我请厂家工程师和John 在电话上多留几分钟以防万一需要NAS需要调整。同时,我向John 了解协助厂家工程师的收获,问他厂家做了些什么。他的回答让我有些失望:“They did nothing (他们啥也没做啊)”我询问厂家工程师的是否可以帮我们检查日志,他们说已经下载了全 部日志,明天会向我报告结果。... 几十个实时网站逐步恢复正常服务。在和厂家工程师互换了联系方式之后,他们离开了电话会议。又经过一个多小时操作系统组和我们部门成员的艰 苦奋战,终于在凌晨两点把近两百个网站全部恢复。

我的年三十算是给泡汤了,这样一个事故出现,也只好取消休假。年初一中午起床后,催问厂家维修工程师关于日志分析结 果。他们的结论,虽然让我有所震动,倒也在我意料之中。他们告诉我,在机房里,有很多事情不便说。他们发现日志从早上十点到晚上八点的内容被删除了。也就 是说 John 单独在机房时候的记录系统 记录都丢失了。但是他们从操作系统的日志上找到了他的具体操作。维修工程师说:“果他当时告诉了我们他做了什么,或者把有关日志给我们,也许就不用我们那么大老远从南方飞过来,电话里就能解决问 题,也会节省你们很多时间了。”

因为存储组不属于我们部门,我向他们部门领导报告了事情经过,因为他们部门的错误造成近两百个网站服务中断十五个小 时。对于 John 的工作失误我罗列了以下 几项:
。没有遵守工作流 程,在成品系统上的操作没有经过试验和操作测试
。没有申请变更管理,擅自进入机房对成品系统进行修改
。没有记录操作过程,增加了故障排除的难度
。事故发生后,没有全部公开事故发生经过,甚至撒谎并且企图销毁 系统记录,给故障排除制造了人为障碍。

对于
John 的技术错误或者操作失误,我表示完全可以接受理解,如果他有完整的变更管理,即使产生了误操作,也可以按照变更档案 的指示,或者修复或者回滚。这样事故的时间会很短,甚至由于系统的缓冲作用,短时间的NAS掉线也许可以被系统容错逻辑给忽略。但是因为他的可避免失误造成 NAS 长时间掉线,这是不可原谅的。我向他们部门负责人建议给 John 三个月观察期,以期改进。

三天之后收到他们部门转发过来的通知。John 已经不被公司雇用了。他的上司私下给我打电话,说这是今年以来 最严重的事故,已经引起集团总裁的注意 (恐怕他也是从收音机里知道的),他也没法把 John 留下来了。只好再另寻高人了。

高兴

感动

同情

搞笑

难过

拍砖

支持

鲜花

发表评论 评论 (1 个评论)

1 回复 yulinw 2010-3-23 23:23
希望John可以接受教训~~

facelist doodle 涂鸦板

您需要登录后才可以评论 登录 | 注册

关于本站 | 隐私政策 | 免责条款 | 版权声明 | 联络我们 | 刊登广告 | 转手机版 | APP下载

Copyright © 2001-2013 海外华人中文门户:倍可亲 (http://www.backchina.com) All Rights Reserved.

程序系统基于 Discuz! X3.1 商业版 优化 Discuz! © 2001-2013 Comsenz Inc. 更新:GMT+8, 2024-4-26 18:03

倍可亲服务器位于美国圣何塞、西雅图和达拉斯顶级数据中心,为更好服务全球网友特统一使用京港台时间

返回顶部