# Only 100 Metrics Matter 讀後感

最近讀了[〈Only 100 Metrics Matter〉](https://opinionatedintelligence.substack.com/p/only-100-metrics-matter)，有些感想。核心觀點不是「不要蒐集資料」，而是「別讓蒐集到的資料分散了我們的注意力」。

# 痛點與決策

文章開頭即是\*\*痛點\*\*的描述︰

* 蒐集可以很貪心，但注意力需要節制。
    
* 全量記錄是為了稀有情況與根因排查；日常決策則需要一組極精煉的「核心指標、核心事件、核心屬性」。
    
    * 今年才跟朋友說，我想我應該很難一直留意那些 log 跟數量有啥異常，你不如轉成看是百分比還是一個量化的純數吧。
        
* 100個核心指標、50個核心事件、150個核心屬性，就能解釋90%的業務與產品變化；其餘是長尾，留作特殊分析與事後鑑識。
    
    * 其實這句話在說的是可數的幾件事情相互組合基本就能解釋大部分的狀態變化了。這些數字並非絕對法則，而是作者用來說明「在大多數情境裡，一個典型的產品／業務，這量級的指標就能覆蓋絕大多數情況」。
        
    * 有個 [**Pareto Principle（80/20 法則**、**關鍵少數法則）**](https://ithelp.ithome.com.tw/articles/10348115)，核心概念也類似，小弟我在以前鐵人賽有寫一篇文章可供參考。
        

**決策**︰

* **認知負荷**：看板與告警越多，決策品質反而下降，MTTD/MTTR變慢。
    
* **組織對齊**：少數關鍵指標更容易形成共識，推動跨部門協同。
    
* **噪音抑制**：**長尾數據**波動大、樣本小，容易誤導；**core set**（能夠解釋 80～90% 業務或產品變化的那一小組指標、事件與屬性。） 有更高信噪比。
    
    * 這些少數關鍵指標的變化，更能可靠地代表實際情況，而不是被隨機波動誤導。例如 **DAU** 或 **錯誤率** 的變化通常能真實反映系統層面的問題或市場反應。
        
    * 把「長尾」留給事後調查或特殊情境，不混進日常決策。
        
* **彈性保留**：全量追蹤不浪費，因為儲存便宜（是真的也不貴，但流量倒是相對貴多了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」「告警疲勞」「高信噪比」：

* 監控應該只針對最重要的指標（例如 Golden Signals：流量、延遲、錯誤、飽和度）。
    
* Dashboard 不是越多越好，而是越能直接支持決策越好。
    
* 長尾數據留給事後分析，不該進日常告警或首頁看板。
    

## 技術團隊中的角色

如果你是這兩種角色，能嘗試將技術與業務掛勾：

| **角色** | **如何應用三個概念** |
| --- | --- |
| **Product Engineer** | 將產品成長或轉換率看作一個系統方程式（System Beneath the Surface），再分解出可操作的漏斗階段（Power of Decomposition），最後聚焦在能驅動決策的少數核心指標。 |
| **Observability Engineer** | 將系統可用性寫成核心 SLO 方程式（System），建立跨服務的依賴追蹤（Decomposition），再只監控與告警那一組「能真實反映健康度的 100 metrics 」（Core sets）。 |

### Product Engineer

> 「產品成長也像一個系統，有結構、有槓桿、有信號。  
> 我們要做的，不是蒐集更多數據，而是抓到能推動變化的那幾個變數。」

**流程要能被拆解與量化**

把「求職旅程」或「廣告投放」想成一條可量化的方程式：

```sql
Job Success = Visitors × Signups × Resume Completed × Applications × Interviews × Offers × Hires
```

* 每一段都是一個「可操作的槓桿」，而不是單純的報表項目。
    
* 要清楚知道：這些環節哪一個波動，整體就會出問題。
    

**指標要能反映決策，不只是呈現現狀**

* 比方說：
    
    * 「投遞成功率下降」→ 是轉換率問題，還是流量異常？
        
    * 「平均求職時間變長」→ 是履歷填寫率下降，還是推薦職缺不夠準？
        
* 這些要能一層層拆出來看，形成「行動鏈」。
    

**定義 Core Set**

* 例如：
    
    * 核心指標（Metrics）＝「註冊率」「履歷完成率」「投遞成功率」「面試率」「錄取率」「到職率」
        
    * 核心事件（Events）＝「註冊」「上傳履歷」「投遞成功」「面試完成」
        
    * 核心屬性（Attributes）＝「地區」「產業」「年資」「職缺類別」
        
* 這組核心集就能解釋 80～90% 的產品健康度，其他留給 ad-hoc 分析即可。
    

**把數據變成故事，而不是表格**

* 「為什麼這週投遞率掉了？」
    
    * 看看「下載→註冊」階段是否轉換低？
        
    * 或「註冊→履歷完成」這段卡住？
        
* 每個數字背後，都應該能講出行為邏輯。
    

### **Observability Engineer**

> 「可觀測性不是看越多越好，而是能清楚地看出**問題在哪裡、為什麼、要不要修**。」

**用系統方程式思考健康度**

* 把平台整體狀態定義為一個高層方程式：
    
    ```sql
    System Health = Availability × Latency Stability × Error Rate × Queue Throughput
    ```
    
* 每一項就是你的**核心監控指標**（**Golden Signals**）。  
    你只要看這幾個，就能快速判斷整體健康狀況。
    

**用分解（Decomposition）做問題定位**

* 當系統異常時，你應該能從：
    
    * 現象「整體服務延遲↑」  
        ↓
        
    * 「哪個API latency 提升」  
        ↓
        
    * 「是哪個 downstream service 卡住」
        
* 這個過程就像 MAU 拆成 New/Retained/Resurrected，用層層分解去找 root cause。  
    observability 本身其實就是「系統方程式的實作版」。
    

**建立核心監控集（Core Set of Metrics）**

* 不需要監控幾千個 metric。  
    一般來說，只要這些就能覆蓋 90% 的狀況：
    
    * **四大 Golden Signals**：Traffic（流量）、Latency（延遲）、Errors（錯誤率）、Saturation（資源飽和）
        
        * Four Golden Signals 是一種綜合性的監控方法，它提供跨使用者介面層 (UI Layer)、服務層 (Service Layer) 和基礎設施層 (Infrastructure Layer)的全面監控視角，而非僅限於單一服務或資源。
            
    * **面板能關聯到主要業務事件健康度儀表板**：註冊成功率、投遞成功率、到職轉換率
        
* 其他指標可以紀錄，但不用進主 dashboard。
    

**告警要能反映真實影響**

* 告警的目的不是通知，而是讓你**更快做決策**。
    
    * 只有當**對應 SLO 惡化**時，才該觸發 P1。
        
    * 其他長尾異常（如零星 timeout）留給事後分析。
        
* 減少噪音，也就是提高信噪比。
    

**讓變更可追蹤**

* 每次版本或設定變更都該留下「Change Event」(**GitOps**)，標註在監控走勢圖上。
    
* 讓你在看 SLO 波動時，一眼就知道是不是跟部署有關。
    
* 可觀測性最重要的價值之一，就是讓「系統可被審計」。
    

# 一句話總結

> 可觀測性的目標不是更多資料，而是更快理解**因果關係**。  
> 我們不需要 10,000 個 metric，只需要那 100 個能讓我們信任的。