歡迎
歡迎
Web 規模的機群包含大量機器。在任何時刻，有些機器健康，有些正在啟動，有些正在排空流量，有些則已靜默故障。機群之所以能維持運作，是因為每台機器都能隨時回答兩個簡單的問題：
- /health — 我目前能否處理真實請求？
- /version — 我正在執行哪個版本的程式碼？
外加一個指標端點（通常為 /metrics），用於公開計數器（counters）與計量表（gauges），供監控工具抓取。
本課程將教導如何設計這些端點，使其真正反映實際狀態、在代理層（proxy tier）中四大黃金信號（four golden signals）的意義，以及觀察到的數據如何驅動容量決策。
完成本課程後，您將能夠：
- 設計一個 /health 端點，以偵測真實的路徑故障，而非僅檢查程序存活狀態
- 設計一個 /version 端點，以驗證部署是否已生效
- 在代理層應用四大黃金信號（延遲、流量、錯誤、飽和度）
- 將觀察到的突增指標與容量決策相結合：何時擴充、何時排空、何時呼叫值班人員（page）
- 理解 SLO（服務等級目標）與錯誤預算消耗率（error budget burn rate），作為「我們該多在意？」背後的營運紀律
兩種健康檢查
存活性（Liveness）與就緒性（Readiness）
存活性（Liveness）：程序是否還活著？由編排器（如 Kubernetes、systemd）使用，以決定是否重新啟動該程序。
就緒性（Readiness）：程序現在是否已準備好處理真實流量？由負載平衡器使用，以決定是否發送請求。
這是兩個不同的問題。一個活著但無法連接到資料庫的程序，是「存活」但「未就緒」的。一個正在啟動中的程序，也是「存活」但尚未「就緒」的。
淺層與深層健康檢查
淺層：如果 HTTP 處理器能執行，就回傳 {"status": "ok"}。這很簡單，只能偵測到程序已停止的情況。
深層：實際執行真實的請求路徑。檢查資料庫連線池是否能返回連線、快取是否可達、下游依賴是否回應。這能偵測到淺層檢查會遺漏的功能性故障。
權衡：深度檢查成本較高（每一次本質上都是一個合成請求），且可能引發連鎖故障（如果每個副本的健康檢查都對資料庫進行高頻請求，當資料庫變慢時，所有副本都會被判定為不健康，從而被移出輪換池，導致所有容量喪失）。
最佳實務：使用淺層檢查來確認存活狀態（快速、低成本、無外部依賴），並使用較深的檢查來確認就緒狀態（使用快取結果，並進行節流以避免對下游服務造成過載）。
版本端點
/version 會回傳 Git 提交哈希值、建置時間及服務名稱。部署完成後，您可以執行 curl https://service.example.com/version 並確認回傳的提交哈希值與您推送的內容一致。如果不一致，則代表部署已靜默失敗。
若沒有 /version 端點，過期的部署可能看起來像是成功的，並隱藏數小時之久。
最小回應結構：{"service": "my-api", "git_commit": "abc1234", "build_time": "2026-05-19T10:00:00Z"}。
延遲、流量、錯誤、飽和度
四個數字涵蓋大部分運維工作
出自 Google SRE 一書。這四個訊號是你必須在每個服務層級上量測的。如果你能妥善監控這四個訊號，就能在用戶發現之前捕捉到大多數生產環境問題。
延遲（Latency）：請求需要多少時間？應報告分佈情況，而非僅看平均值。p99（第 99 百分位延遲）比平均值更重要，因為尾部延遲（tail latency）才是使用者感受到的「慢」。一個平均延遲為 50 ms 但 p99 高達 5,000 ms 的服務存在真實問題，大多數使用者可能察覺不到，但受影響最嚴重的 1% 使用者絕對會感受到。
流量（Traffic）：每秒有多少請求？包括總請求數、依端點（endpoint）、依狀態碼（status code）、依區域（region）的統計。建立基準值（baseline）；對異常情況發出警報（突然下降 = 入口流量問題；突然激增 = 流量高峰或攻擊）。
錯誤（Errors）：失敗請求的比率。區分 4xx（客戶端錯誤，非你的責任）與 5xx（伺服器端錯誤，是你的責任）。將錯誤率追蹤為流量的百分比，而非絕對數量，以便警報在不同負載水平下都能有效運作。
飽和度（Saturation）：系統有多滿？CPU 使用率、記憶體、連線池深度、佇列長度。這是領先指標。飽和度上升通常早於延遲或錯誤惡化。一個飽和度達 90% 的層級，距離佇列崩潰可能只有一分鐘的糟糕表現。
特別針對代理層（Proxy Tier）
每個訊號在邊緣層（edge layer）都會亮起：
- 代理端的延遲：TLS 握手時間、上游連線時間、請求-回應總時間。分別測量，因為它們位於路徑的不同部分。
- 代理端的流量：每秒總請求數、依後端（backend）的分佈（某個後端過熱表示負載平衡偏斜）、依狀態碼的分佈。
- 代理層錯誤：來自客戶端的 4xx（您的使用者存取了錯誤的端點）、來自後端的 5xx（您的服務發生故障），以及代理內部錯誤（502 = 無法連線至後端，504 = 後端逾時）。
- 代理層飽和度：TLS 工作階段數量、上游連線池深度、代理本身的 CPU 使用率（TLS 終止是 CPU 密集型操作）。
專業提示：如果 502 錯誤突然增加，但後端延遲卻很低，這表示後端在回應前就切斷了連線（連線重置、崩潰、記憶體不足 OOM）。如果 504 錯誤增加，則表示後端反應緩慢但仍在回應。請閱讀錯誤代碼；它能告訴您故障發生在哪個環節。
解讀訊號
您的儀表板顯示過去 10 分鐘內的以下情況：
- 流量：大致持平在 800 req/s（無激增）
- 延遲：p50 穩定在 40ms，p99 在 5 分鐘內從 200ms 攀升至 2,500ms，且仍在上升
- 錯誤：4xx 比率穩定在 0.3%（正常背景值）；5xx 比率從 0.1% 上升至 1.2%（主要是 504 Gateway Timeout）
- 飽和度：後端 CPU 在同一 5 分鐘內從 45% 上升至 78%；代理 CPU 穩定在 30%
何時擴展、何時排空、何時呼叫人工介入
容量決策需要觸發條件
觀察指標很容易，但知道何時對其採取行動才是一種紀律。
在以下情況進行擴展：飽和度持續超過閾值（例如，後端 CPU 使用率 >70% 持續 5 分鐘），或佇列深度超過目標值，或延遲 p99 超過 SLO。觸發條件應在系統故障前觸發，而非在故障發生時。
在以下情況排空副本：當某個副本持續緩慢或出現錯誤，而其他副本運行正常時（單一副本過熱通常是主機層級的問題，而非應用程式問題），或在推出新版本時，或在優雅地退役副本時。
在以下情況呼叫人工介入：當 SLO 的消耗速度快於錯誤預算所能承受時，或當飽和度觸發條件被觸發但自動擴展無法吸收時，或當出現級聯模式時（錯誤率與重試率同時上升）。
在以下情況不要呼叫人工介入：當單個異常分鐘自行恢復時，或當背景批次作業造成預期中的週期性波動時，或當雜訊超過閾值時（此時是閾值設定錯誤，而非系統問題）。
SLO 與錯誤預算消耗
SLO（服務等級目標）定義了可接受的效能：「在 28 天窗口內，成功率 >= 99.9%」。其互補部分（0.1%）即為錯誤預算。
消耗速率（Burn rate）：指您消耗錯誤預算的速度。如果您在 1 小時內消耗了 10% 的預算，則速率是永續水平的 240 倍（1 小時是 28 天窗口的 1/672；在該窗口內消耗 10% = 10% × 672 = 預測整個窗口將消耗 6720%，而允許的上限僅為 100%）。
多窗口消耗速率警報：當短窗口（5 分鐘，速率為 14.4 倍）與長窗口（1 小時，速率為 6 倍）同時以超過永續水平的速度消耗預算時，觸發分頁警報（page）。這能同時捕捉快速故障與緩慢退化。
這對容量的重要性：一個運行在 99.9% SLO 且留有 1% 緩衝空間的服務，可以吸收輕微的波動。而一個處於 99.93%（剛好達到 SLO）的服務，只需一個糟糕的日子就會違反 SLO。容量決策應以舒適的 SLO 邊際為目標，而非剛好達標的最小值。
觀察下的容量決策
您的服務 SLO 為 28 天內 99.9% 的成功請求。過去一小時的監控狀態如下：
- 成功率：99.5%（已持續 30 分鐘）
- 後端 CPU：整個集群平均使用率為 82%（目標值 70%）
- p99 延遲：800 毫秒（SLO 目標：<500 毫秒）
- 流量：1,400 req/s，從基準值 1,000 req/s 上升（高於正常水平 40%；趨勢仍在上升）
- 自動縮放：已設定在 CPU 持續超過 80% 達 5 分鐘時增加副本；目前正處於擴容過程中，將在約 90 秒內增加 3 個副本
設計發布可觀測性計畫
綜合
現在您可以設計一個能捕捉真實故障的 /health、一個可讓您驗證部署的 /version、在代理層（proxy tier）的四項黃金訊號儀表板，以及與 SLO 燃燒率（burn rate）掛鉤的容量觸發器。
應用這四項。
您的團隊即將發布 search.example.com（來自故障模式課程中的搜尋服務）。團隊希望推出可觀測性，以在用戶發現問題之前捕捉問題，並具備明確的「是否分頁」決策矩陣。SLO：99.9% 的成功請求，p99 延遲 < 300 ms，時間窗口為 28 天。
課程結束
課程結束
您已完成全部五個課程：
- 代理與來源（Proxies & Origins）：幾乎所有公開網路服務所使用的邊緣層結構
- 無狀態水平擴展（Stateless Horizontal Scaling）：為何無狀態層可以低成本倍增，以及如何進行規模規劃
- 入站與出站分離（Ingress & Egress Separation）：為何一台機器會變成兩台，以及迫使這種分離的故障模式
- 故障模式與爆炸半徑（Failure Modes & Blast Radius）：單點故障（SPOFs）、連鎖反應、事後分析（postmortems）、無責任歸咎的行動項目
- 可觀測性與容量（Observability & Capacity）（本節）：測量什麼指標，才能在用戶發現問題之前讓問題浮現
貫穿全課的主線：網頁級分散式系統並非魔法。它是由一組小型模式（反向代理、無狀態副本、入站/出站分離、隔離艙與電路斷路器、四大黃金信號）經過深思熟慮的組合而成。一旦你認出這些模式，就能在每個生產環境架構中看見它們。
配套課程：五堂「幾何學-*」課程將相同內容重新詮釋為圖論與幾何學。無論以何種順序學習都很適合。
做得很好。