🎯 什麼情境該想到我
當你「出了狀況卻只能靠猜、因為根本沒有資料能看出服務到底哪一層壞了」的時候。
⚙️ 怎麼用（步驟 / 公式）
意圖：在整個應用堆疊的每一層都鋪好遙測，讓問題能用資料與事實判斷，而不是靠謠言、指責與推諉。
五層遙測（書中列出的 metrics levels，缺一層就是一個盲區）：
- Business level：sales transactions 筆數、sales transactions 的 revenue、user signups、churn rate、A/B testing results。
- Application level：transaction times、user response times、application faults。
- Infrastructure level（database、operating system、networking、storage）：web server traffic、CPU load、disk usage。
- Client software level（瀏覽器上的 JavaScript、行動 App）：application errors and crashes、user measured transaction times（使用者實際感受到的交易時間）。
- Deployment pipeline level：build pipeline status（各自動化測試套件的紅或綠）、change deployment lead times、deployment frequencies、test environment promotions、environment status。
補齊缺口的判準（這是本條的操作核心）：
- 每一次生產事故之後，都要回頭找出「缺了哪個遙測，有了它就能更快偵測與復原」。
- 更好的做法：在功能開發的同儕審查（peer review）階段就先把這些缺口找出來，而不是等事故發生。
- 監控 application 與 infrastructure 的 faults（異常終止、application errors and exceptions、server 與 storage errors）同時也是資安事件偵測——這些錯誤常常是漏洞正在被利用的指標。
把部署事件疊到指標圖上（同一套遙測的必要配套）：
- 產生遙測圖表時，把生產環境的變更以垂直線疊在圖上（書中的圖 27 就是登入成功／失敗數的圖上疊部署垂直線），因為絕大多數生產問題來自生產變更，其中包含程式部署。
- 也把維護中、備份中這類營運活動疊上去，用來決定該顯示還是抑制告警。
- 變更本身仍帶風險：副作用不只是 outage，也包括顯著的干擾與偏離常態運作（例如大量交易的服務在部署後 cache 全數 miss 造成的 settling period），疊圖是為了看清「效能多久回到正常」。
規模參照（Etsy）：
- 2011 年已在應用堆疊各層追蹤超過二十萬個生產 metrics，並把最重要的前三十個業務指標放在 deploy dashboard 顯眼處。
- 2014 年追蹤超過八十萬個 metrics。
原文：「Business level: Examples include the number of sales transactions, revenue」（L7934）
原文：「enabled faster detection and recovery; or, better yet, we can identify these gaps」（L7965，接 L7966「during feature development in our peer review process.」）
原文：「production issues are caused by production changes, which include code」（L7788）
原文：「Etsy was tracking over two hundred thousand production metrics at every layer」（L7490）
🧪 我實際套用的紀錄
- （待填）
⚠️ 注意 / 什麼時候不適用
- 五層不是「挑兩層做做」——書中的重點是所有環境（含 pre-production）與支撐它們的 deployment pipeline 都要有遙測，只補一層仍會留下盲區。
- 業務指標要可行動（actionable）；不可行動的多半是 vanity metrics，書中建議存起來但不要拿來驅動決策。
- 光有大量指標不等於有告警品質——要怎麼從這些資料變成不會擾民的告警，見 均值與標準差告警 與 非高斯資料的異常偵測。
🔗 相關工具
- 工具-遙測與監控（本條是它在「該蓋哪幾層」上的具體展開）
- 日誌分級（Application level 遙測的實作面：什麼該寫成哪一級）
- 從事故回推告警（「事故後找缺哪個遙測」的完整操作流程）
- 均值與標準差告警（有了遙測之後怎麼設門檻）
- 工具-部署管線與持續交付（Deployment pipeline level 的指標就出自它）
- 工具-無指責事後檢討（事故後補遙測缺口的最佳時機）
- DevOps手冊