最近讀了〈Only 100 Metrics Matter〉，有些感想。核心觀點不是「不要蒐集資料」，而是「別讓蒐集到的資料分散了我們的注意力」。
痛點與決策
文章開頭即是**痛點**的描述︰
決策︰
認知負荷：看板與告警越多，決策品質反而下降，MTTD/MTTR變慢。
組織對齊：少數關鍵指標更容易形成共識，推動跨部門協同。
噪音抑制：長尾數據波動大、樣本小，容易誤導；core set（能夠解釋 80～90% 業務或產品變化的那一小組指標、事件與屬性。） 有更高信噪比。
彈性保留：全量追蹤不浪費，因為儲存便宜（是真的也不貴，但流量倒是相對貴多了QQ）；但把注意力花在長尾很昂貴。
「不是在收集更多，而是在收斂注意力到真正能影響行動與決策的少數關鍵訊號。」
The System Beneath the Surface
「Every business can be represented as a system. And these systems can be written as a set of equations.」
文章要我們把業務想成「可被數學關係描述的系統」──
也就是說，你的營收、使用者行為、成效轉換，背後都有可觀測的變數與可操作的槓桿（levers）。
以 Facebook 為例，他把「Revenue」分解為 4 個槓桿：
Users × Impressions per User × Ad Impressions per Impression × Revenue per Ad
這種表達方式的重點是：
一旦你看見了系統的方程式，就知道「哪個變數可被操作、哪個是結果」。
對系統來說 「每一個技術系統也可以被寫成一組方程式。」
例如，在人力銀行／廣告投放平台中：
System Health = Service Availability × Latency Performance × Error Rate Stability × Queue Throughput
如果把「業務」換成「系統」，
那每個乘項（或加項）其實就是一組可觀測的核心 metric（SLI）。
→ 換句話說： observability = 將你的系統行為具象成可操作的方程式。
知道這個結構，就能知道「哪些指標才是槓桿、哪些只是噪音」。
The Power of Decomposition
「When you break the system into equations, you can see what drives what.」
文章用 MAU 舉例：
MAU = New Users + Retained Users + Resurrected Users
再往下分解「New Users」成各個轉換步驟。
這叫做 系統分解（decomposition）——從最上層 KPI 一層一層拆解出真正影響它的變數。
在技術系統裡，「decomposition」就是 tracing 與 dependency mapping。
你會從：
「整體平台健康度」
↓
「哪個服務異常」
↓
「哪個 API latency 提升」
↓
「是哪個下游依賴卡住」
這種由上而下的 drill-down 分析，就是 observability 工程的核心價值。
對 Product Engineer 而言，這也是產品儀表板該有的結構：
從「整體求職轉換率下降」→ 分解成「下載轉換低」「投遞流程慢」→ 再分解成「API 錯誤上升」。
👉 所以：
System Equation = 你能觀測的模型架構
Decomposition = 你能追蹤與定位問題的能力
Why Only 100 Metrics Matter
「Each additional layer gives you smaller returns… you don’t need thousands of metrics to understand your business.」
深入分析太多層之後，邊際效益會快速下降：樣本小、噪音大、難以行動。
因此需要聚焦在一個「小而穩的 Core sets」。
對系統監控／可觀測性的對應
這段就是我們前面聊到的「Core set」「告警疲勞」「高信噪比」：
技術團隊中的角色
如果你是這兩種角色，能嘗試將技術與業務掛勾：
| 角色 | 如何應用三個概念 |
| Product Engineer | 將產品成長或轉換率看作一個系統方程式（System Beneath the Surface），再分解出可操作的漏斗階段（Power of Decomposition），最後聚焦在能驅動決策的少數核心指標。 |
| Observability Engineer | 將系統可用性寫成核心 SLO 方程式（System），建立跨服務的依賴追蹤（Decomposition），再只監控與告警那一組「能真實反映健康度的 100 metrics 」（Core sets）。 |
Product Engineer
「產品成長也像一個系統，有結構、有槓桿、有信號。
我們要做的，不是蒐集更多數據，而是抓到能推動變化的那幾個變數。」
流程要能被拆解與量化
把「求職旅程」或「廣告投放」想成一條可量化的方程式：
Job Success = Visitors × Signups × Resume Completed × Applications × Interviews × Offers × Hires
指標要能反映決策，不只是呈現現狀
比方說：
這些要能一層層拆出來看，形成「行動鏈」。
定義 Core Set
把數據變成故事，而不是表格
「為什麼這週投遞率掉了？」
看看「下載→註冊」階段是否轉換低？
或「註冊→履歷完成」這段卡住？
每個數字背後，都應該能講出行為邏輯。
Observability Engineer
「可觀測性不是看越多越好，而是能清楚地看出問題在哪裡、為什麼、要不要修。」
用系統方程式思考健康度
用分解（Decomposition）做問題定位
建立核心監控集（Core Set of Metrics）
告警要能反映真實影響
告警的目的不是通知，而是讓你更快做決策。
減少噪音，也就是提高信噪比。
讓變更可追蹤
每次版本或設定變更都該留下「Change Event」(GitOps)，標註在監控走勢圖上。
讓你在看 SLO 波動時，一眼就知道是不是跟部署有關。
可觀測性最重要的價值之一，就是讓「系統可被審計」。
一句話總結
可觀測性的目標不是更多資料，而是更快理解因果關係。
我們不需要 10,000 個 metric，只需要那 100 個能讓我們信任的。
