客服建立一張訂單，平常不到一秒就能完成，最近卻經常等上三秒。資料有存進去，金額也正確，畫面最後都顯示成功，但每接一通電話，都要多等一下。

這時已經有值得處理的效能問題。等到請求逾時、程式拋出錯誤才注意到，前面那段逐漸變慢的過程，使用者早就感受到了。

不過，如果沒有人回報，我們怎麼知道建立訂單從不到一秒變成了三秒？

先決定哪個流程值得量

以這個案例來說，客服需要邊接電話邊完成訂單，建立速度會直接影響操作節奏，客戶也在電話另一端等待。這類流程不能只在開發階段量過一次，上線後也要持續觀察。

同樣值得觀察的，還有幾種流程：

• 商品搜尋與結帳：直接影響顧客能否順利完成購買。
• 倉庫掃描條碼到取得揀貨資訊：決定現場作業的節奏。
• 每日清晨的對帳批次：需要在財務人員上班前完成。

簡單來說，有人在等、每天頻繁執行，或有明確完成時限的流程，都值得優先納入觀察。

要量什麼，也是實作時就得決定的事：從哪裡開始計時、到哪裡結束，每筆紀錄又帶上哪些分類。若建立訂單只在API層記錄整體耗時，沒有區分客服的單筆訂單與上百筆明細的批次訂單，批次的長耗時就會混進客服的數據裡，兩邊都看不準。

不只看變化，也要看發生比例與分位數

假設過去5分鐘內完成了100次訂單建立，其中20次耗時超過3秒，代表這段時間已有兩成操作明顯變慢。偶發一次的延遲，與連續好幾個時段都有兩成請求變慢，代表的意義與處理的優先順序並不相同。

只看平均值，也容易把問題藏起來。大多數請求都很快、只有少數使用者等很久時，平均數看起來仍然正常。因此可以把執行量、超過門檻的比例與耗時分位數放在一起看；分位數如P95，代表95%的請求都在這個時間內完成。再和流量相近的歷史時段比較，才看得出是不是真的變慢了。

3秒是這個案例假設的觀察門檻，不是所有功能的通用標準。門檻要依業務需求與歷史紀錄訂定，持續累積資料，才知道什麼是平常的表現。

業務流程之外，也看底層資源

流程指標之外，HTTP回應速度與請求量，以及服務和主機狀態，也需要持續觀察。常見項目包括資料庫查詢耗時、連線與等待狀況，硬碟剩餘空間與讀寫延遲，以及CPU、記憶體使用情形。業務流程變慢時，這些數據能幫助我們比對底層資源是否同時出現異常，但不能只因為兩張圖一起升高，就斷定兩者有直接的因果關係。

沒有人回報，也要看得出建立訂單從一秒變成了三秒。量哪些流程、怎麼分類、用什麼門檻判斷變慢，都要在實作時就決定，而不是等錯誤出現才開始找。

「我們有異常通知嗎？」
「有，出事的時候會有人打電話來。」