為智慧體時代做準備：Databricks如何構建自助基礎設施自動售貨機

在 Databricks，現場工程組織的使命是幫助客戶成功。這意味著構建演示、重現問題、在真實工作負載上測試功能，並隨時準備向潛在客戶展示平臺的可能性。在 AI 時代，這一點比以往任何時候都更加重要——一週可能帶來根本性的變革。隨著 Databricks 的發展，以快速、受治理且成本可控的方式賦能現場組織變得既重要又具有挑戰性。

為了解決這個問題，我們構建了現場工程自動售貨機（FEVM）。就像一臺好的自動售貨機一樣，理念很簡單：你說出需求，你得到它，用完後它自動消失。最重要的是，FEVM 以 Databricks 原生元件為核心，並將智慧體視為一等公民。

三年前，現場工程團隊不到 1500 人，少數共享工作區覆蓋了大多數用例，手動維護也還能運轉。但 Databricks 增長迅速，GTM 現在超過 7000 人，現場工程佔了很大比例。曾經適用於一個規模的基礎設施需要重新設計以適應新的規模。共享工作區中多名工程師在同一環境中工作會相互干擾，平臺限制（如目錄、Lakebase 例項和併發工作負載）成為現實問題，成本歸屬變得模糊，可觀察性也面臨挑戰。

FEVM 的核心洞察是：如果每位工程師都能擁有自己的隔離環境，幾分鐘內配置完畢，集中管理並自動清理，情況會怎樣？當 Databricks Apps 可用後，我們有了明確的構建機會。過去我們用一系列獨立作業維護環境，每個作業執行一項任務，總是稍微落後於現實。Apps 讓我們將所有功能抽象到一個單一介面背後：用自然語言描述你要完成的任務，我們就會配置相應的基礎設施。

這就是 FEVM 的核心設計原則：基於用例的配置。你不是請求“一個工作區”，而是描述你要做什麼——構建金融客戶演示、重現支援問題、執行駭客馬拉松——然後獲得為特定目的配置的環境。這一切透過 MCP 抽象，意味著聊天、外部服務和智慧體都透過單一控制點提供服務。藉助 Claude 等工具，只需新增一個簡單的 .md 技能檔案，你就可以用自然語言透過命令列請求新環境，幾分鐘後即可登入。

FEVM 採用 React 前端和 Python 後端，透過 Databricks Apps 部署。Terraform 在後臺執行，負責在 AWS、Azure 和 GCP 上進行實際雲資源配置。狀態和配置資料庫執行在 Lakebase 上，跟蹤每個資源：它是什麼、誰擁有它、用途和過期時間。

當現場工程師開啟 FEVM 時，會看到一個搜尋介面。他們可以瀏覽模板目錄，選擇合適的環境型別——例如 AWS 上的穩定無伺服器、多雲設定或預配置了 Lakebase 自動擴充套件的環境——並配置雲提供商、區域，描述構建內容，命名後即可部署。最近，我們還啟用了智慧體優先工作流，允許使用者使用集中釋出的 Claude 技能；智慧體可以自動執行 UI 操作，直接呼叫底層 FEVM API。這在多步驟和多工具工作流中尤其強大：例如，使用者可以告訴智慧體啟動新工作區、部署多個 DAB、上傳 S3 中的資料，然後執行指令碼填充儀表板。

當使用者或智慧體請求新資源時，後臺會獲取相應的 Terraform 模板，提交給 Git Runner，調整許可權，並新增使用者請求的“附加元件”，如 Lakebase、筆記本或 UC Volume 中的預打包資產。構建環境預設存活 90 天，可延期，其他資源型別具有可配置的 TTL。配置完成後會傳送 Slack 通知，資源接近過期時再次通知，刪除時也會通知。透明度是核心設計目標：每個生命週期事件都可見。

我們還在同一介面管理共享資源。獨立目錄具有獨立生命週期，刪除工作區後目錄保留，在同一區域建立新工作區時目錄自動重新附加。這種資源級生命週期管理很重要，因為 Unity Catalog 和 Lakebase 有嚴格的平臺限制，集中控制可以防止這些限制成為瓶頸。

在內部活動 BuildCon 期間，FEVM 一天處理了近 1200 個配置請求。工程師們建立環境、完成工作、讓它們過期，沒有協調開銷或資源爭用。目前我們管理著超過 2600 個活躍部署，跨越三個雲，沒有遇到擴充套件性問題。

我們兩次重新架構了 FEVM：重新設計資料庫模式、重建前端、重新思考狀態管理。我們使用 AI 加速編碼，但在架構上始終掌握主導權。結果是一個值得信賴的系統，可以在規模上執行。

下一步，我們將專注於三個方面：擴充套件自然語言配置介面、交付 MCP 整合以實現基於工具的訪問，以及在整個 GTM 組織中擴充套件支援。隨著智慧體承擔更多現場工程師的工作，FEVM 將成為這些智慧體執行的資源層——不僅是配置工具，更是智慧體工作流的核心基礎設施。