Cliff的部落格

深入探討

從桃園機場當機談IT維運

■王宜倫

前言

2009年的開始，墨菲定律(註一)空襲桃園機場，移民署境管系統當機事件再一次為所有IT維運人員上了一堂重要且昂貴的課：即使關鍵系統 (mission-critical system) 的儲存設備採用了磁碟陣列 (RAID) 技術，再加上備援系統，在這種雙保險架構下，還是有可能發生資料損毀的問題，而此問題需要3天的時間才能復原。

綜觀全球重大IT異常事件，我們可以容易地發現類似這次「移民署境管系統當機事件」並非特殊個案，類似問題也確實一再上演，因此筆者研究並參考近年來國內外重大IT異常事件後，提出下列IT維運觀念與大家分享，讓不必要的維運疏失降至最低，提升IT整體維運品質。

從桃園機場當機談IT維運

目前各大機關團體、公司組織的關鍵系統大多採用具備備用 (redundancy) 設計的IT設備，設備本身包含多個電源供應器、磁碟陣列設計、架構上的叢集 (cluster) 技術，以及更完整的災備系統 (Disaster Recovery system) 等，都讓系統穩定性獲得大幅度的提升；在資訊科技不斷的進步下，電腦系統配合cluster架構，在硬體上的可用性 (availability) 幾可達99.999%，甚至99.99999%，但是這也僅限於系統層面，並非實際運作層面，"可用性" 除了考量系統硬體架構層面，也包含應用程式設計與操作維運層面；2007年，國際太空站 (International Space Station, ISS) 也曾經發生一個具備三重備援 (triple redundant) 的電腦系統因其中一個電源供應器設計錯誤，再加上後續處理人員操作錯誤，進而導致其環境控制電腦系統停擺；由此實例可知，就算是IT設備已具備redundancy的容錯 (fault-tolerance) 架構，但是若沒有搭配嚴謹的維運程序與訓練有素的人員，投資了龐大的IT成本，仍有可能因為系統設計本身的缺失，或是人為操作錯誤，導致容錯架構無法發揮功效，造成系統停止運作，進而造成業務營運停擺。

暫且先不討論移民署境管系統問題根源 (root cause)，資深IT人員應該都有相同的體認 -問題總與『改變』相伴；因此電腦系統的升級，不論是應用系統、作業系統、資料庫、硬體、網路還是其它設備軟硬體元件，都令人戒慎恐懼，但儘管再如何小心謹慎，系統升級時發生問題的惡夢總是不定時爆發，而且通常某個細節一定會發生問題。因此為了「降低」電腦升級的風險，第一個原則就是要經過完整且嚴謹的測試，關於這點，大部分公司都做的很好，然而，僅有少數公司會針對升級失敗準備好應變計畫，也會針對應變計畫進行測試，確認此應變計畫是可行的，一但發生問題，可立即依據應變計畫採取權宜措施，例如切換備援系統或是進行系統復原 (rollback)；在2008年，因系統升級發生問題的公司如Blackberry (RIM)、Skype、Paypal等公司，都有一個共通點：「沒有應變計畫」，導致升級失敗後，業務營運受影響時間長達數天到數週。

"當發生問題時，人會變笨"－Wendy Bartlett

當系統發生問題時，尤其是重大問題，IT人員將立即面對龐大的壓力，一方面要儘速找出問題發生原因，恢復系統正常運作，另一方面，管理階層介入問題的處理，在問題和系統狀態混沌未明的情況下，要IT人員立即提供問題發生原因、替代解決方法 (workaround)、是否要切換備援系統、何時系統可恢復運作、影響層面等更多的 "問題"，都會造成IT人員更大的負擔，在此壓力下IT人員可能會錯誤判斷或採取錯誤處理方式，造成更大的問題。要避免這種突發的壓力加諸在IT人員身上，最好的方式就是提供良好的緊急應變處理程序讓IT人員依循，若IT人員對於這些處理程序受過完整的訓練，並儘量將這些程序予以自動化，可大幅降低IT人員的心理負擔，減少人為錯誤的發生，加速問題解決。

