
AI 很聰明。但它不知道你們的 log 要去哪裡查、哪個 index 對應哪個服務、收到 503 要先看什麼。
前幾篇我們接好了 OpenSearch、Confluence、Monitoring 這些工具。
AI 確實能用。
但你有沒有遇過這種情況?
你說「幫我查 Payment Service 的 500 錯誤」。
AI 去查了。但它查的 index 不對。
或是它先去查了 Prometheus,但其實這個問題應該先看 server log。
AI 不笨,但它不知道你的調查習慣。
這些是你做 SRE 累積的直覺。
但這些直覺存在你腦袋裡。AI 讀不到。
這篇聊的不是怎麼寫漂亮的 prompt。
是怎麼把你的調查經驗,變成 AI 能讀的文件。
你不是寫一個很長的 prompt。
你是建一套分層的知識系統。
第一層:環境設定
→ 時區、帳號對照、基本設定
→ 每次對話自動載入
第二層:調查 SOP ⭐ 最重要
→ 收到告警先做什麼?
→ 根據錯誤類型決定調查路徑
第三層:服務參考文件
→ 每個服務一份:log index、常見問題、關鍵欄位
→ AI 查的時候自動參考
第四層:歷史案例
→ 之前的調查紀錄,按日期歸檔
→ 「上次類似問題怎麼解的?」
第一層很簡單,幾行設定。
第四層是自然累積的,每次調查就多一筆。
真正需要你花心思的是第二層和第三層。
這是整個系統的核心。
教 AI「收到告警的前 5 秒該做什麼」。
我的做法是寫一份 Investigation Cheat Sheet。長這樣:
收到 SLA 5xx 告警
├─ 先確認:單一 request 還是持續性?
│ ├─ 單一 request → 可能瞬態,先觀察
│ └─ 持續性 → 繼續調查
│
├─ 查 access log:哪個 API、哪個 status code
│ ├─ 503 → Pod 問題(HPA scaling、readiness)
│ ├─ 500 → application 層(查 server log)
│ └─ 502 → 上游服務問題(查 upstream)
│
└─ 查 其他 server log:有沒有 error message
├─ DB error → 查 DB 連線、SP 邏輯
├─ Timeout → 查上游回應時間
└─ 沒有 server log → 基礎設施層(查 Prometheus)
有這份 cheat sheet,AI 會按照你的邏輯走。
沒有的話,它會「什麼都查」。方向不對,浪費時間。
就像資深 SRE 帶新人:「先看這個,再看那個。」
Cheat sheet 就是你帶 AI 這個新人的方式。
我是怎麼開始寫?
不需要一次寫完。
每次調查後問自己一個問題:
「這次我是怎麼決定先查什麼的?」
把那個決策過程寫下來。那就是 cheat sheet 的一條規則。
累積 10 次調查,你的 cheat sheet 就很完整了。
每個服務一份文件。10-20 行就夠。
# Payment Service
## 基本資訊
- Access Log Index: payment-production-access-log-*
- server log Index: payment-production-server-log-*
- Prometheus: 有(K8s pod metrics)
## 常見問題
- 503: 通常是 HPA scaling,查 pod readiness
- 500: 通常是 DB/Application 問題,查 server log
- Timeout: 查上游 Auth Service 回應時間
## 關鍵欄位
- correlation_id: request_id
- 回應時間: duration (ms)
有這份文件:AI 自己知道 Payment Service 的 log 在哪個 index。
沒有這份文件:你每次都要說「去查 payment-production-access-log 這個 index」。
差別就是這樣。
不需要寫得很完整。有 vs 沒有,差距遠大於 80 分 vs 100 分。
先把最常調查的 5 個服務寫好,就能覆蓋 80% 的場景。
SRE 的 Prompt 工程,不是學怎麼寫漂亮的句子。
是把你腦中的調查經驗,變成 AI 能讀的文件。
四層架構:環境設定 → 調查 SOP → 服務文件 → 歷史案例。
最重要的第一步:寫你的 Investigation Cheat Sheet。
下次調查時,記下你的決策過程。10 次之後,你就有一份完整的調查 SOP。
知識系統建好了。但每次還要手動告訴 AI「去讀那個文件」。
下一篇,我們把這套知識系統封裝起來。
一句 /troubleshoot 就能啟動完整調查。