昨天我們談到部署，也就是說完成過去團隊所規劃的轉型實作，團隊的服務就發佈至線上開始運作了

再來就是如何維持線上服務的穩定性，也就是今天的主題，團隊導入監控告警機制。

以下我們就來看看當時團隊的處境與怎麼實作的。

Situation

剛到這個環境的時候發現是沒有真正的監控告警的，不論是網站或排程，很多時候都是靠使用者或其他單位使用時覺得有異狀之後回報，IT 幾乎都是被動的回應。

• CRM 系統錯誤：操作 CRM 的人員覺得資料有異，或程式回饋與平常有異之後回報請 IT 確認問題。
• Web 功能問題：對外串接等 API 遇到供應商更版或網路不穩定等問題時，必須等使用者回報才能發現。
• Cron Job 異常：當時每天需更新會員資料庫到客服系統，但排程有異狀時，常常需等客服人員找不到對應會員時回報才會發現。
• 不論時哪一種異常回報，IT 幾乎都是處於第二線，無法在問題發生第一時間立即反應處理，錯誤無法在第一時間修正，也因此需要花更多精力和資源進行災害復原。

Task

• 核心業務建立監控機制，確保重點指標都納入監控。
• 有完善的告警及回應流程。
• 自動化機制。

Action

• 首先要確定哪些是支援企業運作的核心業務，找出相關聯的系統、程序、資料，決定要如何設定告警閥值（log, traffic, data volume, ..etc）。
• 針對關鍵指標進行監控，建立異常通知頻道及窗口（包含內部頻道以及供應商窗口）。
• 設置 oncall 人員，確保告警時在第一時間得到應對。
• 針對某些既定的後續回覆動作設置自動化機制：自動重啟、排程自動重試等等。
• Daily 時更新當日異常及處理，確保資訊流通。

Result

• 有了監控告警回復機制，IT 對於提供的服務有更多掌握度。從需要靠其他部門或使用者來回報異常，演變為 IT 主動收到異常並處理完畢後，再提醒相關單位進行對應檢查。
• 搭配告警頻道及 Daily update，沒有直接參與異常處理的開發人員也能夠有足夠資訊，近一步主動提醒對應單位。
• 有了告警頻道，當告警演變成異常事件（incident）時，也能夠快速召集相關人員，加速反應時間。