完整確實的系統文件是IT管理的必要之惡，對IT人員而言，通常 "惡念" 戰勝 "必要"，要產製和整理這些文件是非常繁雜且耗時的工作；大部分公司的IT系統文件都較為缺乏，自基礎設施(水、電、空調)、整體網路架構、系統版本架構 (system log)、資料庫文件、程式碼的註解等靜態文件，到各種作業程序、監控檢查項目 (checklist)、異常處理程序等動態文件，不是缺乏就是久未更新或是沒有管理方式。完整且即時更新的文件，對於日常系統維運和程式維護甚為重要，因此，必須提供程式開發人員、操作人員和系統網路管理人員正確的文件；過去部分公司在IT管理上導入ISO 9001，近年來較熱門的ITIL或是ISO 20000都可強化和落實系統文件的管理。

IT維運管理經驗分享

綜合上述說明，可以很清楚的認知要避免IT重大問題的發生，除了IT設備本身的穩定度與架構設計外，最重要的還是要靠IT維運管理流程來避免或降低影響層面；筆者願提供下列IT維運管理經驗，與讀者一同學習分享：

一、建立標準作業流程
針對系統操作、應用系統操作、問題處理、復原等各項作業，建立標準作業程序，讓IT人員執行時依此程序執行，平日IT人員需要接受訓練，熟悉與了解程序內容與相關性，並持續改善這些程序，讓程序符合目前作業需求。

二、落實預防矯正措施
監控系統狀態、掌握系統資源使用情況及系統效能運作情形，一但發現系統問題，建議儘量在最短時間內處理，恢復系統正常運作，雖然IT系統架構可能具備容錯設計，可避免單點故障 (single point of failure) 造成影響，但是，不要挑戰 "墨菲定律"。定期檢討系統殘存問題、效能運作以及各種作業流程，若系統容量資源使用到達預警門檻，立即提出建議；若目前程序不符實際作業需求，立即調整。

三、準備好可用的災難復原計畫
一但決定要切換到災備系統 (Disaster Recovery system)，IT人員一定會感受到真正的備援切換過程與平日的災備切換演練是不同的，真正的災備切換可能在交易最忙碌的時間 (peak time)、遭遇的問題無法預測、可負責切換的人力不足。最重要的是，一但切換失敗就沒有系統可供交易運行，所以，切換必須要成功，切換程序文件和平日訓練一定要落實。

四、永遠要有復原計畫 (rollback plan)
無論升級的準備和測試有多完整和嚴謹，在升級為線上系統 (production system) 時仍有發生問題的風險，針對任何的升級，都需要準備好可行的且經過測試的復原計劃 (rollback plan)，避免升級計劃成為孤注一擲 (all-or-nothing) 的行為。

五、有效率的IT廠商管理
建立內部IT人員與外部廠商的合作模式，將廠商的技術人力當作可運用的資源。通常，大部分公司的IT設備都同時包含多家廠商，當問題發生時公司內部IT人員必須要更有效的管理IT廠商，避免廠商相互指責問題，在問題尚未釐清之前，所有人都有責任，都需要針對所負責的範圍去研究、分析可能的問題點，直到找到問題為止。

六、建立良好的溝通管道
建立單一對外窗口，統一對外發言，協調和解決所有外部事件，並處理使用者和顧客的抱怨。同時做好媒體溝通管道，傳遞正確的訊息，避免媒體引用以訛傳訛和未經求證的訊息，防止事件無限制的擴大。對內需將工作狀況以及預計進度回報給管理階層，以利管理高層人員能採取最有效的措施。
七、代價昂貴的經驗 - 測試、測試、再測試
運作良好的系統通常都不易發生問題，問題通常發生在 "Change"，所以，當系統有任何異動，例如安裝patch或進行升級 (upgrade、migration)，都需要進行測試，測試的目的除了確保產品的穩定度外，也在確認維運人員對系統的了解與熟悉程度。

註一：墨菲定律(Murphy's Law)：有可能發生的問題，就一定會發生，而且通常發生在你最不願見到的時間點，導致最糟的情況。

.