[原创]亡羊补牢，为时已晚

申请免费试用、咨询电话：400-8352-114

A集团是全球知名的成衣制造商。一个偶然的机会，我应聘进入了其在广东某地的分厂。分厂承担着整个集团的辅料生产。2000年当下流行的ERP远未成熟，那是MIS一统天下的时代。但在信息化建设方面，集团还是紧跟着时代的脚步。一套辅料生产MIS系统支撑着辅料厂的全部日常业务运行。如果这个MIS系统停止一个小时，那么由此带来的直接损失估计在200万左右.。

MIS系统的服务器硬件采购自一家全球知名的厂商。双PIII XEON 1G和36GX5个1+5阵列，RAID1(镜象)+RIAD5(3个磁盘)另加外置SCSI HP磁带备份机，系统 WINDOWS NT4.0和SQL7.0。购买的服务是金牌服务。

我的任务重复而简单。每日早上9点到公司对磁带机磁带进行更换。由于当时我对服务器没有管理权限，因此对服务器的检查仅限于观察各个信号灯（红灯是故障，绿色灯是正常，黄色等正在读写操作或者初始化）是否正常。服务器维护由集团系统维护人员每周一通过PC ANYWHERE远程连接检查，包括磁带机的备份。就这样我的维护工作平淡无奇地持续了半年，直到有一天出了问题。

那天，当我象往常一样将目光扫向服务器时，红色的灯光映入眼帘，而且一亮还是两个。仔细看去红灯亮在RAID5的位置，两个红灯代表三个磁盘中两个出现了故障。平静如水的心底泛起了点涟漪。按规定先打电话通知直接主管。毕竟昨天的数据还在，即使硬盘损坏采用手工补单的方式也可以找回丢失的数据。“还好我们有磁带机备份，看来多一个备份，多一份心安呐。”我的心情并没有因为这个故障受到什么影响。

我开始按步骤检查服务器硬件是否属于真的损坏。重新启动服务器确认故障依旧。根据售后条款确认服务器还处于硬件商提供的金牌服务周期内，我马上拨打了硬件提供商的800电话寻求技术支持。他们根据我的现象描述提供了电话远程支持。我按此进行操作：

打开磁盘阵列柜，再次启动服务器自检至阵列柜。进入NetRaid管理程序查看阵列信息，发现硬盘ID0与硬盘ID2状态为Failed，运用修改配置将硬盘ID0强制OnLine，重新启动服务器，在进入NT前的硬件自检时，出现硬盘ID2，ID0依次闪红灯，访问D盘失败。第一次尝试失败。

