倍可親

大年三十的事故 – 變更管理的故事 [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 留下來了。只好再另尋高人了。

高興

感動

同情

搞笑

難過

拍磚

支持

鮮花

發表評論 評論 (1 個評論)

回復 yulinw 2010-3-23 23:23
希望John可以接受教訓~~

facelist doodle 塗鴉板

您需要登錄后才可以評論 登錄 | 註冊

關於本站 | 隱私權政策 | 免責條款 | 版權聲明 | 聯絡我們

Copyright © 2001-2013 海外華人中文門戶:倍可親 (http://big5.backchina.com) All Rights Reserved.

程序系統基於 Discuz! X3.1 商業版 優化 Discuz! © 2001-2013 Comsenz Inc.

本站時間採用京港台時間 GMT+8, 2024-11-14 23:58

返回頂部