我如何用 Claude 將故障調查時間從 2 小時縮短到 15 分鐘

💡 這不是理論，是一個真實的晚上 10 點故障處理全記錄。

又是一個普通的週四晚上

上週四晚上 22:15，我正準備睡覺，手機開始震動。

Teams 訊息：

🔥 CRITICAL: API Gateway 5xx rate > 5%
🔥 CRITICAL: Response time > 3s
🔥 CRITICAL: User service health check degraded
⚠️ INFO: Multiple endpoints showing timeouts

又來了。

看到 "API Gateway 5xx + timeout"
第一反應是：「是誰在搞！🔥」

然後開始推測：

• 某個 Pod 掛了？
• 下游服務回應太慢？
• 資料庫有問題？
• 網路異常？

但光看告警訊息，無法直接判斷。
需要開電腦 查 logs 才知道。

要確認這些細節：

1. 具體是哪些請求在 timeout？
2. 錯誤集中在哪個服務、哪個 endpoint？
3. 有 correlation-id 可以追蹤嗎？
4. 是突發的還是逐漸增加？
5. 以前有遇過類似的嗎？

這些需要：

• 查 K8s 看 Pod 狀態
• 查 Grafana 看 metrics 趨勢
• 查 OpenSearch 看 API Gateway logs
• 用 correlation-id 追蹤到後端服務
• 查 Jira 找歷史案例

以前：逐一登入系統手動查（30-40 分鐘）
現在：我決定試試 AI 協作...

完整的調查過程

整個對話記錄是這樣：

[22:17] 開始調查

我：
「收到 API Gateway 5xx 錯誤告警（提供截圖）
幫我調查這個問題」

Claude：
「我透過 OpenSearch MCP 查詢到：

• 共發現 156 筆 5xx 錯誤
• 主要錯誤：504 Gateway Timeout (92%)
• 時間範圍：22:05-22:15
• 受影響的 endpoints：
  • /api/user/profile (78 次)
  • /api/user/settings (52 次)
  • /api/user/preferences (26 次)

關鍵發現：
所有錯誤的 response 都包含 "upstream request timeout"

這表示不是 API Gateway 的問題
而是後端的 User Service 回應太慢

要我追蹤到 User Service 的 logs 嗎？」

我心裡想：
不到 1 分鐘，就查完所有 logs 並分析出關鍵資訊。
以前光是寫 Query DSL 就要 5 分鐘。

[22:20] 追蹤根因

我：
「對，幫我追蹤看看」

Claude：
「我用 correlation-id 追蹤到 User Service 的 logs：

找到問題了！
User Service 有大量錯誤：

• 錯誤：Failed to acquire database connection within 3000ms
• 發生時間：與 API Gateway 錯誤時間完全吻合

同時發現關鍵 metrics：

• Database connection pool: 95% usage (48/50)
• Active connections: 48
• Wait queue: 15+ requests
• Database slow query logs: 多個 queries > 5s

完整的故障鏈：

1. Database 有 slow queries（> 5s）
2. Slow queries 長時間佔用 connection
3. Connection pool 逐漸被佔滿
4. 新請求拿不到 connection → timeout
5. User Service 無法處理請求
6. API Gateway 等不到回應 → 504

這是典型的 slow query 導致 connection pool 用盡。
要我查這種問題以前怎麼處理的嗎？」

我心裡想：
如果是手動追蹤，光是複製 correlation-id、切換系統、查詢，就要 15 分鐘。
AI 不到 1 分鐘就完成，還直接給我完整的故障鏈分析。

[22:23] 查歷史案例

我：
「查一下歷史案例」

Claude：
「從 Jira 找到 2 個類似案例：

1. PROJ-5678 (2 個月前)

   • 同樣的 database timeout + connection pool 滿
   • 原因：某個 SQL query 沒有 index
   • 解法：加 index + 優化 query

2. PROJ-4123 (4 個月前)

   • Connection pool 用滿但原因不同
   • 原因：pool size 設定太小
   • 解法：調整 pool size 50 → 100

