嗨大家，我是 Debuguy。

昨天我們成功讓 Bot 能用自然語言查 K8s 資源，從查 Log 到查 Metrics 再到查 Pod 狀態，已經可以做完整的問題診斷了。但今天要來聊一個更直接的痛點：當警報響起時，你怎麼知道影響有多嚴重？

凌晨的第一個問題：到底多嚴重？

值班工程師的兩難

📱 凌晨 2:47
🚨 [CRITICAL] API Error Rate Spike
Production API 錯誤率異常上升

@on-call-engineer

收到警報的當下，腦中第一個問題是：

「需要馬上叫醒其他人嗎？」

這取決於影響範圍：

• 如果只是某個邊緣功能掛了：自己處理，明天再說
• 如果是核心功能炸了：立刻 escalate，叫醒整個團隊

判斷影響範圍的標準流程

對於後端服務：

1. 查看 Metrics（哪些 endpoint 受影響）
2. 檢查 Logs（錯誤的具體內容）
3. 確認 K8s 資源狀態（Pod 有沒有掛）

對於面向用戶的服務（Web/App）：

1. 打開瀏覽器
2. 手動點擊各個功能
3. 確認哪些能用、哪些不能用
4. 判斷是否需要發公告

「為什麼不能自動化？因為你需要『親眼看到』影響範圍...」

昨天的 kubectl-ai 解決了後端的問題，但對於需要視覺確認的場景，就需要 Playwright MCP 了。

Playwright MCP 的定位：維運的眼睛

為什麼需要 Playwright？

🚨 支付服務錯誤率上升

需要確認：
- 首頁是否正常？
- 商品頁能不能瀏覽？
- 購物車功能有問題嗎？
- 結帳流程在哪個步驟卡住？

這些問題，光看 Log 和 Metrics 是不夠的，你需要像用戶一樣操作一遍。

Playwright MCP vs kubectl-ai

它們是互補的：

• kubectl-ai 告訴你「系統狀態」
• Playwright MCP 告訴你「用戶看到什麼」

實作：接入 Playwright MCP

Step 1: 啟動 MCP Server（streamable-http 模式）

在 docker-compose.yml 中加入 Playwright MCP 服務：

services:
  # ... 其他服務
  
  playwright-mcp:
    image: mcr.microsoft.com/playwright/mcp
    container_name: playwright-mcp
    ports:
      - "8931:8931"
    restart: always

Step 2: 註冊到 MCP 配置

更新 config/mcp-config.json：

{
  "mcpServers": {
    "playwright": {
      "type": "streamable-http",
      "url": "http://playwright-mcp:8931/mcp"
    },
    "elasticsearch": {
      "type": "streamable-http",
      "url": "http://elasticsearch-mcp:8080/mcp"
    },
    "grafana": {
      "type": "streamable-http", 
      "url": "http://grafana-mcp:8000/mcp"
    },
    "kubectl-ai": {
      "type": "streamable-http",
      "url": "http://kubectl-ai-mcp:9080/mcp"
    }
  }
}

Step 3: 測試服務

啟動服務：

docker-compose up -d playwright-mcp

現在可以在 Slack 中測試：

@debuguy_bot 幫我檢查 https://example.com 現在是否正常

核心問題：LLM 幻覺

Playwright MCP 有個致命問題：LLM 會幻覺。

實際遇到的案例：

工程師: @bot 檢查 staging 環境

Bot: ✅ Staging 環境運作正常！
     - 首頁載入成功
     - 登入功能正常
     - 所有 API 都正常回應

工程師: *半信半疑打開瀏覽器*
現實: 整個網站 503 Service Unavailable

「從那次之後，我就不再相信沒有截圖證據的回報...」

LLM 為什麼會騙人？

1. 工具執行失敗，但 LLM 不知道

   • Playwright timeout 了
   • 但 LLM 以為「沒錯誤 = 成功」

2. LLM 會根據上下文推測

   • 「通常這個網站都正常」
   • 「沒看到明顯錯誤，應該沒事」

3. 錯誤訊息被「潤色」

   • Playwright 回傳一堆 error stack
   • LLM 美化成「遇到一些小問題」

結論：沒有截圖 = 不可信

System Prompt：強制截圖證據

在 chatbot.prompt 中加入規則

# prompts/chatbot.prompt
---
model: gemini-2.5-flash
config:
  temperature: 0.7
---

# ... 其他 instructions

## Playwright MCP Usage for Service Verification

When using Playwright to check service status or verify user-facing applications:

### MANDATORY SCREENSHOT RULE
**Every Playwright check MUST include screenshot evidence.**

- ALWAYS `screenshot` after navigation
- ALWAYS attach the screenshot in your response
- NEVER claim "checked successfully" without screenshot proof
- If screenshot fails, explicitly report the failure

### Response Format
When reporting service status, use this structure:

**Service Status Check: [URL]**

Status: [✅ Normal / ⚠️ Partial Issue / 🚨 Critical]

**Screenshot Evidence:**
[attached screenshot]

為什麼這樣設計？

1. 強制證據：
沒有截圖就不准說「檢查完成」

2. 結構化輸出：
讓工程師快速掃描重點

3. 視覺驗證：
工程師用自己的眼睛判斷，不盲目信任 AI

4. 明確錯誤處理：
失敗就說失敗，不要含糊其辭

實際使用場景

場景一：警報觸發後的影響確認

觸發：

🚨 [CRITICAL] API Error Rate > 10%
Production 環境異常

@on-call @debuguy_bot

