亲历惊心48小时抢救35亿交易数据

亲历惊心48小时抢救35亿交易数据
内容导航： 噩梦开始，35亿交易记录不翼而飞 四处支援，各路神仙爱莫能助 紧急预案，又出节外生枝 柳暗花明，35亿交易数据失而复得 后记：噩梦方醒不忘经验教训
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的工程师也走了……
1


紧急预案，又出节外生枝
    与此同时，客户方也临时召开紧急会议，经讨论后给我们公布了他们的紧急预案措施：冻结原有的业务存储系统DS4300，连夜在新的存储系统DS4800上做RAID，建Volumn Group，将所有应用和数据转移，先让系统跑起来，数据再说。于是，大家纷纷给家人电话或者短信“今晚通宵加班，我不回去了。“
    这时回到那两台为了配置它们而闯祸的DS4800面前，它们却吓得再不敢抬眼看我们，死活就是不和我们的管理系统连接。。。。气得我•##￥%……―
    客户算是有水平了，并没有在这个时候追究责任。而是让我们去处理问题，如果这个问题都没处理好。那，那。。。。。
    看来连DS4800也指望不上的时候，一直在一边帮助客户协调跑前跑后的我们公司的销售经理突然对我说：“你跑一趟，和XXX联系，这是电话，拉一台DS4300回来，再带6块300G的硬盘，就对他说是X总叫你来取的。”我当时那个乐啊！赶紧屁颠屁颠的就打车过去了（那时都半夜了）。到了销售说的地方，领到机器，也顾不得新洗的白衣服了，和司机、库管一起把机器扛到了车上。
    车刚要发动返回客户现场，就收到销售的短信：硬盘拿了么？车还没开到客户大门，老远就看见销售在门口蹲着等着了……所有的人都在期待这台DS4300，但是，新拉来的DS4300却没有接上……
    原来，在场的人七手八脚的把这台救命稻草DS4300抬上楼，打开箱子一瞅，乐了。原来打算用6块300G的硬盘做临时空间有点紧张，只能做RAID5，不能做hotspare，没想到上面整整齐齐的插着7块146G的硬盘，再加上6块300G硬盘，嘿，这下够了！
    销售在这个时候还不忘打趣：“慢点慢点，这可是咱们的最后一棵救命稻草，有了它我就算是有了一条活路，没它我就得从这窗户口跳下去了。嘿嘿。。”要知道，当时我们可是在19层的机房啊。
    上好架，通上电，开始练。第一个分区100G，ok！第二个分区，400G，咦？怎么出错了？
    再来一遍还是不行！这时候，一直镇定的，老练的，不懂技术的销售一直直勾勾瞅着屏幕，憋不住了问一句：“这是怎么回事？”操刀的哥们没有回答，让我把某一块盘拔出来，等一下再插上……故障依旧，关掉再开盘柜……故障还是依旧……
1



柳暗花明，35亿交易数据失而复得
    销售看不下去了，但是毕竟好涵养，压了压焦虑的心情，拉我到外面抽烟去了。烟雾缭绕中，给我讲了上次误操作将一所大学的学籍档案全部删除的事情……。最后，掐灭了烟头：“走，回去看看！”
    回到机房，RAID居然已经做好了。问了我哥们，原来是这样：这台DS4300上原来的几块盘是做过RAID的，但是缺少了一块。于是盘阵总认为后来插上的硬盘就是原来缺的那块硬盘，但实际上不是，而且我们还插了不止一块盘，所以就出错了。
    哥们将所有的盘都拔出去，再将盘阵重起，清除里面的信息，再关闭，把盘都插回去，就一切OK了。
    哦，这样啊！心算是放回肚子里了。再接着就是普通的划区后的工作，忙到了天亮。
    这边问题暂时解决了，但原来的阵列还一动不动躺在那里，里面的数据仍然没法儿拿出来，所有人的希望也就寄托在IBM的二线上，希望他们能够拿出最佳的解决方案来。
    第二天早上9点整，IBM的工程师来了，并且带来了2线的解决方案。很可惜具体的操作方式他们不肯透露，大意是将上面的RAID按照原来最初的重新做一遍。由IBM的工程师讲解方案，客户方系统维护人员操作。整个恢复过程中，现场气氛紧张啊，连插拔光纤的动作都做得极为谨慎，所有操作完成后，一查看，35亿的交易数据总算是失而复得！
    当时那个兴奋啊，要是有蛋糕都能开个PARTY！然后是一些后续的工作，又忙了大半天才结束。
    走出客户的大厦时正是第二天中午，我这才意识到已经2天没有看到这轮太阳了，沐浴在久违的阳光下，发现周围的一切都是这样的美好！
1


后记：噩梦方醒不忘经验教训
    曾经听老大们讲过，小型机和存储盘阵的操作都极为复杂，很多地方和PC机器完全不同。操作PC机的，可以经常自己尝试和摸索，但在小型机和存储系统上瞎鼓捣就是自己找死。只要做过客户系统维护的人员都能深切感受到这份压力，不少都曾经亲身经历过这种要人命的时刻。曾经听说过有人深夜3点打车去五百里之外，和夜里9点打车去千里之外的情况，一旦客户系统发生问题，影响业务运营，就是打飞机也一定要赶到客户现场。
    还有一个问题就是，由于实施维护的时候压力大强度大，所以经常工作到深夜，加上开的窗口会比较多，这个时候是极易出现人为错误的时候。所以老大们告诫我们，再复杂的工作一定要一步一步按部就班，另外每做一步操作，保留数据的备份是极其重要的，否则敲错一个命令，就有可能带来追悔莫及的损失，而这样的例子也的确不在少数。
    上周四刚刚将借来的那台DS4300还了回去，仍然记得那天打车去取这台机器的紧张劲儿。心中不免还是有点那么担心：如果给的方案不好用呢？如果这台备机不好使呢？如果在后面长时间、高负荷、紧张的情况下操作失误呢？如果再有其他设备的损坏？如果……我实在不敢想象下去了。如果，这件事能给所有的同行一点帮助，我就会很欣慰了。