實戰範例 007：重大故障回溯記憶檢索

背景

您的 SaaS 服務發生 API 500 錯誤，超過 50% 的使用者受到影響。這是本季度第二次類似故障，您意識到故障記憶未被有效儲存與關聯，導致團隊重複犯錯。透過 MemPalace，您能將每次故障的根本原因與解決方案逐字儲存，並建立與相關日誌、監控警報的關聯，確保未來類似故障可快速排除。

情境

本次故障：

症狀：API 500 錯誤，影響範圍 50% 使用者
時間：2024-11-15 14:30 UTC
警報：Datadog CPU 警報（>80%）、Slack 錯誤訊息、Pingdom 服務可用性警報

您記得上季度發生過類似故障，但無法快速找到根本原因與解決方案。使用 MemPalace，您能立即召喚相關記憶。

您想做什麼？

用戶：「能不能找出上季度類似故障的根本原因與解決方案？」

第 1 步：初始化 Palace（如果尚未初始化）

$ mempalace init --wing "d:/Repo/saas-service"
✓ Palace initialized at .mempalace
✓ First wing: d:/Repo/saas-service"

第 2 步：召喚故障記憶

使用 recall 搜尋關鍵詞：

$ mempalace recall --wing "d:/Repo/saas-service" --query "API 500 故障 根本原因 解決方案"

搜尋結果：

Top 1: drawer-001.md
Title: 故障 2024-08-12：API 500 錯誤，影響範圍 60% 使用者
Relevance: 0.92
Tags: incident,api-500,root-cause,solution
Content:
  **症狀**：API 500 錯誤，影響範圍 60% 使用者
  **時間**：2024-08-12 10:15 UTC
  **根本原因**：Redis 快取連線池耗盡，導致所有 API 請求回退至資料庫，造成資料庫連接超時
  **錯誤訊息**："Redis Connection Pool Exhausted: max_connections=100, active=100, wait_queue=850"
  **觸發因素**：
  1. 某行銷活動導致流量突增 3 倍
  2. Redis 連線池上限設定為 100（預設值），未依照新流量峰值調整
  **解決方案**：
  1. 緊急解決：動態調整 Redis 連線池上限至 500，後續配置文件永久更新為 300
  2. 永久解決：實施 Redis 快取監控，當連線池使用率超過 70% 時觸發自動擴容
  3. 預防措施：新增流量突增的預警規則，當 QPS 超過平時 2 倍時發送警報

Top 2: drawer-002.md
Title: 日誌 2024-08-12：Redis 連線池監控數據
Relevance: 0.85
Tags: incident,log,redis-connection-pool
Content:
[日誌完整內容...]

Top 3: drawer-003.md
Title: 警報 2024-08-12：Datadog CPU 警報（>80%）
Relevance: 0.78
Tags: incident,alert,datadog
Content:
[警報完整內容...]

第 3 步：檢視故障記憶間的關聯

使用 graph 視覺化故障、日誌與警報的關係：

$ mempalace graph --wing "d:/Repo/saas-service" --drawer "故障 2024-08-12：API 500 錯誤，影響範圍 60% 使用者"

結果：

graph LR
  drawer001[故障 2024-08-12：API 500] -->|has-log| drawer002[日誌 2024-08-12：Redis 連線池監控]
  drawer001 -->|triggered-by| drawer003[警報 2024-08-12：Datadog CPU]

此圖展示如何從根本原因追溯到相關日誌與警報，幫助團隊快速理解鏈路。

第 4 步：引用過去解決方案處理本次故障

基於 drawer-001 中的解決方案，立即執行：

# 1. 動態調整連線池上限
redis-cli -h production-redis -p 6379 CONFIG SET maxclients 500

# 2. 更新配置文件（永久解決）
echo "maxclients 300" | tee -a /etc/redis/redis.conf

# 3. 重啟 Redis
systemctl restart redis

第 5 步：添加本次故障記憶

解決後，將本次故障記錄為新 Drawer 並關聯到過去故障：

$ mempalace add \
  --wing "d:/Repo/saas-service" \
  --room "incidents" \
  --title "故障 2024-11-15：API 500 錯誤，影響範圍 50% 使用者" \
  --content "**症狀**：API 500 錯誤，影響範圍 50% 使用者\n**時間**：2024-11-15 14:30 UTC\n**根本原因**：同 sum故障（2024-08-12），Redis 連線池耗盡\n**引用解決方案**：drawer-001 中的三步驟解決方案\n**實施結果**：10 分鐘內服務恢復正常\n**後續改進**：已預費地將 Redis 連線池上限永久設為 300" \
  --tags "incident,api-500,root-cause,solution,recurrence"

第 6 步：關聯到過去故障

$ mempalace link \
  --wing "d:/Repo/saas-service" \
  --from "故障 2024-11-15：API 500 錯誤，影響範圍 50% 使用者" \
  --to "故障 2024-08-12：API 500 錯誤，影響範圍 60% 使用者" \
  --relation "recurrence-of" \
  --description "本次故障是 2024-08-12 故障的重複，均由 Redis 連線池耗盡引起，解決方案直接引用rawer-001"

✓ Linked drawer-004 → drawer-001

第 7 步：召喚故障串聯記憶

$ mempalace recall --wing "d:/Repo/saas-service" --query "故障 串聯 Redis 連線池"

搜尋結果顯示串聯鍊：

Top 1: drawer-004.md
Title: 故障 2024-11-15：API 500 錯誤，影響範圍 50% 使用者
Relevance: 0.95
Linked [recurrence-of] → drawer-001.md:
  Title: 故障 2024-08-12：API 500 錯誤，影響範圍 60% 使用者
  Linked [has-log] → drawer-002.md: 日誌 2024-08-12：Redis 連線池監控數據
  Linked [triggered-by] → drawer-003.md: 警報 2024-08-12：Datadog CPU 警報（>80%）

關鍵成果

✅ 透過 recall 快速找到過去故障記憶（relevance 0.92）
✅ 引用過去解決方案，10 分鐘內恢復服務
✅ 使用 graph 視覺化故障、日誌、警報的關聯
✅ 添加本次故障記憶並關聯到過去故障（recurrence-of）
✅ Knowledge Graph 串聯「故障 → 日誌 → 警報 → 重複故障」完整鍊路

延伸練習

建立故障趨勢的定期回顧流程：每月從 MemPalace 抽取 recent incidents 並分析趨勢（如重複根因、高影響範圍），進而更新容量規劃與監控規則。

Platform: Claude Code
Skill: oml-recall、oml-add、oml-link、oml-graph