Autocruise

過往使用 Google Cloud 遇到問題時的流程是：先搜尋 Google Cloud Documentation，讀完文件、理解產品行為與限制，再自己轉換成 gcloud、kubectl 或 Terraform 指令，最後執行與驗證。這套模式存在了很多年。但隨著 Codex、Claude Code、Gemini CLI 等 Coding Agent 真正進入工程師的 Terminal，一個新的問題逐漸浮現： 如果實際操作 Cloud Infrastructure 的不只工程師，也包含 AI Agent，那麼官方文件是不是也需要一種「給 Agent 使用的版本」？ (本文含聯盟連結。As an Amazon Associate I earn from qualifying purchases.) Google 在 Cloud Next 2026 推出的官方 Agent Skills repository： Google Skills （ github.com/google/skills ），正是在回答這個問題。Google 把 Skill 定義為一種為 Agent 提供額外能力與專業知識的開放格式，也把它描述成針對特定技術或任務設計的 agent-first documentation 。 換句話說， 它不是把 Google Cloud Documentation 再複製一次，而是把產品知識重新整理成 AI Agent 可以理解、判斷，並在適當時機使用的操作知識。 （一）從 13 個 Skills 開始 Google Skills 在 2026 年 4 月 Cloud Next 發表時，規模並不大。第一批只有 13 個 Skills： 產品類：AlloyDB、BigQuery、Cloud Run、Cloud SQL、Firebase、Gemini API、Google Kubernetes Engine（GKE） Well-Architected 類：Security、Reliability、Cost Optimization Recipe 類：Google Cloud Onboarding、Authentication、Network Observability Google 當時就表示這個 repository 會持...

當新的版本服務要上 production 生產環境時，最直覺的做法就是把所有流量一次全部切過去上線，這是時常看到的，這種做法如果順利的話那就皆大歡喜（實際上不太可能），但只要新版本藏了一個沒測到的 critical bug，等於讓 100% 的使用者同時出問題。這種「一次全量發布」在生產環境裡最省事、卻也最危險，在短期快速迭代開發下很難有 100% 沒有任何缺陷的軟體應用服務，但現在還是時常看到不少企業在做這樣的事情。實際上為了控制這個風險，software engineering 圈子早已發展出「灰度發布」這個概念，底下可細分出 Canary Rollout、藍綠部署(Blue-Green Deployment)、A/B Testing、Feature Flag 幾種做法，但這幾個詞常常被混著用、甚至誤用。這系列文章會先在第一篇把名詞和框架釐清，後面幾篇再針對 AWS EKS + Kubernetes 的具體實作、以及 Web 通訊 App（含 WebSocket 長連線、Android/iOS 行動端）的灰度發布細節展開。在往下讀名詞定義之前，先介紹這系列文章會用的範例情境，方便對照後面出現的程式碼與設定。 本系列的範例情境 這系列文章會用一套虛構的雲端 Web 通訊 App (姑且稱它 ChatApp) 當作貫穿全系列的範例，情境設定盡量貼近實際專案常見的架構，方便對照後面出現的程式碼與設定檔。 ChatApp 提供三種客戶端，使用者可以自由選擇任一種登入使用： iOS App （原生 Swift） Android App （原生 Kotlin） 網頁版 （瀏覽器直接使用的 Web App） 三種客戶端底層都呼叫同一組後端 API，後端部署在 AWS EKS（Kubernetes）上，由幾個主要模組組成： Gateway / Ingress 層 ：對外的統一入口，也是本文提到的 Canary 流量分流實際作用的地方 訊息服務（Message Service） ：處理聊天訊息的收發，跟客戶端之間走 WebSocket 長連線 認證服務（Auth Service） ：處理登入、身分驗證 資料庫（Database） ：儲存使用者資料與歷史訊息記錄 後面所有的範例（包含 chatapp-v1 / chatapp-v2 、 ...

