系統監控與告警白話指南：網站掛了誰先知道、告警怎麼分級才不會狼來了

「網站好像打不開？」如果這句話是客戶在電話裡告訴你的，那代表系統已經掛了一段時間，而你是最後一個知道的。系統監控與告警要解決的就是這件事：讓問題在影響客戶之前、或至少在剛發生的時候，就被該負責的人發現。

很多中小企業的系統是委外開發、上線後就沒人主動看。主機有沒有正常、表單有沒有寄出、付款有沒有成功，全靠「沒人抱怨就當作沒事」。這種做法平常看不出問題，一出事就是最被動的局面。

以下用白話說明監控在看什麼、可用性監控與錯誤監控的差別、告警怎麼分級與安排值班、狀態頁的用途，以及出事後怎麼做事後檢討。

監控到底在看什麼

監控可以想成替系統裝上儀表板與警報器。儀表板讓你隨時看得到狀態，警報器在數字異常時通知人。常見的觀察面向有四種：

• 可用性：系統連不連得上？從外部定期去「敲門」，沒回應就是有問題。
• 錯誤：系統雖然連得上，但有沒有在背後出錯？例如某個按鈕按了沒反應、某支程式一直報錯。
• 效能：回應速度快不快？頁面越來越慢通常是問題的前兆。
• 資源：主機的運算、記憶體、硬碟空間還夠不夠？硬碟滿了是很常見又很容易預防的當機原因。

除了這四種技術指標，還有一種常被忽略的面向：業務指標。例如今天的訂單數、表單送出數、註冊數。系統技術上完全正常，但表單其實已經一整天沒寄出任何一封信，這種「安靜的故障」只有看業務指標才抓得到。

可用性監控：從使用者的角度敲門

最基本、也最該先做的是可用性監控。原理很簡單：由外部的監控服務定期連到你的網站或系統，確認有沒有正常回應。

只監控首頁不夠

許多網站只監控首頁，但首頁能開不代表一切正常。比較完整的做法是：

1. 監控關鍵頁面：首頁之外，加上產品頁、登入頁、結帳頁等真正會帶來營收或服務的頁面。
2. 監控關鍵流程：用模擬操作的方式走一遍「登入→加入購物車→進入結帳」，確認整條流程能完成，這稱為合成監控。
3. 檢查回應內容：只看「有沒有回應」不夠，有時伺服器回了一個錯誤頁面也算有回應。可以設定檢查頁面上是否出現特定文字。
4. 監控憑證與網域到期：網站加密憑證或網域忘記續約，整個網站會突然無法存取，這類問題完全可以提前預警。
5. 從多個地點檢查：單一地點連不上可能只是網路問題，多個地點同時失敗才比較可能是真的掛了，能減少誤報。

錯誤監控：抓住「沒掛但壞了」的問題

可用性監控只能告訴你系統活著，錯誤監控則告訴你系統有沒有在背後出錯。這類工具會收集程式執行時發生的錯誤，整理成清單，標出發生次數、影響的使用者與發生的位置。

錯誤監控的價值在於：

• 在客戶抱怨前發現問題：某個瀏覽器版本按不了送出鈕，客戶多半不會回報，只會默默離開。
• 縮短查錯時間：工程師拿到的是具體的錯誤位置與當下情境，而不是「客戶說怪怪的」。
• 看出新版本有沒有帶來問題：每次更新上線後觀察錯誤數量的變化，可以很快判斷要不要退回上一版。

錯誤監控和部署流程是一起運作的，新版本怎麼上線、出問題怎麼退回，可以參考開發環境與部署流程說明。

告警分級：不是每件事都要半夜叫醒人

監控做起來之後，最常見的問題不是「沒有告警」，而是「告警太多」。一天收到幾十封通知，久了大家就不看了，等真正重要的那一封出現時，也一起被忽略。這就是所謂的告警疲勞。

一個實用的三級分法

等級	意思	例子	通知方式
緊急	客戶已經受影響，必須立刻處理	網站完全打不開、無法付款、無法登入	電話或即時訊息，直接找值班者
重要	部分功能異常或即將出問題，當天內處理	錯誤數量明顯上升、硬碟快滿、憑證即將到期	即時訊息或工作群組
提醒	需要留意但不急	回應速度略慢、單次零星錯誤	每日彙整報告

分級時的幾個原則