從 error pattern 來看：
這次比較像 PROJ-5678（slow query 問題）

要我整理當時的處理步驟嗎？」

我心裡想：
PROJ-5678 那次我還記得。
但如果沒有 AI 提醒，我可能要翻找 10 分鐘才想起來。

[22:25] 找處理步驟

我：
「給我處理建議」

Claude：
「根據 PROJ-5678 的處理經驗，當時的做法是：

SRE 的處理步驟：

1. 保留現場

   • 截圖 connection pool metrics
   • 記錄 slow query logs（如果有權限）
   • 記錄時間範圍

2. 先評估，並恢復服務

   • 評估重啟的影響性
   • 重啟受影響的 service（釋放 connection pool）
   • 不要等 DBA，先讓服務恢復

3. 通知團隊

   • 告訴 DBA：「有 slow queries 需要分析」
   • 告訴 RD：「User Service 可能有性能問題」
   • 提供完整的調查結果

後續由 DBA + RD 處理：

• 與 DBA 找出並優化 slow queries
• RD 改善 application 層邏輯
• SRE 加強監控

建議執行：
kubectl rollout restart deployment/user-service -n production

要我產生完整的執行步驟嗎？」

我心裡想：
這些步驟跟 PROJ-5678 當時處理的一樣。
但如果沒有 AI 提醒，我可能要翻找好久才想起來。

[22:27] 執行修復

我：
「產生完整步驟」

Claude：
「執行步驟如下：

# Step 1: 緊急重啟（恢復服務）
kubectl rollout restart deployment/user-service -n production

# Step 2: 監控狀態
kubectl rollout status deployment/user-service -n production

# Step 3: 確認恢復
watch -n 2 'kubectl get pods -n production | grep user-service'

# Step 4: 觀察 metrics
觀察以下指標：
- 5xx rate 應該下降到 < 1%
- Response time 應該恢復到 < 500ms
- Connection pool usage 應該降到 < 60%

# Step 5: 後續追蹤
- 聯絡 DBA 分析 slow query
- 準備加 index 或優化 query

執行完成後告訴我結果。」

我執行指令。
服務在 3 分鐘內恢復。

[22:30] 產生報告

我：
「服務已恢復，幫我產生 Incident Report」

Claude：
「Incident Report 初稿如下：

# Incident Report: API Gateway 504 Timeout

## Summary
- 發生時間: 2025-01-XX 22:05 - 22:30
- 影響範圍: User Service APIs
- 嚴重程度: High
- 調查時間: 15 分鐘
- 恢復時間: 5 分鐘

## Timeline
22:05 - 開始出現 504 timeout
22:10 - 錯誤率逐漸上升
22:15 - 告警觸發
22:17 - 開始調查
22:21 - 找到根因（slow query + connection pool 滿）
22:24 - 查詢歷史案例
22:28 - 執行重啟
22:30 - 服務恢復

## Root Cause
表面症狀: API Gateway 回傳 504 Gateway Timeout
實際根因: Database slow queries 導致 connection pool 用盡

故障鏈：
1. Database 有 slow queries（> 5s）
2. Slow queries 長時間佔用 connection
3. Connection pool 逐漸被佔滿（95% usage）
4. 新請求拿不到 connection → connection wait timeout
5. User Service 無法處理請求
6. API Gateway 等不到回應 → 504

## Investigation Method
1. 查詢 API Gateway logs → 發現 upstream timeout
2. 用 correlation-id 追蹤 → 找到 User Service logs
3. 發現 "Failed to acquire connection" + connection pool 滿
4. 查詢 Jira 歷史 → 找到類似 slow query 案例
5. 從歷史案例學習處理方式

## Resolution
緊急處理（SRE）：
- 重啟 User Service 釋放 connection pool
- 服務立即恢復
- 保留現場資料（metrics 截圖、logs）

後續改善（DBA + RD）：
- [ ] DBA 分析並優化 slow queries
- [ ] 考慮加 index
- [ ] RD 優化 application 層查詢邏輯
- [ ] SRE 增加 slow query 監控告警