無意中看到整合 AI Agent 的 PaaS 平台爆發資安事件：攻擊者從一把雲端管理憑證出發,一路打穿到主資料庫,把所有租戶存在環境變數裡的第三方金鑰整批查出來、匯出去。問題的根源不是「被駭」這件事本身,而是架構設計把太多信任集中在同一個地方，環境變數欄位是整個平台唯一的機密儲存層,一次控制平面層級的入侵,就足以讓所有租戶的金鑰在同一時間曝險。由此有一些想法，寫了這篇技術文章探討金鑰該如何儲存。 (一) 從攻擊鏈看金鑰為什麼能走這麼遠 該平台官方在事故發生後陸續更新的攻擊鏈,是這起事件最值得拆解的部分:攻擊者取得一把 AWS 管理層級的憑證,先進入東京的一個共用叢集,再從叢集摸到控制平面的 VPN,最後連上主資料庫,把使用者存在環境變數裡的金鑰查出來、匯出去。時間軸上,平台在 8 月 28 日凌晨建立事故頁,一開始只說是「內部服務憑證」被用來查詢環境變數紀錄;直到隔天晚間,才更新出「AWS 管理憑證 → 共用叢集 → 控制平面 VPN → 主資料庫」這條完整路徑。 如果那把 AWS 憑證的有效權限,本身就同時涵蓋叢集存取、VPN 素材、資料庫連線——那麼圖面上的四個箭頭,實際上可能從頭到尾只被同一個身分牽著走,中間沒有一關是「前一個身分拿不到、簽不出、也改不掉」的獨立授權。 要驗證一組雲端身分的真實影響範圍,不能只看掛了哪些 policy 名稱,而要直接查它的 effective permissions: aws accessanalyzer list-findings \ --analyzer-arn <analyzer-arn> \ --filter '{"resource":{"contains":["<role-or-user-arn>"]}}' 這個指令會列出該身分實際可觸及的資源, 找出哪些資源被過度開放給外部身分, 而不是政策文件上「看起來」授權了什麼——這正是重建這類事故攻擊面時,第一件該做的事。 (二) 問題不在用環境變數,而在把它當成信任根 環境變數本身不是問題。幾乎所有 PaaS——Heroku、Render、Vercel 等——都用環境變數當作應用程式讀取設定的方式,這是產業慣例,沒有問題。真正的問...

AI coding agent 在過去兩年間，從輔助工具演變為軟體開發生命週期中的主要生產力來源，也讓 AI 支出從可預測的授權費用，轉變為隨用量複合成長的變動成本。Token 計費模式沒有天然的用量上限——工程師平行執行多個 agent、對整個 codebase 進行重構、或把重複性作業自動化，都會讓消耗量隨活躍度倍增。這個轉變，正把「AI 支出治理」推成一個新的工程管理課題。 Uber Engineering 在 2026 年 8 月發布的〈Running a Software Factory Efficiently at Uber Scale〉，公開了該公司如何在用量快速擴張的同時壓低單位成本。根據該文披露，從 2 月到 8 月中，全公司 agentic 功能的週活躍用戶成長 7 倍，agent 請求量成長 9。4 倍;若把模型版本固定下來比較，每千次請求的成本從高峰下降約 34%，每個 session 的成本從 6 月高峰下降 52%。 若拉開一層來看，這套框架並不是全新的方法論，而是把 SRE 領域行之有年的容量規劃與 error budget 治理，搬進了 AI agent 這個新的資源類型。過去容量規劃談的是運算資源與流量成長的關係，error budget 談的是可用性與變更速度的平衡;Uber 這篇文章處理的問題結構完全相同，只是把「運算資源」換成了「token」、把「可用性」換成了「單位成本」。理解這層對應關係，有助於判斷哪些做法是換皮的舊經驗，哪些才是 AI agent 帶來的新變數。以下先整理該文揭露的治理框架，再回頭對照這層關係。 分層治理模型:掌控力隨專用程度遞增 該文將公司內的 agent 使用場景分為四層，由最泛用到最受管理。層級愈高、愈受管理，團隊對成本、輸出品質與模型選擇的掌控力也愈強。互動式的個人 coding session 屬於最泛用的一層，routing 與模型選擇多半由工程師臨時決定;相對地，把工作交給「受管理的 agent」(例如自動 code review、CI 失敗自我修復、on-call alert 分診)，則讓平台方能統一決定模型版本與執行環境。該文將此描述為核心策略轉向——從優化個別終端 session，轉向優化一支專門化的 managed agent 艦隊。 成本方程式:六個變數，三個...

