技術方案之外你還能做什麼

 技術之外你能夠做什麼？這是我經常自己問自己的一句話。

  不能說賣老，自己也參與了很多大型專案的資料遷移，資料升級和維護工作，從參與進來到主導遷移維護，從技術方案的敲定到最後落地，中間還是有很多的事情和經驗需要總結。

   每次看起來很簡單的操作，如果出了問題那可是很緊急的，比如我在一次遷移中，就是做一些資料類的變更，一個rename表的操作竟然提示失敗，在升級的大晚上，眾目睽睽之下如何應對。我們在測試環境做了演練，但是在生產環境還是會碰到很多意外的情況，這個時候就得冷靜下來，先儘可能把其它的變更都做好，然後再來分析這個問題心理上就有了優勢，處理10%的問題，和卡在了10%的問題上給你的心理壓力是截然不同的。當然最後發現是因為生產環境中的物化檢視日誌導致。

   要說我印象中最深的一次大型維護專案，真是驚心動魄，遷移演練了不下三次，但是實際資料庫升級的時候還是碰到了很多意料之外的問題，比如ORA-00600錯誤，有限的時間內處理這些問題還是很有壓力的，我們很不幸碰到了Oracle的bug,在凌晨準備補丁，但是很不幸補丁竟然沒有解決當前處理的問題，所以雖然99.9%的工作都完成了，但是有一個操作總是會丟擲ORA錯誤，就因為這一點，全套的核心繫統差點都回退，那個時候我真是心急如焚，打電話找行業的朋友來看，最後把電話打到了以色列總部，那頭的首席專家給的幾個解決方案都不奏效，時間一點一點過去，我們離回退的時間越來越近，記得那一次處理問題的時候，身後圍了至少十多個人，還是客戶的高階領導。經過一番努力，問題總算解決了，而解決方案可能就是一個SQL語句，一條命令，無論如何算是化險為夷。

     要說讓我最無奈的一次資料回退，那是一次資料遷移的專案，DB層面所有的準備都到位了，但是遷移的時候IO使用率上不去，CPU使用率上不去，結果最後遷移的時候時間點超出了預期的時間範圍，無奈直接做了回退，多少年來第一次遷移專案做回退，對我們產生的影響是很深遠的，而且問題的矛頭指向了資料庫層面，經過定位最後是儲存的原因導致，但是我的技術方案也收到了Oracle原廠的挑戰，因為還沒有這一類相似的技術方案，所以在某種程度上而言，我和我的團隊都有很大的心理壓力，在後期我們一次一次的除錯，拍錯，總算找到了瓶頸所在，排除了儲存和系統層面的問題，遷移工作就很順利了，這樣一次兩次，三次，遷移都很順利，而這個過程中的收穫我覺得是最大的。記得當時我和團隊做遷移的效能測試，大晚上3點多到了酒店，一個朋友到泰國來玩，看著我還在琢磨如何最佳化，他無意中說了一句，這麼做，應該沒有做不成的事情。這句無心的話成了支援我繼續努力下去的動力。

   技術方案之外，其實我們感覺自己能夠做得事情很少，感覺所有的事情都準備好了，就差那臨門一腳，如果達到了這樣的狀態，不妨換點角度來，我覺得一個就是信念了，我有一個不成文沒有任何依據的做法，那就是大型遷移專案前都會去超市買瓶飲料，喝不喝是一回事，但是買了之後心裡會踏實些。記得有一次我睡得晚了些沒有買，結果那次的遷移就非常艱難，就是資料回退的那一次，雖然從科學的角度來說兩者沒有關聯，但是從心理上我覺得是對自己的一點安慰吧。

   我入行不久的時候，記得有一次我們的總監說道，他們在打標一個專案，感覺所有能做的事情都做了，實在沒有其他可做的了，最後還能做什麼呢，他就去廟裡默默上了一炷香，許了個願。

   這裡我不是在宣揚一些不合適和迷信的想法，我只是想告訴大家，技術方案之外，我們還能做些什麼，其實就是最大程度上給自己的一個安慰。

   今天又是一個不眠之夜，資料遷移的任務很有挑戰，相信今晚的升級會一如既往的順利，成功。