接着第二次尝试。x,q),Wd2o8[W5A打开磁盘阵列柜，启动服务器。进入NetRaid管理程序选择磁盘阵列，将阵列配置信息清空，然后新建磁盘阵列信息（不作初始化），并将硬盘ID2与ID0强制OnLine后，重新启动服务器，在进入NT前的硬件自检时，问题依旧。尝试访问D盘再次以失败结束。

事不过三，我打算做最后一次努力。关闭磁盘阵列柜，将磁盘阵列柜上的所有3块硬盘全部拔除，启动服务器，正常进入NT。打开磁盘阵列柜用NetRaid管理软件，将硬盘ID0，ID1，ID2，进行热插拔，但在进行至硬盘ID0，ID2时软件检测不到此硬盘。到这个时候我们意识到RAID5受到了最致命的情况，同时出现了2块硬盘的故障。此时，惟一的选择就是启动IT处理应急方案。我立即启用备用服务器。因为备用机的数据库没有数据，需要将磁带机的备份数据导入。在场的同事都忙碌了起来，着手准备恢复最近一次磁带机的备份数据。

“不对啊！”负责将备份数据导入服务器的同事一声惊呼让大家的神经紧张了起来。“怎么不对了？”“数据恢复过来的时间不对，怎么是一个半月前的数据？”几个脑袋凑到了只有十几寸的显示器前。几双眼睛仔仔细细地把恢复好的数据察了一遍。的确是一个半月前的数据。“是不是你拿错了磁带？”一个同事问我。“不会，就这么大点地方又没放到其他地方我怎么会拿错。”我自己也在奇怪着。

现在大家已经没有心思去追究这个问题。我重新又复查了一遍，经过详细检查15盒磁带的内容。发现最近有效数据的的确确是一个半月前的。随后检查服务器的备份机制，结果发现服务器的备份任务自一个半月前就停止工作了。汗，开始往外冒！

随后，启动第二步IT应急方案：恢复硬盘数据。

分厂领导和IT经理带上服务器驱车20多公里连夜赶到省城。联系一家专业数据恢复公司。但是为时已晚。由于已经按照800电话的技术指导做过REBUILD，硬盘上的数据无法再恢复。最后得到的结果是原先的数据区在NT4的系统里能看到所有文件名，但所有文件大小全为0K！知道这是一种什么感觉吗？这就象一个即将被洪水没顶的人，向空中张着的双手摸到了一根以为是“救命稻草”的真稻草。生的希望在瞬间又消逝了。想有感觉但来不及有感觉。

就在服务器送去抢救的第二天，厂里决定采用手工单输入的方式恢复丢失的数据。一时间，全厂动员通宵达旦，人人加班。这阵势也是建厂以来少见的。加了三个周末我们才将丢失了一个半月的数据补全。

用“有惊无险”四个字可以为这次事故画上一个句号。毕竟数据最后毫发无损地恢复了。但是事后的责任追究并没有因此结束。

1． 服务器在1个半月前已经陆续出现过系统日志报警，但作为负责这个维护任务的管理员因自身业务比较繁忙（他同时还负责EXCHANGE EMAIL系统及其他大小10个系统的日常备份维护）， 忽视了服务器的异常信息；

2． 我厂MIS服务器本身的条件比较好（相比总厂用了2-3年的设备，我们的设备才投入使用半年多的时间）。平时这台服务器的业务压力并不大。维护人员在前半年的维护周期设定在每周随机检查一次。事实证明这样的规定没有充分考虑到服务器可能存在的风险；

3． RAID5磁盘在用3个磁盘做的时候磁盘的读写频率非常高，由于公司是3班倒，系统是24小时运行。导致其中2块硬盘过早出现老化故障。

4． 机房环境比较差，不是标准机房，尤其是地面是瓷砖地面减震效果差。机房平时人员走动频繁（分公司机房和IT员工办公室是在一处）

以上几点的疏忽导致分厂在这次事故中直接损失在130万，间接损失估计在800万左右。项目经理无奈引咎辞职。虽然“亡羊补牢，为时已晚”，但从更长远的角度看“亡羊补牢，未为晚也”。总厂在调查了具体情况之后做了一些处理：

1． 关键设备维护人员做了重新的分配，增加人手，把每项任务的责任落实到人；

2． 增加一些网络管理软件的应用（OPENVIEW）并规范系统维护方式；

3． 考虑到RAID5的数据安全性不足问题，服务器建RAID尽量采用RAID0+1 或者RAID 1,RAID5+HOT SPACE的方案；

4． 总公司所有的RAID5阵列作了一次系统大检查（对所有磁盘进行运行年限，业务强度进行风险评估）再此基础上做一些业务的迁移和设备的更新；

5． 机房独立，不再和人员办公放一处,减少外部干扰；

6． 由于硬件提供商提供的服务器及其售后服务在此次事故中糟糕的表现，公司在今后几年的硬件建设中逐步放弃该公司设备。那年下半年从另一家全球知名硬件提供商陆续采购了50万的服务器、终端等设备。

一个备份脚本的意外中止，带来数以百万的损失。一次事故让我不再敢小看IT中任何小事。虽然事后做了相应的弥补，但是亡羊补牢的事情还是越少越好。