https://yennj12.js.org/yennj12_blog_V4/tags/ci/Recent content in CI on YennJ12 Engineering BlogHugo -- gohugo.ioen-usFri, 31 Jul 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/kubernetes-complete-guide-part3-advanced-zh/Sat, 11 Oct 2025 13:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/kubernetes-complete-guide-part3-advanced-zh/🎯 前言 經過前兩篇的學習，我們已經掌握了 Kubernetes 的基礎概念與核心資源操作。本文將深入探討進階功能與生產環境實踐，幫助你構建企業級的容器平台。 本文重點： 自動擴展（HPA/VPA/CA） RBAC 權限管理 Network Policy 網路策略 Helm 套件管理 監控與告警系統 日誌收集方案 CI/CD 整合 生產環境最佳實踐 ⚡ 自動擴展機制 擴展類型對照 graph TB A[Kubernetes 自動擴展] --> B[HPA<br/>水平 Pod 擴展] A --> C[VPA<br/>垂直 Pod 擴展] A --> D[CA<br/>叢集自動擴展] B --> B1[根據 CPU/記憶體<br/>自動調整 Pod 數量] C --> C1[根據資源使用<br/>調整 Pod 資源限制] D --> D1[根據負載<br/>自動增減節點] style A fill:#326ce5 style B fill:#4ecdc4 style C fill:#feca57 style D fill:#ff6b6b HPA (Horizontal Pod Autoscaler) 基於 CPU 的 HPA：https://yennj12.js.org/yennj12_blog_V4/posts/docker-complete-guide-part3-advanced-zh/Sat, 11 Oct 2025 11:30:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/docker-complete-guide-part3-advanced-zh/🎯 前言 經過前兩篇文章的學習，我們已經掌握了 Docker 的基礎概念與指令操作。本文將深入探討 Docker 的進階應用，涵蓋從開發到生產環境的完整實踐。 本文重點： Dockerfile 最佳實踐與優化 多階段建立（Multi-stage Build） Docker Compose 完整應用 網路進階配置 安全性強化 效能調優 生產環境部署策略 📝 Dockerfile 深度解析 Dockerfile 指令完整對照表 指令 作用 層級影響 範例 FROM 指定基礎映像 是 FROM node:18-alpine LABEL 添加元資料 否 LABEL version="1.0" RUN 執行指令 是 RUN npm install CMD 容器啟動指令 否 CMD ["npm", "start"] ENTRYPOINT 容器進入點 否 ENTRYPOINT ["python"] COPY 複製檔案 是 COPY app.py /app/ ADD 複製並解壓 是 ADD archive.tar.gz /app/ ENV 設定環境變數 否 ENV NODE_ENV=production ARG 建立時變數 否 ARG VERSION=1.https://yennj12.js.org/yennj12_blog_V4/posts/aio-geo-part4-implementation-zh/Fri, 31 Jul 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/aio-geo-part4-implementation-zh/大多數人的做法：讀完方法論，開一份 Notion 待辦，然後三個月後還在第一項。 真正該做的事：照著步驟做，每一步都有可執行的驗收指令。 這一篇不談概念。 全部是可以複製貼上的東西。 一、實作目標與驗收標準 我們要把一個典型網站從 Level 0/1 推到 Level 2（Part 1 §9 的成熟度模型）。 改造前 改造後 ────────────────────────────────────────────────────────────── AI crawler 部分 403 / 內容不完整 8 個 bot 全 200，內容完整 無 JS 內容量 瀏覽器的 20%（CSR） 瀏覽器的 98% 結構化資料 無 / 只有基本 Article Organization + Article + FAQPage + Breadcrumb，互相 @id 引用 chunk 邊界 靠段落換行 H2/H3 分節 + section id + 錨點 機器可讀版本 只有 HTML HTML + .md + llms.txt 可驗收 靠人工檢查 CI 自動化，PR 階段擋下退步 驗收腳本會在 §9 給出，可以直接放進 CI。建議先跳到 §9 跑一次，拿到基線，再回來逐步修。https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part36-eval-pipeline-zh/Fri, 05 Jun 2026 14:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part36-eval-pipeline-zh/Eval Pipeline 和 Eval 的差別： Eval 是你跑一次、拿到一個分數。 Eval Pipeline 是每次系統改變，自動跑、自動比較、自動擋住退化。 法律合約系統漏掉一個風險條款的損失可能是千萬。 靠人記得去跑評估，不夠。 面試情境 面試官：「客戶是一家法律事務所，剛上線了一個合約審查 AI 系統。他們問：每次你們更新 Prompt 或換模型版本，我怎麼知道品質沒有退化？法務長說，如果 AI 漏掉一個風險條款，損失可能是千萬。請設計一個讓客戶可以信任的 Eval Pipeline。」 一、核心問題：為什麼需要 Pipeline Eval（一次性）的問題： 現在的品質：Faithfulness = 0.87 ← 你知道 下週改了 Prompt 之後：? ← 你不知道 三個月後換了模型版本之後：? ← 你更不知道 沒有 Pipeline： 需要有人記得每次改動後去跑評估 → 沒人記得 → 品質退化不被發現 → 客戶先發現 有 Pipeline： 每次 Prompt / 模型 / 資料 變更 → 自動觸發評估 → 分數低於閾值 → 自動擋住部署 → 品質退化在影響用戶之前被系統發現 Eval Pipeline 是把「品質管控」從人工流程變成自動化系統。 這是 POC 到生產的核心差距之一。 二、Eval Pipeline 的四層架構 ┌───────────────────────────────────────────────────────────────────┐ │ Layer 1：黃金資料集（Ground Truth） │ │ 「正確答案是什麼」的標準，由領域專家建立 │ └──────────────────────────────┬────────────────────────────────────┘ │ 每次評估都用同一份資料集 ▼ ┌───────────────────────────────────────────────────────────────────┐ │ Layer 2：離線評估（Offline Eval） │ │ 每次部署前，對黃金資料集跑 RAGAS + Safety，產出指標報告 │ └──────────────────────────────┬────────────────────────────────────┘ │ 評估結果 vs 上一版 baseline ▼ ┌───────────────────────────────────────────────────────────────────┐ │ Layer 3：CI/CD 品質閘門（Quality Gate） │ │ 分數低於閾值 → 自動阻止部署；通過 → 繼續 Canary 部署 │ └──────────────────────────────┬────────────────────────────────────┘ │ 部署到生產後持續監控 ▼ ┌───────────────────────────────────────────────────────────────────┐ │ Layer 4：線上評估（Online Eval） │ │ 生產流量的持續品質監控，偵測 Data Drift 和 Performance Drift │ └───────────────────────────────────────────────────────────────────┘ 三、Layer 1：黃金資料集的設計原則 黃金資料集的每一筆記錄： { "id": "Q042", "query": "這份合約的違約金條款是否符合台灣民法第 250 條？", "context": ["第 3 頁段落.https://yennj12.js.org/yennj12_blog_V4/posts/ai-system-on-native-aws-part5-production-mlops-observability-zh/Wed, 22 Jul 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-system-on-native-aws-part5-production-mlops-observability-zh/大部分 AI 專案死在「demo 很成功、上線三個月後沒人敢動」。因為沒有人知道:模型現在準不準?這個月的 token 花了多少、花在誰身上?想更新模型會不會把線上搞掛?出錯了要去哪裡看? 「能跑」是原型,「敢上線、敢更新、出事查得到、花多少算得清」才是生產系統。這中間隔著的東西,叫 MLOps。 AWS 原生的好消息是:可觀測性、部署策略、成本治理這些「非功能」的東西,很多都是 managed service 免費附贈或一行設定就開——CloudWatch 收指標、X-Ray 追鏈路、Bedrock 呼叫日誌記每一次推論、SageMaker 藍綠部署零停機、Cost Allocation Tag 讓每個系統的花費一目了然。 這是 Part 5,也是整個系列的收束:把前四個「能跑」的系統,變成「敢上線」的系統。 一、情境與痛點:「能跑」到「敢上線」之間的鴻溝 回顧一下前四篇,我們蓋了四個 AI 系統:RAG 問答、IDP 管線、即時推薦、自主 Agent。每一個 cdk deploy 之後都能動。但「能動」的 demo 跟「敢放給幾十萬人用」的生產系統,中間隔著四個要命的問題: 問題 症狀 沒解決的下場 ────────────────────────────────────────────────────────────────────── ① 看不見 模型變笨了、延遲飆高了,沒人發現 客訴爆了才知道 ② 不敢改 想換個更好的模型,但怕改壞線上 系統凍結,技術債累積 ③ 算不清 這個月 AI 花了多少?哪個系統燒最兇? 帳單來了才心臟病 ④ 追不到 Agent 做錯決定 / RAG 答錯,查不出為什麼 無法歸因,無法改進 這四個問題,對應 MLOps 的四根支柱:可觀測性(看得見)、部署策略(敢改)、成本治理(算得清)、可追溯性(追得到)。這一篇就逐一拆解,並且用 CDK 把它們變成基礎設施的一部分——MLOps 不是上線後才補的東西,而是從第一天就 code 進 stack 裡。https://yennj12.js.org/yennj12_blog_V4/posts/mkdocs-site-size-deploy-perf-tuning-zh/Tue, 30 Jun 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/mkdocs-site-size-deploy-perf-tuning-zh/多數人優化靜態站台的做法：壓縮一下圖片、開個快取就收工。 但當站台是由 42 個機器人每天自動寫進去的 5,000 頁報告時，問題不在「檔案大」， 而在「整個 pipeline 的每個環節都在重複放大成本」——搜尋索引、導覽樹、git 歷史、部署觸發頻率。 真正的調校，是找出那些被無限複製的單位成本。 一、問題：一個會自己長大的站台 finance_data 是一個自動化金融分析站台。它的內容不是人手寫的，而是由大約 42 個每日排程任務自動產生：10-K / 10-Q / 13-F 財報摘要、investor day 筆記、AI 生成的個股報告、notebook PDF……每天都有新的 dated report 被寫進 repo，再透過 MkDocs（Material 主題）建置成靜態站台，部署到 GitHub Pages。 這種「機器人持續寫入」的特性，讓站台的成本不是線性增加，而是在好幾個環節同時被放大。等到我們去看的時候，數字已經很難看： 症狀 數字 ────────────────────────────────────────────── 搜尋索引 (search_index.json) 195 MB 首頁 HTML 1.07 MB 單一深層報告頁 HTML 590 KB 單次部署 payload 752 MB 建置完成的站台總大小 ~3.1 GB CI 建置 + 部署時間 ~15 分鐘 每天觸發部署次數 ~42 次（每個分析任務 push 一次） 最致命的不是任何單一數字，而是它們互相加乘：5,000 頁 × 每頁 1MB 的導覽樹 = 站台爆炸；42 次/天 × 752MB 的部署 = CI 排隊塞車。我們要做的，是逐一拆掉這些放大器。https://yennj12.js.org/yennj12_blog_V4/posts/harness-engineering-intro-ai-zh/Sat, 11 Apr 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/harness-engineering-intro-ai-zh/深入探討 Harness 在 AI 時代的角色，從基本概念、核心功能到實戰應用，幫助工程團隊建立高效的自動化部署流程，加速 AI 應用的上線速度。