小靈通漫遊未來

https://big5.backchina.com/?279512

大年三十的事故 – 變更管理的故事 [2009-09-19]

作者：小靈通漫遊未來於 2010-3-23 23:13 發表於最熱鬧的華人社交網路--貝殼村

通用分類:職場內外|已有1評論

關鍵詞：

農曆新年大年三十。我一覺睡到十一點才起床。多倫多這個鬼天氣，一年中有六個月是冬天，四個月在下雪。現在外面是白雪皚皚，反正今天請假了，現在國內應該是午夜了，打開電視看看國內的慶祝活動吧。再看看本地，雖然天還冷，唐人街也有舞獅舞龍的。

在這樣一個大型企業集團設計維護IT基礎設施的工作真不是太輕鬆。去年趕在聖誕節前把公司近兩百個傳媒網站搬進了它們的新家，十幾部「刀片」(blade)伺服器同時從網路存取系統(NAS)上讀取網站內容，系統根據各網站流量自動申請資源，負荷平衡器（Load Balancer)負責根據活躍服務器數動態把網頁申請轉向活躍伺服器.... 系統從網路結構，伺服器選型安裝，存儲設備，代碼修改，系統測試，網站測試，一直到最終切換，整整花了半年多時間。經過多少個不同部門緊密合作，多少個不眠之夜，總算成功的拔掉了舊伺服器的網線，因為切換而造成的新聞發布凍結時間為零，網站下線時間也為零。整個部門都為這次系統切換計劃的天衣無縫而洋洋得意。在設計過程中曾被質疑NAS的使用，被認為是單點失敗，但是經過多次的商量討論，同時邀請了供應商的參與，用雙通道進入NAS，確保對NAS的讀取萬無一失。切換之後，從外界用戶看來，網站除了速度提高以外，其他變化都沒有，而擁有網站各媒體，除了注意到某些代碼因為軟體系統的升級被優化修改外，也沒有任何工作習慣的改動。與網站擁有者的交流是我上一個月的工作重點，保證舊代碼不會從開發員的桌面上進入新系統造成網頁出錯。農曆新年到了，特意請了2天假，在家好好休息一下。

中午十二點，電話響了，是公司事故管理部門的。報告有用戶投訴一個雜誌網站顯示不了。跟他在電話上的時候又聽他那裡郵件提示音不斷，他就一個一個讀給我聽，一個電台站掉了，兩個，三個，一個電視台，又一個電台，再一個雜誌，十分鐘后他不耐煩的說：「哥們，我想你們的傳媒站恐怕都掉了！」我跑到計算機前面，查了幾個重要網站，告訴他報一個最高級嚴重性的事故給我們部門處理。

電話打到我的組裡，所有的人都戰戰兢兢，報告web伺服器工作正常，應用伺服器工作正常。找到網路部門，報告 Load Balancer 發現所有探針都返回404錯誤，只有很少的幾次探測有效，但下次又立即報錯。這時候我們部門有人半開玩笑的說：「難道真的是單點失敗？」我想到NAS，於是要求事故管理部門通知管理NAS的存儲組，請操作人員參與電話會議。

負責這塊NAS操作的人叫John，雖然有多年的工作經驗，可是做事往往喜歡急功近利，不按照程序。存儲組的同事說，John今天去了處於附近一個衛星城市的機房，手機不通。這時我想起前天電話會議上，他提出今天要去機房。難道這跟他有關? 於是我要求翻查今天的變更管理檔案以了解他今天的改動內容。可是今天變更申請裡面，沒有查到他的名字。

這時組裡有人確認了NAS伺服器目前處於維護模式，只允許單線讀取。我於是請他們把所有的「刀片」全部關機，再一部一部的打開，把重要網站內容複製到刀片的硬碟上臨時恢復部分服務。半小時之後部分網站開始服務，但是因為無法正常更新，新聞網站只能提供上午的信息，徹底破壞了新聞網站的實時性。

下午兩點，事故管理部門終於把John叫到了電話會議上，我問他今天進機房的目的，他說在對同一個NAS系統的另外分區進行操作，因為那個分區目前沒有投入使用，他沒有填寫變更申請。我表示不同意，因為這是成品系統，任何誤操作都可能造成損失，一定要把操作細節步驟，甚至取消改動的步驟清清楚楚寫在變更檔案裡面，而且在操作時嚴格按照步驟執行。這樣萬一出現問題，也有分析依據和儘快恢復。事故管理和變更管理部門的同事也同意我的意見。

但是現在問題已經出現，我們怎麼解決呢？我請組裡的同事做記錄，詢問John是不是誤操作碰到了網站內容的分區。他的回答是：「I did nothing (我什麼也沒做啊)」。既然這樣，那就是NAS系統出問題了。我們緊急呼叫供應廠家要求他們立刻派人來協助維修。廠家通知我們，他們在德克薩斯的工程師已經啟程，應該在天黑之前到多倫多。並且已經要求附近的倉庫把替換設備直接運送到我們機房。我要求John 留在機房協助廠商的工程師。

