緊急救援案例經驗分析與處理方式

由於資訊系統已經深入日常每一環節，當重要的系統發生問題時，往往造成重大的不便、業務與商譽損失、甚至死傷。因此資訊系統的分級、可用性規劃、異地備援、災難演練，乃至於各種的 SLA、SOA 早已充斥。這些規劃我們另篇再談，在此討論雖有前述規劃，但仍真碰到狀況的緊急救援。

緊急救援案例的成因

就我們多年來實際碰到不同企業、組織發生問題而參與緊急救援的案例，歸納其原因可能有：

• 天災：
  • 火災
  • 企業周遭的電話線被施工挖斷、國際海纜斷線
  • 機件損毀，最常見的是硬碟，網卡或 SAN Switch等
• 人為疏失：
  • 手動誤關電源，異常斷電後導致系統損毀
  • 格式化硬碟、誤刪重要檔案
  • 改變系統設定，如改變 SQL Server 的 Replication 設定、將日常 backup database 的指令加上 with norecovery 選項
  • 資安問題：
    • 外在：中毒、勒索加密、SQL Inject…等。
    • 內部：改變 Security Policy、防火牆規則、註冊機碼、帳戶、目錄權限…等。
• 過版、上線、結案日期/時間截止，但功能仍有缺失，無法過版、上線
• 效能異常
• 資源耗盡，系統容量不足
• 觸及程式 Bug

緊急救援的複合困境

當企業與組織遇到上述情境後，因為排除或解決問題的時間緊迫，而委請我們緊急到場或遠端支援。當實際接觸災難現場後，往往面臨以下的複合困境：

• 環境老舊，新舊交雜，常有十幾二十年前的軟硬體，讓你瞬間走進時空膠囊。
• 相關人員交接不久，前人已經離職，這也往往是造成問題的主因之一。
• 技術駁雜、商業邏輯混亂，往往有概觀，但沒人能解釋清楚細節，不管是架構面的網路、伺服器、安全，或是系統功能面的物件組成，商業邏輯。
• 決策多頭馬車，現場混亂。Infrastructure/Network/Developer/Security 等技術窗口、系統負責人、使用者代表、周邊整合系統窗口各說各話。
• 控管嚴格(金融產業尤甚)，能用於救援的時間/資源有限
  • 跳板機每次僅可申請使用一小時，超過要再申請
  • 系統使用權限、登入密碼當日有效，凡過期的各種資安限制都需要流程申請
  • 系統無法聯外，無法線上搜尋
  • 難以放入查核問題的輔助工具程式，或是解問題的語法、腳本
• 部門本位主義嚴重
• 緊急救援往往發生在假日與下班時間，聯繫、到場、擬定策略的時間短暫且人力有限，而解決/回復有目標時間點。
• 現場難有指揮若定者，沒人敢做重大決定，所做決定可能需要事後追認。
• 來不及測試就套用作法，可能造成更大的災難。

資訊人員緊急救援急難救助包

相信看了上述的困境，會讓救援者卻步。而在我們要走入緊急救援的修羅場之前，最好日常要有那些準備？在半夜出勤時帶的急救包內容為何？

• 發生問題的伺服器往往無法上網，自備能上網的裝置與上網的能力，好透過網際網路查詢問題。
• 隨身的 Notebook 電腦最好有虛擬機與足夠運算力，能模擬部份的問題與測試解法。
• 累積能處理問題的各種腳本語言，例如 T-SQL、PowerShell(因為我們多半處理的是微軟平台問題)以查詢各種情況。
• 小工具程式，例如查程式內容、資源使用、網路封包…等。
• 遠端程式或到場的交通工具(最好有汽車)，可能半夜來回遠地城市，甚至坐落在新闢工業區內的唯一一間廠房，連Google地圖都是錯的。
• 累積 call out 的人脈，解相關問題時能提供專業諮詢。
• 累積廣泛的知識、處理問題的經驗與臨危的情緒管理(最好能笑著面對，讓一群人冷靜下來，多用腦、少動口，小心用手)，敢建議，敢決定、敢執行。

• 先儘量討論各種可能，並測試與檢驗推定。擬定因應作業流程，討論可行性與再次失敗的回復措施。要小心，災難救援的慌亂過程中往往再製造更大的災難。
• 執行 plan A，同時準備 plan B，避免 plan A 失敗後會有更多的慌亂不安。
• 儘量準備可能需要的軟硬體，好置換配件，或重新安裝軟體。
• 備齊相關人士的聯絡方式，並儘可能請他們 stand by。
• 所有解法步驟儘量腳本語言化留存。解決問題的過程往往是反覆來回，要留下腳本語言討論曾做過的與現下困境間的因果，一再增修嘗試。若設定與改變都是靠滑鼠，將很難討論，快速回復，並重新再做與大量套用。
• 過程與結果都要截圖留存。

• 檢討成因與寫法，撰寫文件報告
• 執行改善措施
• 持續監控與調校

以上，簡單就我們過去碰過的緊急救援經驗整理出可能的成因及處理方式。當然，緊急救援的所有狀況都是所有資訊人員最不樂見的，如若碰上，可參考這篇的應變方式，未來我們還會持續整理集英信誠這些年的經驗與各位分享。