前言 :
這案例發生在 2008 左右
其架構應該為 IBM AIXserver再以FC連結DS4300.原文金額為RMB.標題直接換算成NT.
轉載文
以前總聽說老大們遇到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的工程師也走了……
緊急預案，又出節外生枝
與此同時，客戶方也臨時召開緊急會議，經討論後給我們公佈了他們的緊急預案措施：凍結原有的業務存儲系統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，咦？怎麼出錯了？
再來一遍還是不行！這時候，一直鎮定的，老練的，不懂技術的銷售一直直勾勾瞅著屏幕，憋不住了問一句：「這是怎麼回事？」操刀的哥們沒有回答，讓我把某一塊盤拔出來，等一下再插上……故障依舊，關掉再開盤櫃……故障還是依舊……
柳暗花明，35億交易數據失而復得
銷售看不下去了，但是畢竟好涵養，壓了壓焦慮的心情，拉我到外面抽菸去了。煙霧繚繞中，給我講了上次誤操作將一所大學的學籍檔案全部刪除的事情……。最後，掐滅了菸頭：「走，回去看看！」
回到機房，RAID居然已經做好了。問了我哥們，原來是這樣：這台DS4300上原來的幾塊盤是做過RAID的，但是缺少了一塊。於是盤陣總認為後來插上的硬盤就是原來缺的那塊硬盤，但實際上不是，而且我們還插了不止一塊盤，所以就出錯了。
哥們將所有的盤都拔出去，再將盤陣重起，清除裡面的信息，再關閉，把盤都插回去，就一切OK了。
哦，這樣啊！心算是放回肚子裡了。再接著就是普通的劃區後的工作，忙到了天亮。
這邊問題暫時解決了，但原來的陣列還一動不動躺在那裡，裡面的數據仍然沒法兒拿出來，所有人的希望也就寄託在IBM的二線上，希望他們能夠拿出最佳的解決方案來。
第二天早上9點整，IBM的工程師來了，並且帶來了2線的解決方案。很可惜具體的操作方式他們不肯透露，大意是將上面的RAID按照原來最初的重新做一遍。由IBM的工程師講解方案，客戶方系統維護人員操作。整個恢復過程中，現場氣氛緊張啊，連插拔光纖的動作都做得極為謹慎，所有操作完成後，一查看， 35億的交易數據總算是失而復得！
當時那個興奮啊，要是有蛋糕都能開個PARTY！然後是一些後續的工作，又忙了大半天才結束。
走出客戶的大廈時正是第二天中午，我這才意識到已經2天沒有看到這輪太陽了，沐浴在久違的陽光下，發現周圍的一切都是這樣的美好！
後記：噩夢方醒不忘經驗教訓
曾經聽老大們講過，小型機和存儲盤陣的操作都極為複雜，很多地方和PC機器完全不同。操作PC機的，可以經常自己嘗試和摸索，但在小型機和存儲系統上瞎鼓搗就是自己找死。只要做過客戶系統維護的人員都能深切感受到這份壓力，不少都曾經親身經歷過這種要人命的時刻。曾經聽說過有人深夜3點打車去五百里之外，和夜裡9點打車去千里之外的情況，一旦客戶系統發生問題，影響業務運營，就是打飛機也一定要趕到客戶現場。
還有一個問題就是，由於實施維護的時候壓力大強度大，所以經常工作到深夜，加上開的窗口會比較多，這個時候是極易出現人為錯誤的時候。所以老大們告誡我們，再複雜的工作一定要一步一步按部就班，另外每做一步操作，保留數據的備份是極其重要的，否則敲錯一個命令，就有可能帶來追悔莫及的損失，而這樣的例子也的確不在少數。
上週四剛剛將借來的那台DS4300還了回去，仍然記得那天打車去取這台機器的緊張勁兒。心中不免還是有點那麼擔心：如果給的方案不好用呢？如果這台備機不好使呢？如果在後面長時間、高負荷、緊張的情況下操作失誤呢？如果再有其他設備的損壞？如果……我實在不敢想像下去了。如果，這件事能給所有的同行一點幫助，我就會很欣慰了。
——————————————————————————————————————————————
後記
噩夢開始往往是細節的疏漏，文章開始於一個小的疏忽，接踵而至是各路神仙愛莫能助的技術問題。面對這樣的嚴重事件，從ITIL角度看，應該算是啟動了緊急預案。沒有循規蹈矩地走事件、問題處理流程，只有現場的特殊處理流程。從文章對事件的描述過程沒有看出慌亂，雖然實際過程一定很緊張，但是看得出處理的步驟仍然是井井有條。
「分別來自不同的TEAM負責不同的系統，有負責小機的，有負責存儲的，還有售前方案的，但是他們在一起卻能很好的協商和達成一致，沒有人口出狂言或者輕舉妄動」文中對IBM工程師的評價可以作為IT服務協同合作的標準了。不同的部門卻能在在處理問題上達成一致，沒有推脫，沒有看笑話的成分。
問題解決了，再回到文章的開頭。KVM連接的時候為什麼沒有人注意到連錯了HUB？也許這是一個業務上的疏漏，也許是人的疏忽。業務疏漏再追溯一下，可能是沒有一個明確的流程來指導伺服器作Raid操作，工程師們像往常一樣憑經驗操作，但沒想到這一次出了大紕漏。因為憑成功經驗的做法導致事件嚴重的幾率較少，所以很多時候我們仍然相信經驗，而忽視對流程、步驟的重視。認為那是多餘、繁瑣、呆板和沒有創造性的。「出來混遲早要還的」《無間道》的這句話在ITSM同樣適用。只是不同的領域對這句話的體會各有不同，類似這次35億交易數據的存儲領域的體會可謂刻骨銘心。他們下次一定會老老實實地按照「多餘、繁瑣、呆板和沒有創造性的」的流程和步驟去作Raid。但是其它不一定帶來「刻骨銘心」領域呢？他們是否願意這麼做，還是依然認為「多餘、繁瑣、呆板和沒有創造性的」？
這是最可怕的！人的疏忽造成嚴重事件發生。有嚴格的流程和步驟但依然我行我素。也許是因為憑經驗從來沒有失過手，沒有撞到南牆，他們是不會回頭。對於此，真的沒有什麼好的辦法。只有等到他們親自體驗到「刻骨銘心」的教訓之後才能意識到未雨綢繆的真正含義。所以，驚心動魄的48小時搶救35億交易數據的故事還會再發生。
貼上這篇文章的用意在於警告自己：IT服務沒有小事，只有重視！
DS4300
OSSLab評論
1. 這案子其實可以用Soft mount方式來處理.不一定要用此方法來做Lun恢復.
2.每顆硬碟倒數512MB區域為陣列卡參數.可參考如圖.
Array name
Logical Drive ID ,Lun Name , Raid Level , Lun大小 , Stripe( Segment) Size,HDD Serial number , Enclouse id +slotid.
重要資料請協同資料恢復公司更能保障重要數據