在等廠家工程師的時候，我們的網站內容複製工作也在進行，越來越多的網站逐漸恢復服務靜態內容。我也借這個時間了解John今天在機房的操作。我了解到他的是要在成品系統上的另外一個分區進行操作，可是，這個操作並沒有在開發系統上試驗過。我表示理解他的性急，但是希望他以後能遵守操作規程，在模擬系統上先試驗，把操作步驟記錄在案到開發系統上測試操作步驟，然後申請變更管理在成品系統上正式操作，因為變更管理申請需要有操作步驟，驗證步驟和取消步驟才能夠被批准，很多人把這個過程認為是瓶頸，試圖繞開。我借了一句家鄉話跟他說，「可是你知道中文裡有一說叫做『磨刀不誤砍柴工』，這樣能最大限度的降低錯誤幾率」。我要求John 在協助廠家工程師的時候，詳細了解他們檢查排除故障的過程以便今後遇到類似問題可以儘快解決。

已經是下班時間了，另外一個部門的同時給我打電話：「我說，老大啊，我在回家的路上呢，給你聽聽收音機」。他把車載收音機開響，廣播里播音員磁性的聲音通過聽筒傳過來「某某高速公路車流也非常緩慢...本台給您提供最新的交通狀況，平時我們會邀請你們隨時瀏覽我們網站得到最近更新，可是今天我們網站出現了些技術問題，我們的技術人員正在極力搶修」。我心裡暗想，等我休假完了去找那播音員算帳去。

廠家工程師趕到進入機房的時候，已經是晚上十點了。他們跟John簡單了解了情況之後對NAS系統進行了初步檢查，結論是系統沒有問題，只是因為某些錯誤配置引起系統恐慌才進入維護模式的。我問他們有沒有系統日誌記錄誤操作的過程，哪裡出現的錯誤，他們沒有回答，說先把故障排出再說。

已經進入大年初一了，NAS 系統終於恢復了正常操作模式。操作系統組已經換了一批值班操作人員了。這時請求他們恢復對NAS的連接，然後把所有網站服務的數據源轉回使用NAS。我請廠家工程師和John 在電話上多留幾分鐘以防萬一需要NAS需要調整。同時，我向John 了解協助廠家工程師的收穫，問他廠家做了些什麼。他的回答讓我有些失望：「They did nothing （他們啥也沒做啊）」。我詢問廠家工程師的是否可以幫我們檢查日誌，他們說已經下載了全部日誌，明天會向我報告結果。... 幾十個實時網站逐步恢復正常服務。在和廠家工程師互換了聯繫方式之後，他們離開了電話會議。又經過一個多小時操作系統組和我們部門成員的艱苦奮戰，終於在凌晨兩點把近兩百個網站全部恢復。

我的年三十算是給泡湯了，這樣一個事故出現，也只好取消休假。年初一中午起床后，催問廠家維修工程師關於日誌分析結果。他們的結論，雖然讓我有所震動，倒也在我意料之中。他們告訴我，在機房裡，有很多事情不便說。他們發現日誌從早上十點到晚上八點的內容被刪除了。也就是說 John 單獨在機房時候的記錄系統記錄都丟失了。但是他們從操作系統的日誌上找到了他的具體操作。維修工程師說：「如果他當時告訴了我們他做了什麼，或者把有關日誌給我們，也許就不用我們那麼大老遠從南方飛過來，電話里就能解決問題，也會節省你們很多時間了。」

因為存儲組不屬於我們部門，我向他們部門領導報告了事情經過，因為他們部門的錯誤造成近兩百個網站服務中斷十五個小時。對於 John 的工作失誤我羅列了以下幾項：
。沒有遵守工作流程，在成品系統上的操作沒有經過試驗和操作測試
。沒有申請變更管理，擅自進入機房對成品系統進行修改
。沒有記錄操作過程，增加了故障排除的難度
。事故發生后，沒有全部公開事故發生經過，甚至撒謊並且企圖銷毀系統記錄，給故障排除製造了人為障礙。

對於 John 的技術錯誤或者操作失誤，我表示完全可以接受理解，如果他有完整的變更管理，即使產生了誤操作，也可以按照變更檔案的指示，或者修復或者回滾。這樣事故的時間會很短，甚至由於系統的緩衝作用，短時間的NAS掉線也許可以被系統容錯邏輯給忽略。但是因為他的可避免失誤造成 NAS 長時間掉線，這是不可原諒的。我向他們部門負責人建議給 John 三個月觀察期，以期改進。

三天之後收到他們部門轉發過來的通知。John 已經不被公司僱用了。他的上司私下給我打電話，說這是今年以來最嚴重的事故，已經引起集團總裁的注意 (恐怕他也是從收音機里知道的），他也沒法把 John 留下來了。只好再另尋高人了。