【IT168 案例】

　　以前总听说老大们遇到DOWN机的事情怎样怎样，多么急迫怎样怎样，但却一直没有感觉，总以为老大们言过其实。但是前不久一次真实的经历，让我终于对存储工程师这一职业有了更深层的认识……

　　起因是某月某日某时，我的一个哥们准备在新上的IBM DS4800盘阵上做RAID，刚刚做完时钟同步，就看见客户方所有的技术人员一阵风似的全部冲进了机房，带头的主管劈头就是一句：你们干什么了?不待我们缓过神来，6、7个人就开始疯狂的查找各自负责的部分。“赶快，赶快，查找原因!”

　　在过后的几个小时情况调查的时候，我们终于知道，当时的盘阵上面存储着该客户35亿的交易记录和10条要人命的信息!然而，当我哥们完成时钟同步的操作后，盘阵上的所有Volumn Group全部不见!

　　噩梦开始，35亿交易记录不翼而飞

　　只见客户方6、7个人分别查找各自的原因，数据库配置，光纤交换机，网络，主机上的应用，甚至电源、机柜都一一仔细检查过，统统没有问题。于是，所有人的目光都转向了我们：你们到底做了什么?

　　我们一下子也没回过神：“只是，只是在还没有使用的盘阵上做了时钟同步，怎么会和生产系统扯上关系?”

　　大家的目光随即投向了连接KVM和盘阵的HUB。咦?上边怎么还有两根线缆?那么我们现在操作的这两根线缆是?……生产系统盘阵上的!而且使用的是默认IP!!.....我的天!我们前面的操作是做在哪里了啊?为什么没有出现IP冲突?

　　这时我们才意识到我们犯了什么样的错误：我们将KVM连在了生产系统的HUB上，对客户新上的盘阵DS4800和原有生产系统上的盘阵DS4300同时做了一个DEMO，并进行了时钟同步，于是，所有的Volumn Group掉下去了，生产停止了……

　　四处支援，各路神仙爱莫能助

　　搞清楚状况后，已经2个小时过去了。客户方的人也不再理我们，所有的人开始打电话，寻求技术支持。在此后的4个小时中，分别有来自各方的支持陆续赶到，其中包括原设备维护厂商，新设备厂商、总代。以及陆续到来的7位IBM的工程师。我哥们至少20次的向各路神仙说明故障原因，客户方也不停的展示目前盘阵的状况，但事情仍然陷入僵局……

　　在我们感叹客户方主管巨大能力的同时，也被打入冷宫了，被安排在一个办公室里不能出来，更别说进机房。还好客户方还允许我们继续找人支持和打800报修，所以我也有机会看了一眼客户受重创后的盘阵，除了ROOTVG，其他的全都没了，就好像连在一个完全空白的新盘阵一样，我当时那个汗啊!

　　回到办公室继续打800报修，提示音之后是长时间的废话，我一遍一遍的报上姓名地址，说明情况，无论你磨破嘴皮，只有一个结果：除了产品硬件故障不能派人解决。我狂晕!

　　先来的是我们找的代理商方面的小型机和存储技术支持，分别来的3个人同一个看法，这些操作按道理不会出现这样的状况，除了重新启动下看看情况以外好像都别无办法。

　　后来的总代技术明显要略胜一筹，从了解实情经过的方式和建议都是更加的谨慎，看得出来经验丰富。他在打电话给他的公司的时候加上意味深长的一句：记住这个教训吧。但是结论仍然是没有什么办法。

　　与此同时，公司通过其它渠道联系上IBM工程师，于是大家苦等IBM工程师。

　　在此之前总有耳闻，说现在的IBM工程师水平也是一般，于是在心理并没有对他们有多大的期待，心想用户就是迷信，干脆重起得了。事情发生后4个小时，所有人都看完了现场以后，IBM工程师到了。先是2位，再来又是2位，然后是3位。分别来自不同的TEAM负责不同的系统，有负责小机的，有负责存储的，还有售前方案的，但是他们在一起却能很好的协商和达成一致，没有人口出狂言或者轻举妄动。这里不得不客观评价，IBM工程师还是训练有素。

　　实在是我们的误操作愚蠢得太不可原谅，最后IBM的7位工程师也不敢贸然给出任何的动作和建议，唯一的举措就是将现场情况抓图整理，上传给2线。希望有人在线，能有解决的办法……

　　然后，IBM的工程师也走了……