## Lessons Learned
- ✅ Correlation-id 追蹤快速定位根因
- ✅ Connection pool monitoring 很重要
- ⚠️ 需要加強 slow query 預警機制

完成！」

我看了一下報告。
時間軸、根因、處理步驟，全部都有。
我只需要補充一些細節就好。

整個調查過程：15 分鐘
寫報告：5 分鐘

視覺化故障鏈

這次的故障傳遞路徑：

這就是為什麼需要 correlation-id 追蹤。
錯誤在 API Gateway，但根因在 Database。

為什麼能這麼快？

1. Correlation-id 自動追蹤

以前：手動複製 correlation-id、切換系統、查詢（15 分鐘）
現在：告訴 AI「追蹤到後端」，自動完成（< 1 分鐘）

錯誤在 API Gateway，根因在 Database。
AI 自動串聯整個故障鏈。

2. 歷史案例 + 處理方式

以前：去 Jira 搜尋、逐一閱讀、回想細節（20-25 分鐘）
現在：AI 找出類似案例 + 整理處理步驟（< 2 分鐘）

我可能會忘記 PROJ-5678。
但 AI 不會。

3. 自動產生報告

以前：回想過程、整理時間軸、寫 Root Cause（30 分鐘）
現在：AI 根據對話自動產生（5 分鐘）

省下 70 分鐘的「查詢」和「整理」時間。

技術上是怎麼做到的？

你可能會問：「這技術上怎麼做的？」

核心是：Claude + MCP (Model Context Protocol)

（第一篇已經介紹過 MCP 的概念了）

這個案例用到的 MCP：

• OpenSearch MCP → 查 API Gateway 和 User Service logs
• Atlassian MCP → 查 Jira 歷史案例 + Confluence Post-Mortem

重點是：
你不需要寫代碼整合這些系統。
只要安裝好 MCP Server，就能用自然語言查詢。

（詳細的設定方式，第三、四篇會手把手教你）

真實的團隊協作

這個案例也展現了 SRE 的真實工作：

不是一個人解決所有問題
而是「快速找到根因 + 協調團隊」

這次的分工：

SRE（我）：

• 調查找出根因（15 分鐘）
• 緊急重啟恢復服務（5 分鐘）
• 保留現場資料
• 通知 DBA 和 RD

DBA：

• 分析是哪些 slow queries
• 決定優化方案（加 index？改 query？）

RD：

• 實作改善
• 部署新版本

AI 協作讓我能：

• 更快找到根因（15 分鐘 vs 30-40 分鐘）
• 更快通知團隊（資料都整理好了）
• 更快寫完報告（AI 產生初稿）

整個 Incident 處理更順暢。

這個案例的啟發

處理完這次 Incident，我有幾個體會：

1. Correlation-id 真的很重要

以前知道要追蹤，但常常懶得做（太麻煩）。
現在有 AI 幫忙，變得很簡單。
我開始養成習慣：每次都追蹤到底。

2. 歷史案例是寶藏

這次如果沒找到 PROJ-5678，可能要多花很多時間。
知識重用的價值，比我想像的大。
這也讓我更願意寫 Post-Mortem。

3. SRE 的價值在判斷

AI 能幫我查資料。
但「決定要重啟還是等 DBA」是我的判斷。
SRE 的核心能力是「判斷」，不是「記住所有指令」。

結語

從收到告警到寫完報告，整整 15 分鐘。

關鍵是：AI 幫你處理「重複性查詢」，你專注在「判斷」和「決策」。

下一篇預告

第三篇：OpenSearch MCP 設定
手把手教你如何安裝、設定、查詢 logs

第四篇：Atlassian MCP 設定
一次設定 Jira + Confluence，重用歷史經驗

看完就能實作。

如果你對這個案例有問題，或想分享你的 Incident 處理經驗，歡迎留言交流！

本文是「SRE × AI 實戰系列」的第 2 篇，共計 10 篇。