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

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

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

先決定哪個流程值得量

以這個案例來說，客服需要邊接電話邊完成訂單，建立速度會直接影響操作節奏，讓客戶在電話另一端等待也會傷害體驗。這類關鍵流程絕不能只在開發階段測過一次就算數，而是需要長期持續的監測。

同理：

• 商品搜尋與結帳速度：直接影響顧客能否順暢完成購買與轉換。
• 倉庫掃描條碼到獲取揀貨資訊的時間：決定了現場作業的流暢度與效率。
• 每日清晨的對帳批次：必須確保在財務人員上班前順利完成。

簡單來說：有人在等、每天高頻執行，或是具有明確完成時限的流程，都值得優先納入監測範圍。

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

假設過去 5 分鐘內完成了 100 次訂單建立，其中有 20 次耗時超過 3 秒，這代表該時段已有兩成的操作出現明顯延遲。偶發一次的單點延遲，與連續數個時段持續有兩成請求變慢，兩者代表的意義與調校優先級截然不同。

此外，只看「平均值」非常容易掩蓋真相。當絕大多數請求都很快，只有少數使用者遭遇嚴重卡頓時，平均數看起來依然非常健康。因此，我們應該結合執行量、耗時分位數（如 P95, P99）與超過門檻的比例進行綜合觀察，並與相近流量、相同業務規模的歷史時段做對比。

3 秒是此案例假設的觀察門檻，並非所有功能的通用標準。指標必須來自真實業務需求與歷史紀錄。例如：處理上百筆明細的批次訂單，就不該直接與客服建立的單筆小訂單混為一談。唯有持續累積與沉澱資料，才能精準定義什麼是「常態表現」。

關注業務流程之餘，底層資源同樣不可忽視

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

要讓一個系統能夠健康、穩定且長久地營運，就必須在實作階段，將「關鍵流程的觀察」與「數據收集的可觀測性」視為系統的一部分。

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