https://yennj12.js.org/yennj12_blog_V4/tags/sre/Recent content in SRE on YennJ12 Engineering BlogHugo -- gohugo.ioen-usMon, 08 Jun 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-agent-team-for-consultant-part3-devops-zh/Thu, 30 Apr 2026 11:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-agent-team-for-consultant-part3-devops-zh/前言 你已經建好了 AI 顧問 Agent 團隊（第一篇、第二篇），現在問題來了： 「這系統真的有在正常工作嗎？品質夠好嗎？出了問題怎麼辦？」 AI Agent 系統不像傳統軟體，你不能只看 HTTP 200。你需要評估輸出品質、追蹤推理過程、並且在 LLM 開始說廢話之前就發現它。 本篇從 DevOps/SRE 的角度，完整說明如何讓 AI 顧問團隊穩定、可觀測、持續進化。 一、系統效能評估：怎麼知道 Agent 表現好不好？ 1.1 評估的四個維度 品質（Quality） → 輸出內容是否正確、有用、符合顧問標準 速度（Latency） → 每個 Agent 節點的回應時間 成本（Cost） → 每次顧問對話的 Token 花費 可靠性（Reliability）→ 成功完成整個流程的比率 1.2 建立評估資料集（Golden Dataset） 這是最重要的第一步。準備 20-50 個有代表性的客戶案例： 1# evaluation/golden_dataset.py 2GOLDEN_CASES = [ 3 { 4 "id": "case-001", 5 "input": "我們是一家 50 人的電商公司，客服每天要處理 500 封郵件，想用 AI 減輕負擔。", 6 "expected_intake": { 7 "industry": "電商", 8 "size": "50人", 9 "pain_points": ["客服郵件量大"], 10 "ai_type": "自動化" 11 }, 12 "expected_strategy_keywords": ["聊天機器人", "郵件分類", "自動回覆"], 13 "quality_rubric": { 14 "relevance": "策略必須針對客服場景", 15 "feasibility": "建議的方案在 100 萬預算內可行", 16 "actionability": "至少有 3 個具體的下一步行動" 17 } 18 }, 19 # .https://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-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 分鐘內可以隔離根因。」