情境背景

你負責一個 API 服務，使用者回報「API 回應時間越來越慢，有時超過 5 秒」。你已經嘗試過一些優化（例如新增快取、調整查詢），但問題仍然存在。你決定使用系統化除錯來進行徹底調查。

問題表現

• API 回應時間從 100ms 增加到 5 秒
• 只在某些 API 端點發生問題（訂單 API）
• CPU 使用率正常（< 50%）
• 記憶體使用率正常（< 40%）
• 資料庫連線池連接數正常（< 10）

第 1 步：根因調查

目標：使用系統化除錯進行根因調查

觸發：

/systematic-debugging

AI 對話：

• You:

  /systematic-debugging

• AI:

  讓我們一起系統化地診斷這個 API 延遲問題。

  第一個問題：問題的具體表現是什麼？

  • You:

  訂單 API 有時超過 5 秒才回應。

  AI: 讓我收集一些資訊。

  資訊收集：

  • 監控數據：CPU、記憶體、網路都正常
  • 查詢日誌：慢查詢都在訂單 API
  • 資料庫連接：連線數正常

  第二個問題：你嘗試過哪些優化？

  • You:

  我新增了 Redis 快取，但效果不明顯。

  AI: 讓我檢查 Redis 快取的使用情況。

  發現：

  • Redis 快取確實命中
  • 快取命中率只有 30%
  • Redis 快取未命中時，仍會查詢資料庫

  第三個問題：為什麼快取命中率只有 30%？

  • You:

  可能是快取的 key 設式設計不當。

  AI: 讓我檢查快取的 key 設式設計。

  發現：

  • key 包含完整查詢條件

• 查詢條件件件太長（包含過濾濾的參數）

• 不同條件的 key 格式不一致

• 大量重複的查詢

第 2 步：建立假設

目標：基於初步調查，建立並驗證假設

第一個假設：快取 key 設式不當，導致快取命中率低

驗證方法：

1. 重新設計快取 key 格式
2. 觀察命中率是否提升
3. 如果沒有提升，假設被反駁

第 3 步：深入調查

目標：深入調查其他可能的原因

第二個假設：查詢邏輯本身有問題

驗證方法：

1. 在查詢邏輯中添加時間戳
2. 測量查詢
3. 分析慢查詢的查詢條件
4. 識別最慢的查詢

AI 對對話：

• AI:

  讓我檢查查詢邏輯…

  發現：

  • 有一個查詢 SELECT * FROM orders WHERE created_at > ? AND user_id = ? ORDER BY id LIMIT 100
  • 沒有適當的索引
  • 每次查詢都掃描 50 萬記錄
  • 50 萘記錄 × 100 個 = 5000 萘記錄

  結論：查詢邏輯本身沒有問題，但缺乏適當索引

第 4 步：解決方案

目標：制定解決方案並實作

解決方案：

1. 新增適當的索引：

   CREATE INDEX idx_orders_user_created_at_created_at 
   ON orders(user_id, created_at);

2. 優化快取 key 格式：

   • 只儲存關鍵欄位
   • 使用 JSON 格式（標準化）

3. 定期維護索引：

   • 定期重新建立索引
   • 移除未使用的索引

實作完成

實作內容：

• 新增資料庫索引 ✓
• 優化快取 key ✓
• 誇式碼更新 ✓
• 測試通過 ✓

驗證結果

驗收標準：

• API 回應時間 < 100ms
• 所有測試通過
• 系統運作正常

實測結果：

• API 回應時間：80ms ✓
• 所有測試通過 ✓
• 系統運作正常 ✓

工具使用摘要

結果

• ✅ 問題徹底解決
• ✅ API 回應時間降至 80ms
• ✅ 系統運作更穩定
• ✅ 建立長期維護機制

超驗

問題解決後，使用者反饋：「現在 API 回應速度大幅提升，問題不再出現。」