老闆說「之前有發生過嗎？查一下。」你翻了 10 分鐘 Confluence。查完他又說：「Action items 都開 ticket 追蹤。」

你翻過 Confluence 翻到懷疑人生嗎？

Incident 發生了。

你正在查 log、追 correlation ID，腦袋全速運轉。

這時候老闆問了一句：

「這個問題之前有遇過嗎？」

你打開 Confluence，輸入關鍵字，搜尋。

沒有結果。

換個關鍵字，再搜。找到 3 篇，點進去看。

第一篇不相關。
第二篇有點像，但是去年的。
第三篇才是要找的。

10 分鐘過去了。

你的調查思路，已經斷了。

好不容易回答完老闆，他又說：

「Action items 都開 ticket 追蹤一下。」

你打開 Jira。
選 project，選 issue type。
填 summary，寫 description。
選 priority、assignee、label。

一張 ticket 就要 5-10 分鐘。

這次有 5 個 action items。

又是半小時。

這篇要解決的，就是這兩件事。

1. 透過 MCP（Model Context Protocol，讓 AI 直接呼叫外部工具的標準協定）讓 AI 幫你搜 Confluence
2. 幫你建 Jira ticket。

場景 1：搜 Confluence 查歷史

什麼時候會需要搜 Confluence？

兩種情境。

情境 A：你自己想查。

Issue 發生的時候，你腦中閃過一個念頭：

「這好像之前遇過？上次是怎麼處理的？」

你想查歷史紀錄，看看有沒有可以參考的。

情境 B：老闆問你。

「之前有發生過嗎？」
「上次是什麼原因？」
「發生過幾次了？」

不管是哪種情境，第一步都是 — 打開 Confluence，開始搜。

Before：手動搜的痛

以 Payment Service 503 為例。

你搜「Payment Service 503」。

沒結果。

因為上次報告的標題寫的是「Payment Service 5xx Error」，不是 503。

你改搜「Payment Service 5xx」。
找到 2 篇。

但其中一篇是去年的，跟 health probe 有關。
你又搜「Payment Service health probe」。
找到另外 1 篇。

現在你有 3 篇要看。
點進去，翻到根因的段落，看看跟現在的狀況像不像。

10 分鐘過去了。你的調查才剛開始。

問題不只是慢。

是你在搜 Confluence 的這 10 分鐘，腦袋從「調查模式」切換到「搜尋模式」。

等你搜完，要花力氣把思路拉回來。

思路中斷，才是最大的成本。

After：AI 搜的方式

裝了 Atlassian MCP 之後，我現在是這樣做的：

「幫我搜 Confluence，看 Payment Service 503 之前有沒有發生過。」

AI 會做什麼？

1. 搜「Payment Service 503」
2. 搜「Payment Service 5xx」
3. 搜「Payment Service error」
4. 找到相關頁面後，自動讀取內容
5. 整理成摘要回覆你

找到 3 篇相關紀錄：

1. [2025-01-15] Payment Service 5xx - Connection Pool Exhaustion
   根因：Connection pool 設定過小，高流量時耗盡
   處理：調整 pool size 從 10 → 50

2. [2024-11-20] Payment Service 503 - HPA Scaling Issue
   根因：HPA（Horizontal Pod Autoscaler）minReplicas 設太低，cold start 來不及
   處理：調整 minReplicas 從 2 → 5

3. [2024-08-03] Payment Service 5xx - Health Probe Timeout
   根因：Readiness probe timeout 太短
   處理：timeout 從 3s → 10s

1 分鐘內搞定。

而且重點是：這段摘要你可以直接貼給老闆。

不用自己翻 3 篇文件再整理。

關鍵差距：一組 vs 多組關鍵字

你可能會想：「我自己搜也可以啊，就是慢一點。」

但真正的差距不是速度。

是你搜一組關鍵字，AI 搜多組。

人在搜尋的時候，很容易「第一組找到了就停」。
但 Confluence 上的報告，標題可能寫 503、也可能寫 5xx、也可能寫 error。

一組關鍵字不夠。

AI 不會嫌麻煩。它會自動多搜幾組，然後幫你整理。

搜得快 + 搜得全 + 自動整理 = 不打斷你的調查思路。

場景 2：批量建 Jira Ticket 追蹤 Action Items

痛點：一張不痛，五張就痛了

Incident 結束後，老闆說：「Action items 都開 ticket 追蹤。」

你打開調查結論，列了 5 個 action items：

1. 調整 connection pool size
2. 更新 HPA 設定
3. 新增 alerting rule
4. 更新 runbook
5. 安排 load testing

每一張 Jira ticket 都要：

• 開 Jira
• 選 Project
• 選 Issue Type
• 填 Summary
• 寫 Description
• 選 Priority
• 指定 Assignee
• 加 Label

一張 5-10 分鐘。
5 張就是半小時起跳。

而且這些 ticket 的內容，你在調查的時候其實都已經想好了。
只是要把它「搬」進 Jira 的格式裡。

這種重複又瑣碎的搬運工作，最適合交給 AI。

Before vs After

Before：

打開 Jira
→ 選 Project: SRE
→ Issue Type: Task
→ Summary: 調整 Payment Service connection pool size
→ Description: （寫了一段）
→ Priority: High
→ Assignee: Backend Team
→ Label: incident-followup
→ Create

