https://yennj12.js.org/yennj12_blog_V4/tags/troubleshooting/Recent content in Troubleshooting on YennJ12 Engineering BlogHugo -- gohugo.ioen-usMon, 08 Jun 2026 11:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/kubernetes-autoscaling-complete-guide-part7-troubleshooting-war-stories/Mon, 10 Nov 2025 00:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/kubernetes-autoscaling-complete-guide-part7-troubleshooting-war-stories/Part 7 of the Kubernetes Autoscaling series: Real-world production incidents, debugging workflows, common failure scenarios, and hard-learned lessons from operating autoscaling at scale. Battle-tested troubleshooting guides and postmortem analysis.https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part11-agent-debugging-zh/Wed, 03 Jun 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part11-agent-debugging-zh/Agent debugging 和傳統程式 debug 的本質差異： 傳統程式出錯，你找 stack trace。 Agent 出錯，LLM 的「決策過程」是不透明的——你找不到 stack trace。 所以你必須在設計時就把觀測能力建進去，而不是出問題後再想怎麼查。 一、核心問題：為什麼 Agent 難 debug 傳統程式： Input → [確定性邏輯] → Output ↑ 出錯有 stack trace Agent： Input → [LLM 決策] → [Tool Call] → [LLM 決策] → ... → Output ↑ ↑ 決策過程不透明 中間狀態沒有自動記錄 三個讓 Agent debugging 特別難的原因： 非確定性：同樣的 input 可能產生不同的執行路徑 多步驟：一個錯誤可能在步驟 1 發生，但直到步驟 8 才顯現 工具依賴：問題可能在 LLM 層、工具層、還是 data 層——不好定位 二、系統全貌：觀測性架構 解決思路：在 Agent 的每個關鍵節點插入觀測點。 用戶請求 │ ▼ ┌──────────────────────────────────────────┐ │ Agent Execution │ │ │ │ ┌─────────┐ ┌──────────────────┐ │ │ │ LLM │ │ Tool Gateway │ │ │ │ │ ←→ │ (instrumented) │ │ │ └─────────┘ └──────────────────┘ │ │ │ │ │ │ ▼ ▼ │ │ ┌──────────────────────────────────┐ │ │ │ Trace Collector │ │ │ │ 每一步的 thought/action/result │ │ │ └──────────────────────────────────┘ │ └──────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────┐ │ Observability Stack │ │ │ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │ │ Metrics │ │ Traces │ │ Logs │ │ │ │ (Grafana)│ │(Langfuse)│ │(Cloud │ │ │ │ │ │ │ │ Logging) │ │ │ └──────────┘ └──────────┘ └──────────┘ │ │ │ │ │ │ │ ▼ ▼ ▼ │ │ 系統健康狀態 單次請求路徑 詳細事件記錄 │ └─────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────┐ │ Alerting Layer │ │ threshold breach → PagerDuty / Slack alert │ └─────────────────────────────────────────────┘ 三、觀測性三層：各層收集什麼 Layer 1：Metrics（系統健康） 關鍵指標 Dashboard： 延遲 成本 品質 ───────────── ────────────── ────────────── TTFT p50: 450ms input tokens/req: 2500 loop_rate: 0.https://yennj12.js.org/yennj12_blog_V4/posts/fde-core-concept-22-structured-troubleshooting-zh/Mon, 08 Jun 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-core-concept-22-structured-troubleshooting-zh/核心定義：Structured Troubleshooting 是一種「永不猜測、逐層消除」的診斷哲學——從用戶可見的症狀出發，沿著系統堆疊自上而下，在每一層用可量測的指標排除假說，直到根因被隔離為止。 一、為什麼面試官問這個 面試官測試的不是你背了多少 Cloud 工具名稱，而是你在凌晨三點 PagerDuty 響起時思考的順序是否可預測、可重複、可教給初級工程師。 測試診斷紀律：弱答案是「我會先看 logs」或「我會重啟服務」——沒有層次、沒有假說優先順序、沒有消除邏輯。強答案明確說出「Layer 4 quota 佔 80% 的 Agent 慢案例，我的第一個動作是打開 Vertex AI quota dashboard 看 TPM 消耗曲線，而不是翻 application log」。這句話背後是數據，不是直覺。 測試可觀測性設計意識：面試官想知道你是否在架構設計時就預埋了排錯所需的 trace / metric / log，而不是等到出事才臨時加 print()。可觀測性是一個設計決策，需要在 Day 1 就被納入 API 規格、tool wrapper 合約、和部署 checklist。 測試成本意識：每一層的排錯工具有不同的費用曲線（Cloud Trace ingestion $0.20/百萬 spans、外部 HTTP check 每分鐘觸發一次約 $0.01/check/月）。強候選人知道在什麼層次停下來，不做過度觀測，也知道哪些 error path 值得 100% 採樣。 弱回答：「我會看 error logs，然後試著在本地重現問題。」 強回答：「我先確認 TTFT 是否超過 3 秒的 SLO 閾值。如果是，立刻拉 Vertex AI quota dashboard 看 TPM 消耗曲線——因為 80% 的 slow-agent 案例根因在 Layer 4 quota 耗盡。確認 quota 正常後，我才打開 Cloud Trace，找哪個 tool call span 攜帶 status_code=429 或 latency_ms > 3000，這樣平均 15 分鐘內可以隔離根因。」https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part41-troubleshooting-zh/Mon, 08 Jun 2026 11:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part41-troubleshooting-zh/「AI 系統出問題了」不是問題描述，是症狀描述。 在沒有找到根因之前，任何修復都是猜測。 結構化的故障排查不是把所有可能都試一遍， 而是用最少的資訊快速縮小到一個節點。 面試情境 面試官：「你們的 AI 客服系統，今天早上 9 點開始，客戶回報：系統變慢了，有時候會給出奇怪的答案。你不在現場，只能遠端處理。請一步一步說明你的排查思路，以及你平時會怎麼設計可觀測性來讓這類問題更快被找到。」 一、AI 系統故障排查的特殊性 傳統系統 vs AI 系統的故障特性對比： 維度 傳統系統 AI 系統 ────────────────────────────────────────────────────────────── 確定性 相同輸入 = 相同輸出 LLM 輸出有隨機性，問題可能間歇出現 錯誤信號 明確 Error Code（500/404） 品質問題沒有 Error Code，只有「感覺不對」 根因數量 通常在代碼或配置 分佈在：模型、Retrieval、Tool、基礎設施 「正確」定義 有明確的正確答案 需要評估，不是二元對錯 ────────────────────────────────────────────────────────────── 最重要的 AI 特有洞察： ┌──────────────────────────────────────────────────────────────┐ │ Retrieval 失敗 → 「奇怪的答案」 │ │ │ │ Vector Search 返回 0 個結果 │ │ ↓ │ │ LLM Context 是空的 │ │ ↓ │ │ LLM 沒有 Context，靠「自己的知識」猜測 │ │ ↓ │ │ 症狀：「答非所問」「答案不基於我們的資料」 │ │ Error Log：沒有任何錯誤 ← 這就是難以發現的原因 │ │ │ │ 只有 Trace 才能發現： │ │ vector_search Span → result_count=0（返回 0 結果） │ └──────────────────────────────────────────────────────────────┘ 三個常見的排查誤區： 誤區 1：「LLM 模型一定有問題」 → 不一定。延遲問題通常是基礎設施；品質問題可能是 Retrieval 失敗 誤區 2：「昨天還好，一定是昨晚的部署造成的」 → 不一定。流量模式改變（如特定類型查詢增多）也能觸發潛在問題 誤區 3：「重啟一下試試」 → 可能暫時緩解（Cold Start 問題除外），但根因沒找到必定再發 二、三個可觀測性成熟度階段 ╔══════════════════════════════════════════════════════════════╗ ║ Phase 1：基礎可觀測性（POC / 初期上線） ║ ║ 「能知道系統壞了」 ║ ╚══════════════════════════════════════════════════════════════╝ 元件： ├── 結構化日誌（JSON 格式，帶 timestamp、level、service 欄位） ├── 基本 Metrics（Error Rate、P50 Latency、Uptime） └── 簡單 Alert（Error Rate > 5% → 發 Email） 能解決的問題： ├── 「系統是不是掛了？」（Uptime 告警） └── 「有沒有大量錯誤？」（Error Rate 告警） 無法解決的問題： ├── 「哪個 Step 慢？」（沒有 Trace） └── 「品質退化了嗎？」（沒有 Eval 指標） ╔══════════════════════════════════════════════════════════════╗ ║ Phase 2：生產級可觀測性（正式上線後） ║ ║ 「能知道系統為什麼慢，慢在哪裡」 ║ ╚══════════════════════════════════════════════════════════════╝ 新增元件（在 Phase 1 基礎上）： ├── Distributed Tracing（OTel + Cloud Trace） │ 每個 LLM 呼叫、Tool 呼叫、Vector Search 都有獨立 Span ├── 完整 Metrics 儀表板 │ P50/P95/P99 延遲、Token 消耗趨勢、快取命中率、Error Rate by type ├── 告警精細化 │ P95 > 5s 持續 5 分鐘 → PagerDuty │ Error Rate > 1% 持續 2 分鐘 → Slack └── 日誌結構化增強（加入 trace_id，可與 Trace 關聯） 能解決的問題： ├── 「哪個 Span 是延遲瓶頸？」（瀑布圖） ├── 「哪個 Tool 最常失敗？」（tool.