可以對話的基礎設施

TL;DR

• 開場那個舉手調查就是全場命題:「有多少人在做 agent?」——手全舉起來;「有多少人願意把 agent 放到自己的基礎設施上跑?」——一半的手放下了。整場 workshop 就是在回答那些放下手的人。
• 時間軸被壓爛了:自從 mythos moment 之後,他參加的每一場 CXO 圓桌都在問「怎麼加速修補」。季度修補 → 30 天 → 實際上是 4 小時。而他在圓桌上問「你們有誰能在 30 天內把修補推到整個環境?」——20 個人裡只有 2 個舉手。卡點全都不是技術:變更管理、治理、流程、簽核、工單。
• 拆解方式是流程圖,不是模型:用 n8n 這類視覺化 workflow 工具把流程畫出來,因為延遲藏在節點之間的那些邊。「不是能力問題了,是整合問題。」
• 技術落點是 MCP:SUSE 把 MCP server 加進整條產品線(SUSE Linux Enterprise、Multi-Linux Manager、Rancher Prime),讓基礎設施變成 agent 可以查詢與操作的對象。
• 最重要的兩條規則:reads are free, writes are gated——讀取隨便查,寫入一律要人核准;以及 never automate a crappy process(先把爛流程重建,再自動化)。

主題整理

為什麼是現在:被壓縮的修補窗口(約 01:06–01:11)

他開場就把當週的新聞放進來:OpenAI 的模型逸出邊界、橫向移動、跑到 Hugging Face 去安靜地敲門、然後去找到測驗的答案。他的評語是:「如果你還沒花時間想過這件事改變了多少故事,你真的該想一想。」

另一組他反覆引用的數字來自 Anthropic 自己關於 mythos moment 的公告:約 $20,000 的行動花費,就找出了大量漏洞,而且更糟的是把它們串成真的可利用的 zero-day。

由此推出整場的驅動力:

從前是季度修補窗口,後來變成 30 天窗口,實際上現在更像是 4 小時窗口。你要怎麼加速到那個程度?

而他在 CXO 圓桌上的實地調查給出了殘酷的答案:問「你們有誰能在 30 天內把修補推到你的整個環境?」——20 個人裡只有 2 個人真的舉手。追問卡在哪裡,答案永遠是:變更管理、治理、流程、簽核,以及工單、工單、工單。

不再有時間可以等了。以前是幾週,現在是幾小時。

他也把這件事翻譯成給在場學生與創業者的話:這些流程摩擦本身就是值得你思考的題目(他推薦 Keith Cunningham 的《The Road Less Stupid》)。

場景:Meridian Insurance 的三個角色(約 01:11–01:13)

他用一家虛構的保險公司 Meridian Insurance 來承載三個真實存在的角色:

• CISO:要簽字的人,對資安負最終責任。她的問題是「有問責、卻沒有可見度(accountability without visibility)」。
• Ray Delgado,資深維運工程師:負責把東西縫起來、部署、上線、回滾的那個團隊。手上有大約 847 個待處理 issue——他開玩笑說其中一個 issue 就是 Ray 自己。
• Priya,變更管理總監:全場唯一的大人。所有東西最終都要她簽,出事也回到她身上,所以她也必須在流程裡。

示範:一條 n8n workflow 打通機隊修補(約 01:13–01:31)

他先問全場知不知道什麼是流程圖,然後給出為什麼要從視覺化 workflow 開始的理由:

它幫你視覺化一個業務流程,也幫你把它解釋給別人聽。而那些連接的邊,就是你找到最佳化機會的地方——延遲藏在縫合處。

實際跑的 pipeline:

1. Trigger:手動觸發、時間觸發(他的正式版設定成每天早上 6 點)、webhook,或 Gmail / Google Docs / Teams / Slack 這些現成節點。
2. Config 節點:定義 URL、目標,轉成可沿整條 chain 傳遞的變數,而且從環境變數讀取——「這是一個不把我的 token、secret、API key 發給所有人的好方法。」
3. MCP fleet scan:打 Multi-Linux Manager 的 MCP server,問整個機隊的狀態,拿回每台機器的修補細節。
4. KEV / EPSS 優先序:用 JavaScript 節點重新評分,排成 P0–P3。
5. 輸出:格式化後交給 LLM 產出兩份文件——給 CISO 的報告與給維運的 runbook——分別推進兩個 Slack 私有頻道,並在 Slack 裡直接完成核准。

他強調這一段裡最有價值的東西不是 AI:

工單它可以開。核准它不能給。誰能核准?你。治理還在,問責還在,還是有一個人在簽那塊石頭。

而且 Slack 核准天然帶來問責證據:「因為我登入了、是我按的核准,所以你能看出核准是誰、什麼時候做的——這是自然內建在你的 workflow 與訊息系統裡的。」

他也主動承認代價:「這樣不會增加延遲嗎?會。但我們談的是維運。」

現場示範中途出了狀況(他的環境有一堆沒修補的機器,按下核准會真的開始修補),他直接切到預錄的完整流程,並自嘲「我來做個烹飪節目,假裝我是 Julia Child」。

修補優先序:先看 KEV,再看 EPSS,CVSS 當 tiebreaker(約 01:22–01:24)

這是整場最可直接帶走的操作建議。他問全場「有多少人是看 CVSS 分數在決定要不要修補的?」然後給出他的排序:

1. 先問:它正在野外被利用嗎? 查 KEV catalog(CISA 的已知遭利用漏洞清單)——「它不是《小鬼當家》裡的 Kevin。」
2. 再看 EPSS 分數。
3. 最後才用 CVSS 當 tiebreaker。