...重複 4 次

After：

「根據這次 Payment Service 503 的調查結果，幫我建 5 張 Jira action item tickets。」

AI 根據調查上下文，自動幫你：

• 產生 5 張 ticket 的 Summary 和 Description
• 設定 Priority（根據嚴重程度）
• 加上對應的 Label
• 一次建好

✅ PROJ-1234: Increase Payment Service connection pool size (High)
✅ PROJ-1235: Update HPA minReplicas configuration (High)
✅ PROJ-1236: Add alerting rule for connection pool usage (Medium)
✅ PROJ-1237: Update Payment Service runbook (Medium)
✅ PROJ-1238: Schedule load testing for Payment Service (Low)

5 張 ticket，2 分鐘搞定。

你只需要看一眼確認，不用自己填任何欄位。

量大才是真正的痛

開一張 ticket 不難。

難的是每次都要開、每張都要填。

一個月遇到 3-4 次 incident，每次 3-5 張 action items。
算下來一個月光是開 ticket 就花 2-3 小時。

這 2-3 小時不會讓你成長。
不會讓你學到新東西。
純粹就是機械式的搬運。

AI 最適合處理的，就是這種事。

完整 Incident 工作流

到目前為止，我們在這個系列已經涵蓋了 Incident 處理的幾個關鍵環節。

把它們串起來：

📢 告警觸發
   ↓
🔍 搜歷史：Confluence 查過往案例（本篇）
   ↓
📋 查 Log：OpenSearch 查錯誤日誌（第三篇）
   ↓
🔬 分析根因：AI 協助判斷（第二篇）
   ↓
🎫 建 Ticket：批量建立 Jira action items（本篇）

時間對比

這還不包含監控查詢的部分。

下一篇會補上 Monitoring MCP（Prometheus + Icinga2 + Site24x7），把監控這塊也串進來。

工具篇還有最後一塊拼圖。

安裝 Atlassian MCP

你需要什麼

1. Atlassian Cloud 帳號
2. API Token
3. Claude Code（或 Claude Desktop）

Step 1：取得 API Token

到 Atlassian API Token 頁面 建立一個 token。

一個連結就搞定。記得把 token 存好，等一下要用。

Step 2：安裝 MCP Server (以社群版mcp-atlassian為例）

Github: https://github.com/sooperset/mcp-atlassian

方法 A：用 claude mcp add-json（推薦）

一行指令搞定：

claude mcp add-json "mcp-atlassian" \
'{
    "command": "uvx",
    "args": ["mcp-atlassian"],
    "env": {
      "CONFLUENCE_URL": "https://your-domain.atlassian.net/wiki",
      "CONFLUENCE_USERNAME": "your-email@example.com",
      "CONFLUENCE_API_TOKEN": "your-api-token",
      "JIRA_URL": "https://your-domain.atlassian.net",
      "JIRA_USERNAME": "your-email@example.com",
      "JIRA_API_TOKEN": "your-api-token"
    }
}' --scope project

把 your-domain、your-email、your-api-token 換成你自己的。

--scope project 表示只對當前專案生效。想全域使用，改成 --scope user。

方法 B：手動編輯 mcp.json

如果你習慣直接改設定檔，在 .claude/mcp.json（或 Claude Desktop 的 config）加入：

{
  "mcp-atlassian": {
    "command": "uvx",
    "args": ["mcp-atlassian"],
    "env": {
      "CONFLUENCE_URL": "https://your-domain.atlassian.net/wiki",
      "CONFLUENCE_USERNAME": "your-email@example.com",
      "CONFLUENCE_API_TOKEN": "your-api-token",
      "JIRA_URL": "https://your-domain.atlassian.net",
      "JIRA_USERNAME": "your-email@example.com",
      "JIRA_API_TOKEN": "your-api-token"
    }
  }
}

兩種方法效果一樣，選你習慣的。

Step 3：測試

重啟 Claude Code，試試看：

• 「搜尋 Confluence 上關於 Payment Service 的頁面」
• 「列出 Jira 上 SRE project 最近的 tickets」

如果都能正常回應，就設定成功了。

安全提醒

Atlassian MCP 有寫入權限。

跟上一篇的 OpenSearch MCP（唯讀）不同，這個 MCP 可以：

• 建立 Jira ticket
• 建立 Confluence 頁面
• 修改現有內容

所以 token 管理很重要：

1. 不要 commit token 到 git — 用環境變數或 .env 檔管理
2. 定期更換 token — 建議每 90 天換一次
3. 注意權限範圍 — token 的權限跟你帳號一樣，能做的事情很多

我的建議是：先用自己的帳號測試，確認流程沒問題後，再考慮要不要開一個專用的 service account。

結語

Atlassian MCP 做的事情很簡單：

讓搜尋和建立，都變成一句話的事。

搜 Confluence？一句話。
開 Jira ticket？一句話。
批量開 5 張？也是一句話。

但目前我們還是「一個個動作」在做 — 搜一下、建一下。

下一篇，我們要補上工具篇最後一塊拼圖：Monitoring MCP。

Prometheus、Icinga2、Site24x7 — 三個監控工具，一個 AI 對話搞定。

等工具都齊了，再來把整個 Incident 流程串起來，從調查到報告一條龍。

如果你試了 Atlassian MCP，歡迎留言分享你的使用經驗。