為何 SRE 重視監控與可觀測性#

分散式架構讓系統的故障面更廣，必須要有強大的可觀測性來捕捉問題：

• 主要由 SRE 與運維團隊建立
• 用於主動偵測 production 問題，並讓團隊能夠在使用者察覺前介入
• 屬於 SDLC 的最後階段，但其價值貫穿整個生命週期

沒有 100% 無錯的系統。即使測試再完整，外部因素仍可能造成上線後的故障。監控與可觀測性正是讓 SRE 能即時介入的雷達。

監控與可觀測性的差異#

• 監控（Monitoring）：透過指標與紀錄關注系統狀態，分析資料並判斷影響。例如：CPU、記憶體、HTTP 500 比例、請求/回應比，看到異常就介入排查
• 可觀測性（Observability）：是監控的進階，會自動化關注系統狀態並連結詳細日誌。能主動自我修復；無法處理的異常則彙整數據協助 SRE 找出根因

兩者互補，常用儀表板與日誌共同收集資料。

範例：線上旅遊預訂專案#

上線前兩個月，SRE 團隊：

• 評估監控工具並交給技術主管選型
• 為 CPU、記憶體、回應時間、上線時間建立儀表板，並做書籤化方便巡檢
• 在日誌工具上設置告警，並含詳細 stack trace 協助根因分析
• 部分告警設定為自動修復，例如服務當機時自動重啟

常見工具#

• Prometheus、Grafana
• Dynatrace、New Relic、Datadog
• VMware Aria Operations
• Microsoft Application Insights

多數工具同時支援基礎設施監控、應用監控與可觀測性，差別在於資料來源。例如 Prometheus + Grafana：以容器為輸入即作基礎設施監控；以應用程式日誌為輸入即作應用監控。

工具選型的最佳實踐#

• 先定義系統效能要量測的指標，再挑能拉那些資料的工具
• 設計整合方案，確認工具與架構的相容性
• 評估購買、整合、人力成本（含是否需要特殊技能）
• 選擇開源還是訂閱制
• 確認工具能隨應用一起擴充
• 沒有工具完美吻合需求，所以可客製化的能力非常重要

完整告警流程：從監控到事件管理#

延續線上旅遊預訂的案例，可看到一條典型的告警鏈：

• ELK 收集日誌、Prometheus + Grafana 做儀表板、Slack 為訊息工具、ServiceNow 做事件管理、PagerDuty 負責 on-call 通知
• SRE 與開發在程式碼裡植入指標，雙方共同決定閾值
• Grafana 與 Kibana 都把告警接到 Slack
• 任何指標越過閾值即推播訊息

範例情境#

1. Kibana 設定「全服務 HTTP 500」告警
2. 搜尋服務開始拋 500，Slack 收到訊息
3. SRE 點擊訊息進入 Kibana，看到 stack trace
4. 同時資料庫伺服器出現高記憶體告警；該基礎設施告警同步觸發 ServiceNow 事件
5. ServiceNow 與 PagerDuty 串接，PagerDuty 發 SMS 給 on-call 工程師
6. 完整 stack trace 顯示 HTTP 500 與資料庫高記憶體相關
7. SRE 啟動新的資料庫實例分擔負載
8. 一分鐘內告警解除

完整告警流程不只是單純的「通知」，而是把監控、根因關聯、事件管理與 on-call 串成一條閉環，是 SRE 帶給組織最具體的價值。

進階方向：自動化、相關性、人工智慧#

• 自動化：把已知問題的解法直接放進工具
• 相關性（co-relation）：把跨服務的多個告警自動關聯到同一根因
• AI/機器學習：讓系統從歷史資料學會自動修復未知問題

SRE 應該蒐集 production 的數據點，餵入 ML 演算法，逐步把「人工排錯」的能力轉化為「機器在使用者察覺前自動修補」的自動防線。