• 以客戶影響來判斷，不是以技術嚴重度。資料庫重啟一次，如果客戶完全沒感覺，就不需要緊急告警。
• 每一則告警都要有對應動作。收到之後不知道要做什麼的告警，應該刪掉或降級。
• 持續一段時間才發出。瞬間的波動很常見，設定「連續失敗幾次才通知」可以大幅減少誤報。
• 定期回頭檢討。每隔一段時間看看哪些告警從來沒被處理過，那些多半就是噪音。

值班與通報：告警要送到確定有人看的地方

告警最大的盲點是「送出去了，但沒有人收到」。寄到一個共用信箱、發到一個沒人在看的群組，都等於沒有告警。

值班安排的基本問題

• 誰收第一手告警？有內部工程團隊就排輪值；沒有的話，通常是維護廠商，再抄送公司內部一位窗口。
• 多久沒回應要升級？例如緊急告警發出後一段時間沒有人確認，就自動通知下一順位的人。
• 非上班時間怎麼辦？如果系統夜間與假日也有客戶在用，就必須事先約定這段時間的處理方式與範圍。
• 誰負責對外說明？技術人員專心修，對客戶與內部同仁的溝通由另一個人負責，避免修的人一直被打斷。

這些約定如果是委外維護，一定要寫進合約，包括回應時間、處理範圍與聯絡管道，相關條款可以對照網站維護費用與合約指南。

狀態頁：出事時主動說，比被追問好

狀態頁是一個獨立的網頁，用來公告系統目前是否正常、正在發生什麼問題、預計何時恢復。它的用途是：

• 減少重複詢問：客戶與同仁自己就能查到狀況，客服不用一則一則回覆。
• 展現掌握度：主動公告「我們已經知道、正在處理」，比讓客戶自己發現更能維持信任。
• 預告維護時段：計畫性的系統維護提前公告，客戶可以避開。

狀態頁要放在跟主系統分開的地方，否則主系統掛了，狀態頁也一起掛，就失去意義。公告文字也要用一般人看得懂的語言：

目前部分會員反映無法登入，我們已確認問題並正在處理。訂單與付款不受影響。下一次更新時間預計於一小時內。

不需要寫技術細節，但要寫清楚影響範圍、目前狀態、下一次更新的時間。

事後檢討：目的是讓同樣的事不再發生

系統恢復之後，工作還沒有結束。每一次影響到客戶的事件，都值得做一次事後檢討，重點是找出流程與系統的弱點，而不是追究是誰的錯。一旦變成究責，大家就會傾向隱瞞，下次只會更晚被發現。

事後檢討的骨架

可以照這個結構寫，一頁就夠：

1. 發生了什麼：用時間軸記錄，從問題開始、被發現、開始處理到恢復。
2. 影響範圍：哪些功能、哪些客戶、持續多久。
3. 怎麼被發現的：是監控告警，還是客戶回報？如果是客戶先發現，代表監控有缺口。
4. 根本原因：不只寫「伺服器當了」，要往下追問為什麼會當、為什麼沒有提前預警。
5. 做得好的地方：哪些處置有效，下次要保留。
6. 改善行動：每一項都要有負責人與完成時間，例如新增某項監控、補一份操作說明、調整告警門檻。

改善行動常常會指向備份、擴充或安全性的不足，對應的做法可以參考網站備份與災難復原與流量高峰與壓力測試。

業主可以先做的監控自查清單

不需要一次建立完整的監控體系，以下這份清單可以先對照現況：

• 網站或系統掛掉時，是否有自動通知，而不是靠客戶回報？
• 監控範圍是否包含結帳、登入、表單送出等關鍵流程，而不只是首頁？
• 網域與加密憑證到期前是否會收到提醒？
• 告警送到的人或群組，確定有人在看嗎？
• 非上班時間出事，誰負責處理、怎麼聯絡，有寫下來嗎？
• 有沒有一個地方能對客戶公告系統狀態？
• 上一次系統出問題後，有沒有留下紀錄與改善行動？

有幾項打不了勾，就從那幾項開始補。

如果你不確定現在的系統出事時誰會先知道，NETVANA 可以協助盤點監控缺口、設計告警分級與通報流程，並把監控納入日常維護。軟體服務一律採詢問報價制，歡迎與我們聯繫，說明你的系統規模與目前的維護方式；相關服務內容可參考軟體服務介紹。

延伸閱讀：出事後怎麼把資料救回來，看網站備份與災難復原；活動前怎麼確認系統撐得住，看流量高峰與壓力測試；新版本怎麼上線與退回，看開發環境與部署流程說明；監控之外還有哪些基本防護，看企業網站資安基礎；主機方案怎麼挑，看中小企業雲端主機選擇。