SRE 的「四體問題」：自主維運為何離不開統一情境
CNCF Blog · 2026-07-06
CNCF Blog 於 2026 年 7 月 6 日刊出 StackGen Field CTO Sanjeev Sharma 的文章，主張目前自主維運（autonomous operations）推進緩慢的瓶頸不在 AI 模型能力，而在維運情境的碎片化。作者將這個現象類比為物理學上的「多體問題」：當四個獨立系統各自運作卻必須被同時納入單一決策時，任何規則式或模型式的自動化都難以收斂。這篇文章不談具體工具改版，而是提出一套診斷框架，解釋為何多數「AIOps」專案停留在告警彙整層次。
背景
Sharma 觀察到，現行維運環境已經把知識拆成四個彼此獨立的系統：版本控制（程式碼、commit、部署工件）、基礎設施狀態（雲端資源、Kubernetes 叢集、IAM、實際狀態與期望狀態的落差）、執行期訊號（Prometheus 指標、OpenTelemetry 追蹤、日誌、SLO 與錯誤預算）、以及維運知識（runbook、事後檢討、架構決策紀錄）。每個系統各自有成熟工具鏈，Git、Terraform、可觀測性平台、文件庫都運作良好。問題在於真正的維運決策從不落在單一系統內，而是落在四者的交集——例如一次 commit 如何改動了基礎設施狀態，進而觸發某個追蹤異常。
文章把目前彌補這道落差的機制稱為「People Putty」（人力黏著劑）：資深工程師腦中的隱性知識，加上逐漸過時的 runbook，暫時把四個孤立系統黏在一起。這套機制在小規模團隊尚可運作,但無法隨雲端複雜度擴展,一旦關鍵人員離職或系統規模擴大就會迅速失效。
核心論點
Sharma 提出的解方是先建立「基底」（substrate）再談代理人（agent）：一個即時同步、可版本化的統一知識圖譜，把程式碼、基礎設施狀態、執行期訊號與維運知識連結成同一張圖，且圖中「邊」的關係——某次 commit 如何影響基礎設施、又如何產生某個異常——比單點資料本身更有價值。只有當代理人是對著這個整合過、可查詢、語意一致的情境操作,自主維運才具備可信度,而不是對著四個各說各話的系統各自臆測。
另一個關鍵機制是「決策軌跡」（decision trace）。文章直接對比：腳本與告警是不透明且沒有記憶的,而決策軌跡必須是持久、可查詢、不可竄改的紀錄,內容包含決策當下的圖譜快照、生效中的政策、模型版本、曾被列入考慮但遭排除的假設、實際採取的行動與觀察到的結果。這讓自主維運的每一步都可回放與稽核,而非事後只能靠日誌片段拼湊。
影響範圍
Sharma 指出三個具體的整合場景可以驗證這套框架：CI/CD 流程中代理人存取 commit 歷史與部署情境以關聯變更與系統行為；基礎設施漂移偵測中,代理人持續比對 Terraform 宣告狀態與雲端實際狀態並自動協調;以及 SLO 違反事件中,代理人形成假設、執行有邊界的實驗、記錄推理過程,再决定是否上報人類。作者強調人類核准（human-in-the-loop）應該內嵌在自主迴圈的每一步,而不是事後才補上的審查關卡。
- 四體：程式碼（版本控制）、基礎設施狀態、執行期訊號、維運知識
- People Putty：資深工程師隱性知識與過時 runbook 的暫時性黏合
- Live Context Graph：即時同步、可供人類與代理人共同查詢的統一情境圖譜
- Decision Trace：持久、可查詢、不可竄改的決策紀錄，涵蓋快照、政策、模型版本與結果
原始來源：CNCF Blog、StackGen 原文
平台工程 2.0：CNCF 提出 AI 原生工作負載的五大支柱
CNCF Blog · 2026-07-06
CNCF Blog 於 2026 年 7 月 6 日刊出社群投稿文章，由 CNCF Platform Engineering 技術社群（Platform Engineering Technical Community Group）成員 epower 撰寫，主張現行平台工程模式已不足以支撐 AI 原生工作負載,需要一次結構性演進。文章將現有以黃金路徑（golden path）與內部開發者平台（IDP）為核心的模式稱為「平台工程 1.0」，並提出「平台工程 2.0」作為因應框架。核心依據是 CNCF Platform Engineering Maturity Model 白皮書所定義的成熟度分級。
背景
文章列舉五項正在衝擊既有平台設計的變化。首先是 AI 輔助程式生成的提速——程式碼產出速度已超過既有 CI/CD 管線的吞吐能力，造成新的排隊瓶頸。其次是代理系統（agentic systems）的興起：既有平台當初並未設計來處理 GPU/TPU 配置、模型生命週期管理,或是針對 AI 行為的治理機制。
另外三項變化分別是：資料主權與合規不再能作為事後補救項目，必須內建於供應流程；多角色需求擴大到 ML 工程師、資料科學家、FinOps 人員，甚至 AI 代理人本身都成為平台的直接使用者；以及 AI 基礎設施帶來的新成本型態，需要比傳統雲端支出更即時的優化機制。CNCF Platform Engineering TCG 共同組織者 Atulpriya Sharma 在文中被引述：「最初作為開發者生產力工具的平台，如今已成為企業的集中治理層。」
核心論點
文章提出平台工程 2.0 的五大支柱。第一是 AI 原生平台：把 GPU/TPU 配置、模型服務、MCP（Model Context Protocol）閘道與代理防護機制當作平台的一級能力，而非外掛。第二是 多角色體驗：平台介面需同時服務工程師、資料科學家、安全團隊、工程主管，乃至於 AI 代理人這類非人類使用者。
第三是內建 FinOps，將成本判斷從「事後報表」前移到「資源供應當下的即時決策」。第四是安全下沉，具體針對影子 AI 擴散（shadow AI sprawl）、提示注入（prompt injection）、模型投毒（model poisoning）與推論資料外洩等 AI 專屬威脅設計緩解機制。第五是可組合式設計，主張以模組化、API 優先的建構模塊，並利用 CNCF Landscape 中超過 200 個相容專案來組裝平台能力，避免重造輪子。
影響範圍
文章將平台工程 2.0 定位為對 CNCF Platform Engineering Maturity Model 既有分級框架的延伸，而非取代。這意味著已經依循 1.0 模式建立黃金路徑與 IDP 的團隊，會被要求疊加 GPU 排程、模型治理與 AI 安全層，而不是重新設計整個平台。CNCF Platform Engineering 技術社群被文章列為後續規格與最佳實踐的討論場域，另有 Broadcom 與 Platformengineering.org 聯合發布的白皮書提供更詳細的實作案例。
- AI 原生平台：GPU/TPU 配置、模型服務、MCP 閘道、代理防護
- 多角色體驗：ML 工程師、資料科學家、FinOps、AI 代理人
- 內建 FinOps：成本決策前移至供應階段
- 安全下沉：影子 AI、提示注入、模型投毒、推論外洩
- 可組合設計：模組化、API 優先，依託 CNCF Landscape 200+ 專案
Azure SDK 2026 年 6 月釋出：Planetary Computer Pro 與 AI Transcription 雙雙轉為正式版
Microsoft DevBlogs · 2026-07-05
Microsoft DevBlogs 於 2026 年 7 月 5 日發布 Azure SDK 月度彙整，涵蓋 6 月間跨語言的用戶端與管理函式庫更新。這期重點是兩個 Python 函式庫轉為正式版（GA），另有 Java 與 Python 共四個新套件以 beta 形式首次亮相。完整版本清單涵蓋 .NET、Java、JavaScript/TypeScript、Go、Python、Rust、C++、Embedded C、Android 與 iOS 等平台，但本篇僅針對 Python 與 Java 提供詳細變更說明。
核心改動
兩個正式版套件均為 Python 用戶端函式庫。Azure AI Transcription 以 1.0.0 版本首次轉正,讓 Python 開發者可以呼叫 Azure 的語音轉錄服務並取得穩定版 API 保證。Microsoft Planetary Computer Pro 同步升上 1.0.0,新增三個回應模型類別：AssetStatisticsResponse、ClassMapLegendResponse 與 QueryableDefinitionsResponse。
Planetary Computer Pro 這次 GA 附帶一項破壞性變更：StacOperations.list_collections 方法被重新命名為 StacOperations.get_collections,既有呼叫該方法的程式碼在升級後必須同步改名,否則會直接因方法不存在而拋出例外。
Beta 端則有四個新套件首次釋出。Java 管理函式庫新增 Resource Management – File Shares 1.0.0-beta.1；Python 用戶端函式庫新增 Agent Server – Optimization 1.0.0b1 與 AI Discovery 1.0.0b1；Python 管理函式庫則新增 Resource Management – Discovery 1.0.0b1 與同名的 Resource Management – File Shares 1.0.0b1。
影響範圍
對既有整合 azure-ai-transcription 或 azure-mgmt-planetarycomputer（Planetary Computer Pro 對應套件）的專案而言,升級到 1.0.0 前需先搜尋程式碼庫中所有 list_collections 呼叫點並改為 get_collections,才能避免升級後的執行期錯誤。四個 beta 套件（File Shares 資源管理、Agent Server Optimization、AI Discovery、Discovery 資源管理）都屬於非穩定介面,方法簽章與回應結構在後續版本仍可能調整,不建議在生產環境依賴其行為。
| 套件 | 語言 | 版本 | 狀態 |
|---|---|---|---|
| Azure AI Transcription | Python | 1.0.0 | GA |
| Microsoft Planetary Computer Pro | Python | 1.0.0 | GA（含破壞性變更） |
| Resource Management – File Shares | Java | 1.0.0-beta.1 | Beta |
| Agent Server – Optimization | Python | 1.0.0b1 | Beta |
| AI Discovery | Python | 1.0.0b1 | Beta |
| Resource Management – Discovery | Python | 1.0.0b1 | Beta |
| Resource Management – File Shares | Python | 1.0.0b1 | Beta |