被動巡檢報告設計：僅異常通報情境

為什麼需要被動巡檢

許多客戶雖然委託遠端代管，但希望日常不被打擾，只在異常時收到通知。若沒有標準化的巡檢報告，日後要追蹤告警脈絡或交接窗口時就會缺乏依據。

前置資料基準

1. 事件分級規則：先定義資訊/警告/重大事件條件，避免不同工程師對同事件有不同處置。
2. 資料保留週期：依儲存容量定義告警、SNMP 指標與聊天紀錄保留天數，確保可回溯。
3. 事件編號一致化：告警、工單與通知訊息使用同一事件編號，避免跨系統比對困難。
4. 通知邊界明確化：先約定哪些事件即時通知、哪些事件進入週期摘要，降低過度告警干擾。

實際採集的資料

1. 設備告警與使用量：直接引用 UniFi/Mikrotik 控制器上的告警、用戶數與錯誤計數，並依現有儲存空間保留歷史紀錄。
2. 關鍵節點 SNMP：僅針對少數核心設備透過 Zabbix、LibreNMS / SNMP 回收 uplink 速率與介面狀態，方便交叉比對告警。
3. 客戶回報：把客戶聊天紀錄或工單摘要收錄到報告，建立異常處理的上下文。

與客戶的互動方式

• 資料用途：回收的告警與 SNMP 指標主要供行雲資訊內部診斷，不會另外提供 Portal 或報表查詢。
• 通知管道：依客戶偏好（Line、Slack、電子郵件等）同步全部異常資訊；除非合約另有約定，平時僅以訊息通知，不會主動產出正式報告。
• 彈性補充：若客戶臨時需要報告或摘要，顧問可依當次需求整理並分享，維持最低限度的資訊同步讓客戶即時掌握狀態。

常見問題與排除順序

1. 告警過多造成疲勞：先調整分級閾值與抑制規則，再觀察噪音是否下降。
2. 同事件重複通知：檢查事件去重鍵（設備、介面、時間窗）是否設定一致。
3. 客戶感受與指標不一致：把客戶回報時間與 SNMP 時序對齊，排除只看單一資料來源的誤判。
4. 事後無法追溯：檢查事件編號是否在告警、工單、通知三端一致流轉。

技術檢核清單

1. 事件分級規則已固定且可重複套用。
2. 告警、SNMP 與客戶回報可用同一事件編號串接。
3. 被動巡檢不打擾日常但可即時捕捉重大事件。
4. 回顧時可完整還原事件時間軸與處置流程。
5. 資料保留週期足夠支援季度或跨月分析。

參考資料

• LibreNMS Documentation
  https://docs.librenms.org/
• Zabbix Documentation
  https://www.zabbix.com/documentation/current/en/manual