--- title: Bug Triage 完整流程 — 從 New 到 Closed 的 lifecycle 與 SLA 設計 description: Bug 從回報到關閉的完整 lifecycle。State machine、Severity/Priority 矩陣、Triage meeting 怎麼開、SLA 設計、跨團隊責任歸屬、避免 ticket 墳場。 category: manual tags: [bug-triage, lifecycle, bug-management, sla, process] date: 2026-06-12 --- # Bug Triage 完整流程 — 從 New 到 Closed 的 Lifecycle 與 SLA 設計 「Jira 上 800 個 bug 沒人處理」是大公司日常。**Bug triage 流程設計爛 = ticket 墳場 = 真重要的事被掩埋**。這篇給你完整 lifecycle、severity 矩陣、triage meeting playbook。 ## Bug 完整 Lifecycle ```mermaid stateDiagram-v2 [*] --> New New --> Triaged: Triage 分類 New --> Duplicate: 重複 New --> CantReproduce: 無法重現 New --> NotABug: 不是 bug Triaged --> InProgress: Assign 給 dev Triaged --> Backlog: 暫不處理 InProgress --> CodeReview: PR 提出 CodeReview --> ReadyForQA: PR merged ReadyForQA --> Verified: QA 驗證通過 ReadyForQA --> Reopened: 仍有問題 Reopened --> InProgress: 回去修 Verified --> Closed: Release 後 Backlog --> Triaged: 再次優先級評估 Duplicate --> Closed CantReproduce --> Closed NotABug --> Closed Closed --> [*] ``` 每個 state 都該有 **owner**（負責人）跟 **SLA**（多久該轉到下一個）。 ## 9 個 State 詳解 ### State 1: New（剛建立） | | | |--|--| | 誰建 | QA / Support / User / 自動化系統 | | Owner | 待 triage | | SLA | 24 小時內 triage | ### State 2: Triaged（分類完） Triage 過程確認： - ✅ Severity（傷害大小） - ✅ Priority（修復急迫度） - ✅ Component（哪塊） - ✅ Assigned to（誰修） - ✅ Target version（哪版修） ### State 3: In Progress（修中） | Owner | Dev | | SLA | 看 priority：P0 4 hr / P1 3 天 / P2 1 sprint | ### State 4: Code Review | Owner | Reviewer | | SLA | 24 小時內 review | ### State 5: Ready for QA（待驗證） | Owner | QA | | SLA | 看 priority：P0 4 hr / P1 1 天 | ### State 6: Verified（驗證通過） 可以 close、或等下次 release。 ### State 7-9: Reject / Duplicate / Won't Fix ```mermaid flowchart LR Reject{該 reject
嗎?} --> R1["Can't Reproduce
→ 補 repro steps"] Reject --> R2["Duplicate
→ 連到原 ticket"] Reject --> R3["Not a Bug
→ 連到 spec"] Reject --> R4["Won't Fix
→ 連到 backlog/wontdo doc"] style R1 fill:#f59e0b,color:#fff style R2 fill:#a855f7,color:#fff style R3 fill:#06b6d4,color:#fff style R4 fill:#ef4444,color:#fff ``` **全都要寫原因**。直接 close 是文化殺手。 ## Severity × Priority 矩陣 ```mermaid quadrantChart title Severity vs Priority Matrix x-axis Low Priority --> High Priority y-axis Low Severity --> High Severity quadrant-1 P0 - Drop everything quadrant-2 P1 - This sprint quadrant-3 P2 - Next sprint quadrant-4 P3 - Backlog "資料遺失": [0.9, 0.95] "結帳壞": [0.85, 0.9] "Logo 變形": [0.4, 0.2] "舊版瀏覽器 crash": [0.5, 0.5] "小錯字": [0.2, 0.1] "可繞過的 bug": [0.6, 0.4] ``` ### 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（不修） ``` ## Triage Meeting Playbook ```mermaid flowchart LR Prep[會前準備] --> Meet[Meeting 30 min] Meet --> Post[會後 follow-up] Prep --> P1[列 New ticket] Prep --> P2[QA 預先看一輪] Meet --> M1["每個 ticket 30 秒
S / P / Owner / Target"] Meet --> M2[爭議的 5 分鐘] Post --> Po1[更新 ticket] Post --> Po2[Slack notify owner] style Meet fill:#06b6d4,color:#fff ``` ### 開會節奏 | 公司階段 | 頻率 | 時長 | |---------|------|------| | 新創 / 小團隊 | 每週 1 次 | 30 min | | 中型 | 每週 2 次 | 45 min | | 大型 / 多 team | 每 team daily | 15 min | ### 參與者 ``` 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 設計 ```mermaid flowchart LR SLA[Bug SLA] --> P0[P0] SLA --> P1[P1] SLA --> P2[P2] SLA --> P3[P3] P0 --> P0t[Triage: 1 hr
Fix: 4 hr
Verify: 1 hr] P1 --> P1t[Triage: 24 hr
Fix: 3 days
Verify: 1 day] P2 --> P2t[Triage: 1 week
Fix: this/next sprint
Verify: in sprint] P3 --> P3t[Triage: 1 week
Fix: backlog
Verify: when fixed] style P0 fill:#ef4444,color:#fff style P1 fill:#f59e0b,color:#fff style P2 fill:#06b6d4,color:#fff style P3 fill:#a855f7,color:#fff ``` ### 超 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 ``` ## Bug 來源管理 ```mermaid mindmap root((Bug 來源)) 內部 QA 找的 Dev 自己找的 Code review 中 外部 Customer support Beta tester Bug bounty Sentry / 監控 自動 CI / E2E fail Production alert User analytics ``` 每個來源該有 **不同 intake channel**： - QA / Dev → 直接建 Jira/Linear - Customer support → Form → 自動 create ticket（含 user info） - Bug bounty → 走 security review - 監控 / Sentry → 自動建、自動分類 ## 防止「ticket 墳場」 **症狀**：Backlog 1000+ ticket、過期、沒人 own。 ```mermaid flowchart TD Sym{症狀} --> S1[Backlog 永遠長大] Sym --> S2[60% ticket 半年沒動] Sym --> S3[reopen 率高] Fix[預防] --> F1["Quarterly cleanup
砍 P3 過期 ticket"] Fix --> F2["Auto-close
90 天無 activity"] Fix --> F3["每月 ticket age 報告"] Fix --> F4["Bug 入帳 cap
每 sprint 預留時間"] style Sym fill:#ef4444,color:#fff style Fix fill:#10b981,color:#fff ``` ### 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 模式分析 ```mermaid flowchart TD Reopen[Reopen 率高] --> Q{為什麼?} Q --> R1["Dev 修了但沒測
→ DoD 加 QA verify"] Q --> R2["QA verify 太草率
→ Verify SOP 跟 review"] Q --> R3["環境不同
→ Verify on 多環境"] Q --> R4["真的修錯方向
→ Root cause 不對"] style Reopen fill:#f59e0b,color:#fff ``` **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]」 ``` ## Bug 報告品質改善 垃圾 ticket 進入流程 → triage 浪費時間 → 修錯 / 沒修。 **改善方法**： ```mermaid flowchart LR Quality[改善 bug 品質] --> Q1[Bug report template
強制必填欄位] Quality --> Q2[Auto-attach context
browser/OS/version] Quality --> Q3[Triage 退回機制
缺資訊 → request more info] Quality --> Q4[培訓 support / 用戶
怎麼報好 bug] style Q1 fill:#06b6d4,color:#fff style Q2 fill:#10b981,color:#fff style Q3 fill:#a855f7,color:#fff style Q4 fill:#f59e0b,color:#fff ``` 延伸閱讀：[Bug Report 撰寫 SOP](/manual/bug-report-sop.html) ## 工具設定建議 ``` 工具: 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`。 ## 跨團隊 / Multi-team 流程 ```mermaid flowchart TD Bug[Bug 進來] --> Route{歸誰?} Route --> A[Frontend team] Route --> B[Backend team] Route --> C[Mobile team] Route --> D[Platform / Infra] Route --> E[Multi-team] E --> Lead[Owner: Engineering Manager
分拆成多 sub-ticket] style E fill:#f59e0b,color:#fff ``` **Routing 規則寫成文件**。沒寫 = 每次 triage 吵 30 分鐘。 ## 反模式 ```mermaid flowchart TD Anti[Triage 反模式] --> A1["所有 bug 都 P1"] Anti --> A2["不設 SLA、永遠等"] Anti --> A3["Bug 直接 assign 給 dev
不過 triage"] Anti --> A4["Close 不寫原因"] Anti --> A5["Reopen 沒分析"] Anti --> A6["不開 triage meeting"] Anti --> A7["Backlog 永遠長大"] style A1 fill:#ef4444,color:#fff style A2 fill:#ef4444,color:#fff style A3 fill:#ef4444,color:#fff style A4 fill:#ef4444,color:#fff style A5 fill:#ef4444,color:#fff style A6 fill:#ef4444,color:#fff style A7 fill:#ef4444,color:#fff ``` ## 給 QA Lead 的 5 句 1. **沒有 lifecycle 的 bug 系統 = ticket 墳場** 2. **Severity ≠ Priority、分開兩個欄位** 3. **SLA + 自動 escalation 是健康指標** 4. **Quarterly cleanup 是必修、不是可選** 5. **Reopen 率是 process 品質的真相指標** ## Metrics 看板（每週看） ``` 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。