Bot 自動檢查：

@debuguy_bot 檢查 https://app.example.com 的影響範圍

Bot 思考中...
> 我需要確認不同功能的狀態
> 首先檢查首頁...
> 接著測試登入功能...
> 最後檢查核心功能...

**Service Status Check: https://app.example.com**

**首頁：✅ 正常**
[首頁截圖]
- 頁面正常載入
- 導覽列顯示正常
- 無明顯錯誤

**登入頁：🚨 異常**
[登入頁截圖]
- 顯示 "500 Internal Server Error"
- 登入按鈕無法使用
- 錯誤訊息：Authentication service unavailable

場景二：定期健康檢查

不用等警報，主動監控：

# 用 cron 或排程工具定期執行
curl -X POST https://slack.com/api/chat.postMessage \
  -d "channel=ops-monitoring" \
  -d "text=@debuguy_bot 執行每小時健康檢查：檢查所有 production 服務"

Bot 會自動巡邏各個服務，發現問題立刻回報（附截圖）。

成本與效益

額外的成本

執行時間：

• 每次網頁檢查：30-60 秒（含截圖）
• 比純文字慢，但換來視覺證據

Token 成本：

• 每張截圖約 1500-2500 tokens
• 圖片作為 context 會增加 token 消耗

帶來的價值

時間節省：

• 人工確認影響範圍：10-15 分鐘
• Bot 自動檢查：2-3 分鐲
• 節省 70-80% 的時間

降低心理負擔：

• 半夜被叫醒時，有初步分析可以依據
• 不用在半夢半醒中判斷要不要 escalate

提升決策品質：

• 有視覺證據，不會誤判嚴重程度
• 減少不必要的 escalate（節省團隊睡眠）
• 減少漏報（真有問題時不會輕忽）

建立信任：

• 截圖證據 = 可信度 100%
• 工程師願意依賴 Bot 的判斷

ROI 計算：多花幾秒和一些 token，換來 10 分鐘的時間節省和完整的信任度。

傳統 E2E vs AI 驅動的 E2E：應對不可預測性

為什麼不直接寫 Playwright 腳本？

核心差異：可預測性

真實問題：後台設定的黑箱

生產環境的殘酷真相：

很多東西是後台就能設定觸發的，完全不需要改 code：

• 行銷團隊在 CMS 後台加促銷彈窗（雙十國慶優惠）
• PM 在後台開啟新功能導覽
• 客服主管開啟 Intercom 聊天機器人
• 營運團隊設定 A/B Testing 實驗
• 第三方廣告系統自動投放內容

沒有人會通知工程團隊，也不需要。

實際案例

10/9 晚上 23:59：

• 監控腳本運作正常 ✅

10/10 凌晨 00:01：

• 行銷在後台排程的國慶彈窗自動上線
• 監控腳本全部失敗 ❌（被彈窗擋住）
• On-call 工程師被叫醒

傳統腳本的困境

// 腳本是靜態的
await page.click('#login-button');

// 但頁面是動態的
// - 今天可能有國慶彈窗擋住
// - 明天可能有客服聊天彈出
// - 後天 PM 開了新功能導覽
// 根本無法預測

AI 的優勢：理解而非記憶

AI 不是靠 selector，而是靠理解：

Bot 思考中...
> 看到一個「雙十國慶優惠」彈窗
> 判斷：這不是我要找的登入功能
> 找到關閉按鈕 → 點擊
> 繼續找登入按鈕 → 完成

不需要預先知道會有什麼彈窗，也不需要知道 selector。

技術選擇建議

傳統腳本：

• ✅ CI/CD 中的回歸測試（環境可控，可 toggle off 一些 feature）
• ✅ Staging 環境監控（沒有動態內容）

AI 驅動：

• ✅ Production 環境檢查（充滿後台設定的動態內容）
• ✅ 警報觸發時的影響確認（不知道頁面長怎樣）
• ✅ 整合第三方服務的場景（行為不可控）

關鍵：當你無法預測頁面會長怎樣時，AI 的價值就出現了。

小結

Day 28 我們完成了維運工具鏈的最後一塊拼圖：

技術整合：

• ✅ Playwright MCP（streamable-http）
• ✅ 強制截圖證據機制
• ✅ 結構化的檢查流程

實用價值：

• ✅ 快速確認面向用戶服務的影響範圍
• ✅ 視覺證據建立信任
• ✅ 結合其他工具做完整診斷
• ✅ 降低值班工程師的心理負擔

設計哲學：

• ✅ 眼見為憑：截圖優於描述
• ✅ 避免幻覺：限制 LLM 的「創造力」
• ✅ 輔助判斷：AI 提供證據，人類做決策

現在當凌晨警報響起時，Bot 已經幫你做完了：

1. 🖥️ 確認用戶看到的影響（Playwright + 截圖）
2. 📊 檢查監控指標（Grafana）
3. 📝 查詢錯誤日誌（Elasticsearch）
4. 🎯 檢查資源狀態（kubectl-ai）

你只需要根據這些證據，決定下一步行動。

從 Day 21 的 Grafana Alert 自動分析，到 Day 27 的 kubectl-ai 整合，再到今天的 Playwright 視覺驗證，我們建立了一個完整的 AI DevOps Squad。

完整的原始碼在這裡

AI 的發展變化很快，目前這個想法以及專案也還在實驗中。但也許透過這個過程大家可以有一些經驗和想法互相交流，歡迎大家追蹤這個系列。

也歡迎追蹤我的 Threads @debuguy.dev