希望John可以接受教训~~- 天津爆炸的到底是什么，那么厉害？ [2015/08]
- 温州动车追尾 -- 恐怖袭击? [2011/08]
- 曾经跟西太平洋大学打过一些交道 [2010/07]
- 新版"红色曙光" (Red Dawn) 又重新制作, 把中国抹掉 [2011/04]
- 今年六四怎么了? 都出动了? [2010/06]
- 面试技巧并不是要给人错觉 [旧文翻贴] [2010/04]
- 黄色怎么了 [2010/12]
- 你在互联网上, 一不小心就会成裸奔 -- 也说谷歌和隐私 [2010/10]
- 一个关于乞丐的笑话 - 两个不同版本 [2010/04]
- 也说刘晓波的诺贝尔奖 [2010/10]
- 重读"小灵通漫游未来" [2010/04]
- 地铁上听到两个华裔小美女说话. [2010/05]
- 被人要求代考托福的故事 [2010/04]
- 谷歌离开中国的后遗症开始发作 -- 新的谷歌手机怎么办? [2010/03]
- 谷歌离去, 中国的互联网就落后了吗? [2010/03]
- 新买了部便宜手机 [2010/09]
- 童言无忌(3) 我有一年时间 [2010/11]
- 谷歌, 你所想不到的阴谋 -- 从google 宣布撤出中国市场想到的 [2010-01-15] [2010/03]
- REWRDE 语言学习方式 [2010-03-19] [2010/03]
- 不是我看不懂, 是我老了不明白 [2010/04]
- 童言无忌(1) 黑白世界 [2010/03]
农历新年大年三十。我一觉睡到十一点才起床。多伦多这个鬼天气，
一年中有六个月是冬天，四个月在下雪。现在外面是白雪皑皑，反正今天请假了，现在国内应该是午夜了，打开电视看看国内的庆祝活动吧。再看看本地，虽然天还
冷，唐人街也有舞狮舞龙的。
在这样一个大型企业集团设计维护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 留下来了。只好再另寻高人了。
在这样一个大型企业集团设计维护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 留下来了。只好再另寻高人了。