歡迎
歡迎
一個網絡級的機群包含許多機器。在任何時刻，某些機器健康，有些機器正在啟動，有些機器正在排放，有些機器安靜地壞掉。機群在這個過程中生存，因為每台機器在要求時會回答兩個簡單的問題：
- /health — 我目前是否能夠服務實際請求？
- /version — 我正在運行的代碼是什麼？
此外，還有一個指標端點（通常為 /metrics），該端點揭示了用於監控工具挖掘的計數器和閾值。
這堂課教你如何設計這些端點，以便它們實際上反映現實，如何在代理層面應用四個黃金信號，以及如何將觀察到的數據與容量決策相聯繫。
在結束時，你將：
- 設計一個 /health 端點，該端點檢測實際路徑失敗，而不僅僅是過程的存活狀態
- 設計一個 /version 端點，讓你能夠驗證部署已經生效
- 在代理層面應用四個黃金信號（延遲、流量、錯誤、饒舌）
- 將觀察到的擴增指標與容量決策相聯繫：何時擴展、何時排放、何時發送警報
- 理解 SLO 和錯誤預算消耗速度作為『我們關心多少』的運營紀律
兩種健康檢查的種類
存活與準備就緒
存活：過程是否至少存活？由調度器（Kubernetes、systemd）決定是否重新啟動過程。
準備就緒：過程現在是否已經準備好處理實際流量？由負載平衡器決定是否將請求發送。
這些是不同的問題。一個過程即使是存活但無法達到其數據庫，也是存活但不具備現時準備就緒。一個正在啟動的過程是存活但尚未準備就緒。
浅表與深表健康檢查
浅表：返回 {"status": "ok"} 如果 HTTP 處理程序運行。簡單。只檢測過程下降。
深度: 實際執行真實請求路徑。檢查數據庫連接池是否可以返回連接，緩存是否可達到，下游依賴項是否響應。偵測功能中斷，淺度檢查會遺失。
交易-off: 深度檢查的成本更高（每一個都是synthetic請求）& 可能導致連鎖失效（如果每個副本的健康檢查撞擊數據庫，一個慢的數據庫使所有副本不健康，將從輪詢中移除，從而移除所有容量）。
最佳實踐：淺度檢查存活（快速，廉價，不依賴外部）& 深度檢查就緒（使用緩存結果，避免撞擊下游）。
版本端點
/version 返回 Git提交，建構時間和服務名稱。部署後，您可以使用 curl https://service.example.com/version 確認返回的提交與您推送的匹配。如果不匹配，部署失敗靜音。
沒有 /version，過時部署可以看起來成功並隱藏數小時。
最小響應形狀：{"service":"my-api","git_commit":"abc1234","build_time":"2026-05-19T10:00:00Z"}。
延遲，流量，錯誤，飽和
四個數字覆蓋大多數操作
從Google SRE書中。四個信號在每個服務層次進行測量。如果對這四個信號進行良好的配置，您可以在生產環境中捕獲大多數問題，避免用戶自己做出。
延遲：請求花費的時間。報告分布，不僅僅是平均值。p99（99分位延遲）比平均值更重要，因為尾部延遲是用戶感受到的‘慢’。一個服務的平均值為50毫秒，p99為5000毫秒，有一個真正的問題，1%最受影響的用戶絕對感受到。
流量：每秒請求數。總請求，按每個端點，按每個狀態碼，按地區。基線已知；對異常進行報警（突降表示進入問題；突增表示突襲或攻擊）。
錯誤：失敗請求的速率。區分4xx（客戶錯誤，不是您的錯）和5xx（服務錯誤，您的錯）。以流量百分比的形式跟踪錯誤率，而不是以絕對數量進行跟踪，以便報警在不同負載水平下有效。
飽和度: 系統有多滿? CPU 利用率、記憶體、連接池深度、排隊長度。領導指標。飽和度在 latency 或錯誤惡化之前會上升。飽和度為 90% 的層級，意味著只差一分鐘就會導致排隊崩潰。
特別在代理層級
每個信號在邊緣層顯示:
- 代理層的延遲: TLS 握手時間、上游連接時間、請求-響應總時間。分別測量，因為它們生活在不同部分的路徑上。
- 代理層的流量: 總請求/秒、每個後端分佈（熱後端表示負載均衡器偏斜）、每個狀態碼分解。
- 代理層的錯誤: 從客戶端 (您的用戶訪問錯誤的端點) 的 4xx、從後端 (您的服務失敗) 的 5xx、代理內部錯誤 (502 = 後端無法接觸, 504 = 後端超時)。
- 代理層的飽和度: TLS 會話數、上游連接池深度、代理本身的 CPU (TLS 終止是 CPU 密集型)。
專業建議: 突然增加 502 的同時，後端 latency 低意味著後端在回應之前就掛住了 (連接重置、崩潰、OOM)。增加 504 意味著後端慢但仍回答。讀取錯誤碼，它告訴你失敗發生在哪里。
![/static/diagrams/distsys_four_golden_signals.svg]
閱讀信號
您的儀表板在過去的 10 分鐘內顯示如下:
- 流量: 約為 800 req/s (沒有暴增)
- 延遲: p50穩定在 40ms,p99 從 200ms 上升到 2,500ms 過了 5 分鐘仍在上升
- 錯誤: 4xx 率穩定在 0.3% (正常背景); 5xx 率從 0.1% 上升到 1.2% (主要是 504 Gateway Timeout)
- 飽和度: 後端 CPU 從 45% 上升到 78% 在同一個 5 分鐘內; 代理 CPU 穩定在 30%
擴展、排放、提醒的時機
能力決策需要觸發器
觀察指標很簡單。知道何時應該採取行動則是自律的藝術。
擴展時機：當飽和度持續超過閾值時（例如，後端CPU超過70%持續5分鐘），或是排隊深度超過目標，或者是延遲p99超過SLO。觸發器應在事情發生之前觸發，而不是在事情發生時觸發。
排空副本時機：當它一致地慢或錯誤，而同伴則健康（一個副本運行得很熱往往是主機層級問題，而不是應用程式問題），或者在推出新版本時，或者在優雅地退休副本時。
叫醒人力時機：當SLO比錯誤預算更快地被燃燒時，或者飽和度觸發器在自動擴展未能吸收它時發生，或者出現漸層模式（錯誤率+重試率都在攀升）。
不要叫醒人力時機：當單個壞分鐘自己恢復時，或者背景批次作業導致期望的周期性突發時，或者噪音跨越閾值時（閾值是錯誤的，而不是系統本身）。
SLOs & Error Budget Burn
SLO（服務水平目標）定義了可接受的性能：‘成功率>=99.9%在28天的滑動窗口中’。其補充（0.1%）是錯誤預算。
燃燒速率：您正在什麼速度消耗錯誤預算。如果您在1小時內燃燒了10%的預算，那麼速率是不可持續的240倍（1小時是28天滑動窗口的1/672；在該窗口內燃燒10% = 10% × 672 = 6720%，預計為全窗口的100%時，只允許100%）。
多窗口燃燒速率警報：在短窗口（5分鐘，14.4倍速率）和長窗口（1小時，6倍速率）都燃燒得比可持續速度快時叫醒人力。這可以捕捉到快速中斷和慢慢惡化。
為什麼對於容量來說這有關係：一個運行在99.9% SLO的服務，具有1%的閒置空間，可以吸收小的突發。一個在99.93%（僅剛剛滿足SLO）運行的服務，只要有一天的差距就會違約。容量決策應該目標是舒適的SLO安全邊際，而不是最小的滿足它。
在觀察下進行容量決策
您的服務的SLO為28天內成功請求的99.9%。在過去1小時的監控中，當前狀態為：
- 成功率：99.5%（持續30分鐘）
- 後端CPU：整個艦隊的平均值為82%（目標值70%）
- p99延遲：800毫秒（SLO目標：<500毫秒）
- 流量：每秒1,400個請求，從基線1,000個請求/秒（高出正常水平40%；趨勢仍在上升）
- 自动扩展：配置在 CPU 大于 80% 持续 5 分钟时添加实例；当前正在进行缩放操作，将在 ~90 秒内添加 3 个实例
设计发布观察性计划
合成
你现在可以设计一个 /health 来捕获真实的故障，一個 /version 来验证部署，四个金色信号仪表板在代理层，以及与 SLO 燃烧率相关的容量触发器。
应用所有四个。
你的团队正在发布 search.example.com（来自故障模式课程的搜索服务）。该团队希望部署一个能够在用户之前捕获问题的观察性系统，具有明确的页面还是不页面决策矩阵。SLO：99.9% 成功请求，p99 延迟 < 300 ms，覆盖 28 天的时间窗口。
课程总结
结束课程
你已经完成了五个课程：
- 代理与源：几乎每个公共网络服务使用的边缘层形状
- 无状态水平扩展：为什么无状态层可以便宜并且如何 sizing 它
- 入口与出口分离：为什么一个盒子变成两个，以及强制其执行的故障模式
- 故障模式与爆炸半径：SPOFs，链式故障，后续分析，无责行动项目
- 观察性与容量（这个）：要测量的问题才能在用户之前浮现
主題線: 一個網絡級別的分布式系統不是魔法。它是一個小組的模式（反向代理，無狀態的副本，入口/出口分離，四個黃金信號，分隔帶和電路斷開器），由思考組合。 一旦您認識到模式，您將看到它們在每個生產架構中。
配對課程：五個形狀-* 的課程將相同的材料重新表述為圖論和幾何學。 它們可以在任何順序中進行。
很好。