Dockerfile 看似簡單，幾行 FROM、RUN、COPY 就能把應用打包成 image，但寫得好不好，直接牽動 build 速度、image 大小、安全性與日後的可維護性。本文整理幾個實務中最常用、卻也最常被忽略的 Dockerfile 撰寫訣竅。 （一）善用 layer cache　，　指令由　變動較少　排到　容易變化　（由上到下） Docker build 是逐層（layer）快取的,只要某一層的指令或內容改變,該層之後的所有 layer 都會失效重建。因此在Dockerfile內容中，指令順序（由上到下）應該從「變動頻率低」排到「變動頻率高」。最典型的例子，是先複製相依清單、安裝套件，最後才複製原始碼： # 先處理相依,讓 cache 命中率最大化 COPY package.json package-lock.json ./ RUN npm ci COPY . . 如此一來,只要原始碼變動、相依沒變, npm ci 這一層就能命中 cache,不必重跑。 （二）用 multi-stage build 縮小 image 把「編譯環境」與「執行環境」分開，只把最終產物帶進 runtime image，可大幅縮小體積，也降低受攻擊面（attack surface）: FROM golang:1.22 AS builder WORKDIR /app COPY . . RUN go build -o server . FROM alpine:3.20 COPY --from=builder /app/server /server ENTRYPOINT ["/server"] runtime image 不再包含 compiler 與原始碼,從數百 MB 降到數十 MB 是常態。 （三）合併 RUN 並在同一層清理 cache 每一個 RUN 都是一層。把相關指令用 && 串接成一層,並在同一層清掉套件快取,避免多餘體積殘留在 image 裡: RUN apk add --no-cache curl \ && rm -rf /var/cache/apk/* Debian/Ubuntu 則常見 apt-get install 之後接 rm -rf /var/l...

導讀摘要： 在企業管理會議上，「這個 SRE 專案什麼時候結束？」是財務長與執行長最常提出、也最容易誤導決策的問題。它反映了一種常見的認知失調——用「專案（Project）」的靜態思維，去管理一項本質上動態、連續、持續對抗系統熵增的工程實踐。本文從三個層面展開分析：為什麼傳統專案管理難以有效衡量 SRE、SRE 真正的核心價值何在、以及在沒有明確截止日期的前提下應如何評估其 ROI 並控制成本。核心觀點是：衡量 SRE 的正確標準，不是「何時完成」，而是「自動化的程度是否讓人力成本的成長率低於業務成長率」。 一、問題的起點：一個常被問錯的問題 當年度規劃討論到 SRE 或 DevOps 團隊時，最常出現的質疑往往是：「這個專案什麼時候會結束？既然沒有完工日，預算要如何控制？是否要無止盡地投入人力與軟體授權費用？」 這是一個合理、卻建立在錯誤前提上的問題。傳統的 IT 管理習慣以專案思維運作——明確的範圍、時間、預算與截止日期（Deadline）——藉此控管風險。然而，SRE 的本質是對抗複雜系統中的熵增（Entropy）與規模化挑戰，這是一個持續進行的過程，而非一次性的交付任務。 問題的根源不在 SRE，而在管理範式（Paradigm）的錯配。以靜態的專案框架衡量動態的維運工作，不僅難以正確評估績效，也容易導致資源錯置。要化解這個誤判，需要先釐清三件事：專案管理為何在此失效、SRE 的價值究竟該如何定義、以及該用什麼機制取代「截止日期」來控制成本。 二、為什麼傳統專案管理難以衡量 SRE？ 軟體服務與建築工程有本質差異。建築物完工後，維護成本相對低廉且可預測；軟體服務則不同——只要業務在成長、流量在增加、新功能在發布，維運的複雜度就會持續上升。 若以「專案結案」的方式管理 SRE，通常會導向兩種結果。其一是 專案永遠無法結案 ：由於系統的熵增不會停止，管理者容易因看不到終點而誤判團隊效率低落。其二是 強制結案、撤出人力 ：系統隨後因缺乏維護而逐漸劣化，最終造成遠大於節省成本的商業損失。 兩種結果指向同一個結論：SRE 並非一個「有終點的導入計畫」，而是一種「持續運作的能力」。為它設定完工日，就如同為消防體系設定解散日——問題不在於效率，而在於這個提問的框架本身並不成立。承認這一點，是後續一...

