可觀測性
你無法修復你看不見的東西。可觀測性必須內建在設計中，而非事後補救。如果為了回答生產環境的問題而需要修改程式碼，那表示儀器化機制出了問題。
規則
- 三大支柱：日誌、指標、追蹤。 每個支柱回答不同的問題——發生了什麼事（日誌）、發生多少與頻率（指標）、為何變慢（追蹤）。三者缺一不可。
- 僅使用結構化日誌。 JSON（或類似格式）。在大規模環境中，grep並非可靠策略。
- 每行日誌都包含關聯ID/追蹤ID。 透過跨服務邊界的標頭傳遞該ID。一個ID就能串起整個請求的旅程。
- 每個端點都要有RED指標。 速率（Rate）、錯誤（Errors）、持續時間（Duration，包含P50/P95/P99）。這是發現迴歸問題的最低要求。
- 每個資源都要有USE指標。 利用率（Utilization）、飽和度（Saturation）、錯誤（Errors）——針對CPU、記憶體、池、佇列、磁碟、網路。
- 追蹤每個跨服務呼叫。 使用OpenTelemetry。資料庫查詢與快取命中也應記錄為跨度（spans）。
- 根據SLO發出警報，而非原始指標。 「CPU > 80%」只會讓人類在凌晨三點無謂地被叫醒。「P99延遲違反SLO持續5分鐘」才能捕捉到真實的使用者痛點。
- 健康檢查與就緒檢查是不同的端點。
/health= 「我還活著，不要重啟我。」/ready= 「我現在可以接受流量。」請確實區分。 - 在正確的層級記錄，每個事件只記錄一次。
INFO用於請求生命週期，WARN用於可復原問題，ERROR用於需要人類介入的情況。重複的日誌會讓儀表板失真。 - 絕不記錄PII或機密。 在日誌附加器（appender）層級遮罩處理，不要依賴呼叫端記得做。
- 每個警報都對應一份操作手冊。 沒有紀錄行動方案的警報，只是偽裝成呼叫的Slack通知。
警示訊號
- 透過SSH登入Pod來除錯生產環境。
- 定期觸發卻被忽略的警報。（警報疲勞是可靠性問題。）
- 寫著
"error occurred"但沒有上下文、沒有ID、沒有堆疊追蹤的日誌。 - 只顯示平均值、沒有百分位數的指標。
- 每個服務一個儀表板，但沒有任何工具是針對使用者旅程的。