Bug Triage 完整流程 — 從 New 到 Closed 的 lifecycle 與 SLA 設計

「Jira 上 800 個 bug 沒人處理」是大公司日常。Bug triage 流程設計爛 = ticket 墳場 = 真重要的事被掩埋。這篇給你完整 lifecycle、severity 矩陣、triage meeting playbook。

每個 state 都該有 owner（負責人）跟 SLA（多久該轉到下一個）。

State 1: New（剛建立）

State 2: Triaged（分類完）

Triage 過程確認：

• ✅ Severity（傷害大小）
• ✅ Priority（修復急迫度）
• ✅ Component（哪塊）
• ✅ Assigned to（誰修）
• ✅ Target version（哪版修）

State 3: In Progress（修中）

State 4: Code Review

State 5: Ready for QA（待驗證）

State 6: Verified（驗證通過）

可以 close、或等下次 release。

State 7-9: Reject / Duplicate / Won't Fix

全都要寫原因。直接 close 是文化殺手。

Severity × Priority 矩陣：

Severity（壞得多嚴重）與 Priority（多急著修）是兩個軸。高 Severity 不一定高 Priority — 一個只有舊瀏覽器才出現的 crash 可能晚點修。

Severity（傷害大小 — 由 QA 給）

S1 Critical: 系統當機 / 資料遺失 / 安全漏洞
S2 High: 主要功能無法用 / 阻擋 release
S3 Medium: 次要功能異常 / 有 workaround
S4 Low: UI 小瑕疵 / 文案錯字

Priority（修復急迫度 — 由 PM/Lead 給）

P0 Now: 阻擋發版 / 影響營收 / 法遵
P1 This sprint: 重要、本 sprint 修
P2 Next sprint: 規劃但可等
P3 Backlog: 看情況、可能不修

關鍵：Severity ≠ Priority

範例:
- Severity S1（會掉資料）+ 1% 使用者觸發 + 有 workaround → P1
- Severity S4（首頁 logo 跑版）+ 全站 → P0（brand 重要）
- Severity S2（特定 flow 壞）+ 0.001% 使用者 → P3（不修）

開會節奏

參與者

QA Lead（主持）
Engineering Lead
Product Manager
Senior QA（書記）
（可選）Customer Support、Designer

議程範本

0:00-2:00   開場、上次 action item
2:00-20:00  Triage new ticket（每個 30 秒）
20:00-27:00 爭議 ticket 深入討論
27:00-30:00 Action items + 寫下來

30 秒一個 ticket 的關鍵問題

1. 這個 bug 確實是 bug 嗎? (Yes/Not a bug/Duplicate)
2. Severity 多少?
3. Priority 多少?
4. 誰負責?
5. 目標哪個 release?

爭議的留 5 分鐘討論、其他快速過。

超 SLA 時自動 escalate

P0 超 SLA → Slack #incidents + Page on-call
P1 超 SLA → Slack #qa-leads + Email manager
P2 超 SLA → Daily standup 提
P3 超 SLA → Quarterly cleanup review

每個來源該有 不同 intake channel：

• QA / Dev → 直接建 Jira/Linear
• Customer support → Form → 自動 create ticket（含 user info）
• Bug bounty → 走 security review
• 監控 / Sentry → 自動建、自動分類

症狀：Backlog 1000+ ticket、過期、沒人 own。

Quarterly Cleanup（救命）

每季一次「bug bash cleanup」：

1. 列 P3 + 90 天無動的 ticket
2. 每個重新評估：still relevant?
3. 不 relevant → Won't fix + 標原因
4. Still relevant → 重新 prioritize
5. 跑完後 backlog 通常砍掉 60-80%

Bug Budget（進階）

每 sprint 預留 20% 給 bug fix：

Sprint capacity = 100 hours
- 80 hours: feature work
- 20 hours: bug fix budget

新 P1 bug 進來 → 從 bug budget 扣。 Bug budget 用完 → feature 延、不加班補。

Reopen 率 > 10% = 流程有洞。

Verify SOP

1. Reproduce 原 bug（用原始 steps）
2. 確認在 fix 版本不能 reproduce
3. 跑相關 regression case
4. 跨環境驗（dev 改的 env 跟 prod 不一樣）
5. 看 fix 有沒有副作用（test 旁邊功能）
6. Close + comment：「Verified on [env] with [version]」

垃圾 ticket 進入流程 → triage 浪費時間 → 修錯 / 沒修。

改善方法：

延伸閱讀：Bug Report 撰寫 SOP

工具: Jira / Linear / GitHub Issues / Notion

必設定:
- Issue template（強制欄位）
- Severity + Priority 兩個獨立欄位
- Status workflow（state machine）
- Auto-transition rules（例如 PR merge → 自動移 Ready for QA）
- SLA tracking + 超時 alert
- Dashboard（show me P0/P1 open、ticket age）

Linear 範例 workflow

Backlog → Triaged → In Progress → Code Review → Ready for QA → Verified → Closed
                                                    ↓
                                                  Reopened ↺

加自訂 status: Cant Reproduce, Duplicate, Wont Fix。

Routing 規則寫成文件。沒寫 = 每次 triage 吵 30 分鐘。

1. 沒有 lifecycle 的 bug 系統 = ticket 墳場
2. Severity ≠ Priority、分開兩個欄位
3. SLA + 自動 escalation 是健康指標
4. Quarterly cleanup 是必修、不是可選
5. Reopen 率是 process 品質的真相指標

Open by severity:
- P0: 3
- P1: 15
- P2: 47
- P3: 234

Created vs Closed（過去 7 天）:
- Created: 28
- Closed: 22
- Net: +6 ⚠️

Age distribution:
- < 7 days: 45%
- 7-30 days: 30%
- 30-90 days: 15%
- > 90 days: 10% ⚠️

SLA breach:
- P0: 0 ✅
- P1: 2 ⚠️
- P2: 12

Reopen rate: 8%

Net > 0 持續 2 週 = 警訊。 Reopen > 10% = 流程有洞。 > 90 天 ticket > 5% = 需要 cleanup。

Bug triage 不是 ticket 工人、是 quality 系統。沒有清晰 lifecycle + SLA + cleanup 機制 = 6 個月後變垃圾場。從今天起：（1）寫 lifecycle 文件、（2）開週會、（3）設 SLA、（4）每季 cleanup — 三個月後 backlog 從 800 變 80、每個 ticket 都有 owner。