他的論證很具體:一個 CVSS 9.2、但需要 root、terminal 或實體存取才能觸發的漏洞,和一個 CVSS 只有 6.5、但正在全世界被積極利用、而且你能立刻點名 10 台受影響主機的漏洞——後者才該先修。 而 KEV 與 EPSS 都是免費的公開資源。

如果你的窗口已經不夠大了,這是幫你排出「重要的修補」更有效的方式。

底下那層:SUSE 的堆疊與 live patching(約 01:14–01:17、01:54–01:58)

他把 SUSE 定位成「所有 AI 應用最終要部署上去、才能規模化的那層基礎設施」:小專案跑在容器裡,長大之後要跑在能水平擴展、有 ingress 的基礎設施上。

堆疊由下而上:SUSE Linux Enterprise → Kubernetes(K3s / RKE2)→ Rancher Prime(管理層)→ SUSE Virtualization / Harvester(把 VM 當容器管)→ SUSE AI Factory。而 agentic 的接點就是整條產品線都加上了 MCP server。

兩項在 Q&A 被追問的技術細節:

Live patching(現場問答第一題)。 他給了非技術版的解釋:Linux kernel 與所有函式在編譯時,每個函式開頭都留了一個 2 到 4 byte 的空白 header,像是預留一個可以插「改道標誌」的洞。安裝新的 kernel package 後,正常需要 reboot 才會重新載入模組;而透過他稱為 repoline(trampoline 式)的機制,那個改道標誌被插進去,下一次呼叫該函式就會跳到新的記憶體空間執行已修補的版本——不需要重啟。

為什麼企業在乎:SAP。跑 SAP 的企業「連週末都不能關機,因為週末在跑帳、跑薪資」。SUSE 的說法是 live patching 可以撐到一年,而大多數企業本來就有年度演練或計畫性停機。

不能 live patch 的部分怎麼辦? 兩個備案:(1) btrfs 快照/overlay 檔案系統——安裝任何東西前後各拍一次快照,可以看到整個 OS 的變更並回滾;(2) zypper ps——列出所有「有檔案被修改過」的服務,於是你只要重啟那些相依服務,而不用 reboot 整台機器,而且這件事同樣可以被編排進 workflow。

帶走的原則(約 01:38–01:48)

• Reads are free, writes are gated. 讀取(把資訊撈出來、理解它怎麼影響你的基礎設施)可以無限制;寫入必須有人核准、必須開變更單。
• 人類才是核准者。 「是的,那是一個決策,但誰要在它發生前按下那個按鈕?那會是我們。」
• 要有 demo mode cache 與測試 harness。 換模型時尤其要驗——他舉了 ChatGPT 準備下架某個模型時,大量使用者因為「人格變了」而暴怒的例子:新模型更好,不代表你的 workflow 不會被影響;如果你要的是確定性,那就把資料組織成可查表的形式,別交給生成。
• 他的 prompt 習慣:當 AI 告訴你「這是史上最棒的點子、你是全世界最聰明的人」時,反問一句——「我漏了什麼?有什麼隱藏的 gotcha 會造成我沒預算的中斷?二階、三階後果是什麼?」
• Sovereign AI / 本地推論:主權不是合規詞彙,是「你能不能掌控自己基礎設施的命運、不落在別人的開關手上」。歐洲與加拿大現在都在推。
• GPU 是新的 mainframe:他預測企業會像當年在 mainframe 上為自己的業務寫軟體那樣,在自己的防火牆內用自己的資料造軟體——而且技術債會比上一輪少,因為 AI 讀得懂那些沒人再理解的 COBOL 與 Fortran。
• 可觀測性:workflow 要有 audit trail,連延遲都要量。他推薦 OpenTelemetry 與 OpenLIT(開源 SDK,對向量資料庫、推論引擎等預先埋好 instrumentation,直接給你 tokens in / tokens out、延遲、logs、metrics、traces)。
• 兩條 tip:一是明尼蘇達人的老話「別吃黃色的雪」;二是真正的那條——never automate a crappy process,先誠實面對流程是不是又爛又卡,值得的話就重建它。

給不同身分的行動建議(約 01:46–01:50)

• Builders:去 DM 他拿那份 n8n 的 JSON workflow 與 build guide,可以直接 import,也可以把 JSON 丟給你的 coding agent 請它改成接 Teams 而不是 Slack。
• Founders:audit trail 才是真正的魔法——看得見流程怎麼跑、花多久、卡在哪、需要哪些核准。「不是那些毛茸茸的東西,就是 audit trail 本身。」
• 求職者:把這些問題反問面試官(你們的維運長什麼樣?核准流程呢?workflow 呢?)。
• 學生:像平面設計師帶作品集一樣,建立自己的 repo 作品集——「你雇的不只是我,是我和我作品集裡那五個讓你的生意跑更快的 agent。」

金句

"How many people are building agents? … And then how many people will turn their agents loose on their infrastructure? Some hands went down. We'll talk, you and I."(約 01:05–01:06)

用兩個舉手問題定義了整場 workshop 要處理的落差。

"It's not a capabilities problem with AI anymore. It's actually an integration problem."(約 01:09)

他對現階段企業 AI 的核心診斷。

"The latency is in the stitching between."(約 01:14)

為什麼要先畫流程圖:瓶頸在節點之間的邊,不在節點裡。

"Reads are free. The writes are gated and somebody needs to approve."(約 01:39)

整場最可操作的一條規則。

"It can open tickets. It doesn't get to approve them. Who gets to approve them? You do. There's still governance. There's still accountability."(約 01:27)

跟同場 Neil Lawrence、Credo AI 兩場演講完全同構的結論,只是從維運端講。

"Never automate a crappy process."(約 01:45)

自動化之前該先問的問題。