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

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

Bug 完整 Lifecycle

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

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

flowchart LR
    Reject{該 reject<br>嗎?} --> R1["Can't Reproduce<br>→ 補 repro steps"]
    Reject --> R2["Duplicate<br>→ 連到原 ticket"]
    Reject --> R3["Not a Bug<br>→ 連到 spec"]
    Reject --> R4["Won't Fix<br>→ 連到 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 矩陣

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

flowchart LR
    Prep[會前準備] --> Meet[Meeting 30 min]
    Meet --> Post[會後 follow-up]

    Prep --> P1[列 New ticket]
    Prep --> P2[QA 預先看一輪]

    Meet --> M1["每個 ticket 30 秒<br>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 設計

flowchart LR
    SLA[Bug SLA] --> P0[P0]
    SLA --> P1[P1]
    SLA --> P2[P2]
    SLA --> P3[P3]

    P0 --> P0t[Triage: 1 hr<br>Fix: 4 hr<br>Verify: 1 hr]
    P1 --> P1t[Triage: 24 hr<br>Fix: 3 days<br>Verify: 1 day]
    P2 --> P2t[Triage: 1 week<br>Fix: this/next sprint<br>Verify: in sprint]
    P3 --> P3t[Triage: 1 week<br>Fix: backlog<br>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 來源管理

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。

flowchart TD
    Sym{症狀} --> S1[Backlog 永遠長大]
    Sym --> S2[60% ticket 半年沒動]
    Sym --> S3[reopen 率高]

    Fix[預防] --> F1["Quarterly cleanup<br>砍 P3 過期 ticket"]
    Fix --> F2["Auto-close<br>90 天無 activity"]
    Fix --> F3["每月 ticket age 報告"]
    Fix --> F4["Bug 入帳 cap<br>每 sprint 預留時間"]

    style Sym fill:#ef4444,color:#fff
    style Fix fill:#10b981,color:#fff

Quarterly Cleanup（救命）

每季一次「bug bash cleanup」：

列 P3 + 90 天無動的 ticket
每個重新評估：still relevant?
不 relevant → Won't fix + 標原因
Still relevant → 重新 prioritize
跑完後 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 模式分析

flowchart TD
    Reopen[Reopen 率高] --> Q{為什麼?}
    Q --> R1["Dev 修了但沒測<br>→ DoD 加 QA verify"]
    Q --> R2["QA verify 太草率<br>→ Verify SOP 跟 review"]
    Q --> R3["環境不同<br>→ Verify on 多環境"]
    Q --> R4["真的修錯方向<br>→ 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 浪費時間 → 修錯 / 沒修。

改善方法：

flowchart LR
    Quality[改善 bug 品質] --> Q1[Bug report template<br>強制必填欄位]
    Quality --> Q2[Auto-attach context<br>browser/OS/version]
    Quality --> Q3[Triage 退回機制<br>缺資訊 → request more info]
    Quality --> Q4[培訓 support / 用戶<br>怎麼報好 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

工具設定建議

工具: 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 流程

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<br>分拆成多 sub-ticket]

    style E fill:#f59e0b,color:#fff

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

反模式

flowchart TD
    Anti[Triage 反模式] --> A1["所有 bug 都 P1"]
    Anti --> A2["不設 SLA、永遠等"]
    Anti --> A3["Bug 直接 assign 給 dev<br>不過 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 句

沒有 lifecycle 的 bug 系統 = ticket 墳場
Severity ≠ Priority、分開兩個欄位
SLA + 自動 escalation 是健康指標
Quarterly cleanup 是必修、不是可選
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。

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