2026 年六月起，「Loop Engineering」成了討論度很高的一個詞。它的核心主張是：不要再一句一句去指揮 AI agent，而是設計一個能自己運作的迴圈，讓系統替你下指令。這個想法很誘人，但也帶來疑問：它跟我們已經在用的東西有什麼不同？什麼時候該用？會不會出問題？ 這篇文章想換一個角度來看這件事。如果我們把 Loop Engineering 放回「控制迴圈（control loop）」這個更老、也更成熟的脈絡裡，前面那些疑問會清楚不少。控制迴圈是 SRE 與自動化領域用了很多年的概念，它累積下來的一些經驗，剛好可以回答 Loop Engineering 現在還沒講清楚的問題。本文的目的不是重述一次「Loop Engineering 是什麼」，（這類介紹網路上已經很多了），而是透過 SRE 的角度來說明，並用它來想清楚幾個實務上真正重要的問題。 一、Loop Engineering 本質 Google Cloud 的 Addy Osmani 在他那篇被廣泛引用的長文裡，把 Loop Engineering 定義為「把負責下指令的那個人，從你自己換成一套你設計好的系統」。在過去 Prompt Engineering 的模式下，開發者跟 AI 是一來一往的：你提需求、AI 產出、你看完再給下一個指令，人始終是流程的控制者。Loop Engineering 想做的，是把這個控制的角色交給一個迴圈：它會自動發現工作、指派任務、驗證結果、記錄狀態，再決定下一步。實作上它由幾個元素組成：Automation、工作區隔離 Worktree、Skills、Connector、Sub-Agent，以及 State Memory。 這裡有個容易被熱潮蓋過的事實值得先說：這並不是一個全新發明。Anthropic 在 2024 年的《Building Effective Agents》裡，就已經描述過 Evaluator-Optimizer（一個模型產出、另一個模型批判修正）與 Orchestrator-Workers（主代理分派工作給子代理）這類架構，它們本質上都是 agent 迴圈。真正改變的其實是工具的成熟度，一年前你想做這件事，得自己寫一堆 bash script 跟排程，現在這些能力已經直接內建進 Claude Cod...

在 2026 年的企業技術圈，「Platform Engineering」已不再是矽谷大廠的專屬詞彙， 它正以驚人速度出現在每一份 CTO 的年度規劃書中。然而，許多企業在尚未釐清其本質之前， 便倉促地將資源從 SRE 團隊抽調至平台建設，結果兩頭落空。本文將從組織設計、成本結構 與工程文化三個維度深度解析，為不同規模的企業提供一套可操作的決策框架——因為這道題 的正確答案，從來就不是二選一。 一、背景：為什麼 2026 年這個問題變得緊迫？ 最近注意到一件事：「Platform Engineering」這個詞出現的頻率，已經開始追上「DevOps」。 Gartner 在其《Hype Cycle for Software Engineering, 2023》中， 將 Platform Engineering 與 AI-augmented software engineering（AIASE）、AI coding assistants 並列為 具轉型潛力的核心趨勢，預計主流採用時間落在 2 至 5 年內， 並預測到 2026 年，80% 的大型軟體工程組織將建立專責的平台團隊。 [10] 值得注意的是，根據 platformengineering.org 於 2025 年底的調查， 這個預測已提前實現——近 90% 的企業表示已建立內部平台， 比 Gartner 的預測時程提早了整整一年。 [11] 與此同時，許多已經導入 SRE 三至五年的企業，正面臨一個尷尬的現實困境： SRE 團隊的價值難以向管理層說清楚，招募符合條件的 SRE 工程師越來越困難， 而開發團隊對維運流程的抱怨卻從未減少。這些積累已久的組織摩擦， 讓 Platform Engineering 的出現顯得格外像是一個「救星」。 問題在於，當企業管理層開始把 Platform Engineering 視為 SRE 的「升級替代版」時， 一場代價高昂的組織誤判便已悄然開始。在真正理解它們的本質差異之前， 任何倉促的組織重組，都只是把問題從一個地方搬到另一個地方。 要回答「企業該如何選擇」這個問題，我們必須先回到最基本的定義。 二、定義釐清：先弄懂這兩個詞到底在說什麼 SRE 的本質 SRE 的起源可以追溯到 2003 年 Googl...