可觀測性與服務等級目標 (Observability and SLOs) 是做什麼的？
概述
你無法操作、除錯或改善你看不見的東西。可觀測性必須是設計的一部分，而不是在第一次故障發生後才硬塞進去。每個事件的首要問題是「什麼變了，誰受到了影響」——一個無法回答這個問題的系統會把五分鐘就能解決的問題變成一場考古挖掘。
原則（通用）
- 三大信號。 發射結構化日誌（機器可解析，非純文字）、指標（計數、比率、持續時間）和追蹤（請求在服務間的路徑）。一個請求會從頭到尾攜帶一個關聯/追蹤 ID。
- 為每個表面檢測黃金信號：每個端點/操作上的速率、錯誤、持續時間 (RED)，加上資源飽和度。新端點在變得可觀測之前不算「完成」。
- 健康狀況是一個端點，而非猜測。 將存活度（「我還在運行嗎？」）和就緒度（「我能處理流量嗎？」）作為獨立的檢查公開。
- 為關鍵旅程定義 SLO，搭配衡量它們的 SLI，以及一個讓可靠性與功能之間的取捨變得明確且資料驅動的錯誤預算。
- 根據症狀而非原因發出警報。 當使用者受到影響時（SLO 燃燒、就緒度失敗）才發訊息，而不是在每個內部小問題出現時。每個警報都必須是可執行的——一個無人理會的警報會訓練人們忽略所有警報。
機制（此技術棧）
- 輸出結構化 JSON 日誌到 stdout，由平台收集（例如 AKS → Azure Monitor / Log Analytics）。服務內部不得使用純文字記錄。
- 在應用伺服器和 PostGraphile 中使用 OpenTelemetry；將追蹤/指標導出到 Azure Monitor / Application Insights（或 Prometheus / Grafana）。
- 在資料路徑中傳播關聯 ID——在邊緣生成，通過瀏覽器 → 應用 → PostGraphile，與上下文標頭一起傳遞，並附加到每一條日誌行和跨度中。
- 每個 HTTP 路由和 GraphQL 操作的 RED 指標；PostgreSQL 慢查詢日誌 +
pg_stat_statements。 - 存活度/就緒度端點連接到 Kubernetes 探針（請參閱
cloud-delivery-aks）。就緒度應反映真實的依賴健康狀況（它能否連接到資料庫？），而不僅僅是程序是否運行。 - 前端： 將 Web Vitals 和用戶端錯誤報告給同一個後端。
- 每個旅程的 SLO，搭配儀表板和燃燒速率警報。
何時擴展此方案
一個預啟動/本地專案現在可以實施結構化日誌 + 健康端點，但將 SLO / 警報推遲到有真正使用者需要保護時。在第一個決策記錄中說明模式。
完整理由：參見憲法第 IX 條與第 XVI 條，這些內容位於 engineering-constitution/references/engineering-constitution.md。