缺陷管理的角色#
事件管理偏向運維，缺陷管理偏向開發。但兩者都會落到 SRE 手上：
- SRE 觀察 production，把問題以缺陷形式登錄
- 開發依優先級修補
- 測試驗證後上線
延續上一節的保全 + 雜貨整合案例。事件管理改善後，SRE 終於能聚焦在可靠性，但缺陷數仍然居高不下。
維運階段觀察#
- 同樣的缺陷反覆出現
- 部分事件最終轉化成程式缺陷
- 主動監控偵測到的告警也轉成缺陷
問題#
SRE 100% 時間都在繞過缺陷以保住使用者體驗，沒餘力改善系統本身。
解法：把缺陷流程拆開檢視#
- SRE 分析缺陷型態，發現「事件 → 缺陷」與「告警 → 缺陷」並非孤立事件
- 既有流程：所有 production 缺陷都進入單一佇列，依分類由 SRE 或開發承接
- 功能缺陷由開發處理
- 非功能缺陷（如 WARN 印成 INFO）由 SRE 處理
- 但開發未及時挑單；SRE 重啟服務以繞過根本問題仍未解決
- SME 雙方分析後發現分類有誤：缺陷被標為「一般優先級」，因為「有重啟可繞過」就不被視為高優先級
- 現有流程沒有缺陷會議與所有權設定，重要缺陷常被獨立修改而引入新缺陷
- SRE 與開發領導重新設計流程：
- 影響使用者的 production 缺陷「立刻處理」
- 新增 20% 開發團隊容量專責 production 功能缺陷
- 開發團隊重新命名以利 SRE 指派
- 每週固定 SRE 與 dev SME 會議追蹤缺陷
- 三個月內缺陷頻率明顯下降、可用性與效能上升、SRE 可回頭做其他工作
缺陷分類的小錯，會放大成可靠性的大坑。流程審視必須與業務成長同步。
教訓#
- 缺陷管理是 SRE 的「結構性」工作，不僅是「處理單筆」
- 重複出現的缺陷往往代表流程缺陷，而非單純的程式問題
- 在系統成長時主動審視流程，遠比等出事再改要划算
每季檢視一次「缺陷分類規則」與「處理 SLA」，並記錄變更前後的指標差異，是落實這個習慣的最簡單方法。