Backstage與Lakebase的結合，第二部分

在本系列的第一部分中，我們展示了將Backstage的底層資料庫遷移至Databricks Lakebase如何將風險性的模式遷移轉變為1秒分支與測試操作。然而，如果安全和治理團隊仍然將運算元據庫視為黑箱，那麼更快的開發週期也只能帶來有限的改進。

傳統架構中，應用資料庫與資料湖分屬不同的安全正規化。Backstage的基礎設施所有權圖儲存在獨立的RDS例項中，透過複雜的IAM角色和Postgres原生許可權進行管理；而資料倉儲資料則由資料團隊透過Unity Catalog治理。Unity Catalog是Databricks建立的開源框架，為資料、AI以及現在的運算元據庫提供統一的治理層——一個集中管理訪問控制、審計追蹤、血緣和合規性的地方。

為了審計RDS上的一個表刪除操作，需要交叉引用CloudTrail（IAM主體）、pg_stat_activity或pgaudit日誌（SQL語句）以及CloudWatch（時間戳），涉及三個服務、三種查詢語言、三種訪問策略。運算元據庫成為合規性的側通道。

當我們將Backstage指向Lakebase時，改變的不僅是資料儲存的位置，更是訪問策略的所在。由於Lakebase原生嵌入Databricks，Unity Catalog直接擴充套件到操作Postgres資料庫。在本POC中，我們使用Lakehouse Federation將Backstage目錄作為外部目錄（lakebase_bs）暴露在Unity Catalog中。一旦完成，標準的UC授權即可控制誰能看到什麼，無需Postgres級別的角色管理。儘管我們未在POC中為Backstage構建端到端的行級安全策略，但從架構上看，保護敏感計費表的相同RLS規則可以直接應用於這些操作表。“操作”與“分析”之間的壁壘不再是物理邊界，而僅僅是訪問模式。

還記得第一部分的1秒寫時複製分支嗎？在傳統設定中，向安全工程師證明開發者僅分支資料庫一小時然後銷燬，是一個手動過程。使用Lakebase，每個針對運算元據庫的控制平面操作都會自動記錄在system.access.audit中。我們透過查詢審計日誌驗證了第一部分的精確分支操作：每次分支建立和刪除都記錄在案，每個事件關聯到特定的OAuth使用者身份和源IP，自動捕獲，並受到與Unity Catalog中其他審計表完全相同的行級安全控制。無需CloudTrail交叉引用，無需RDS日誌解析，只需一個SQL查詢。

治理團隊不僅想知道誰建立了分支，還想知道其成本。在傳統AWS環境中，追蹤臨時RDS例項的成本需要自定義CloudWatch標籤策略，且經常遺漏短期工作負載。由於Lakebase原生整合Unity Catalog的系統計費表，計算成本自動按project_id、branch_id和endpoint_id細分。本POC中，生產分支計費31.6130 DBU，而已刪除的測試分支獨立歸屬0.0107 DBU。審計追蹤與成本追蹤在同一位置治理。

對於每天建立分支的團隊，這種治理能力解決了合規性問題：能否證明誰在何時做了什麼以及成本？答案是肯定的——一個SQL查詢替代三個服務。但還有第二個治理問題同樣重要：當團隊每個Sprint建立數十個分支時，治理如何處理？Unity Catalog的分支級治理在此處成為關鍵支撐：建立Lakebase分支時，屬性級掩碼策略自動傳播到新分支。開發者在其功能分支上永遠看不到未掩碼的生產資料——不是因為有人記得配置，而是因為治理層在建立時強制執行。CI分支、QA分支均與生產環境受同等治理。沒有“非生產例外”導致敏感資料洩露。

根據Perforce 2025年資料合規報告，60%的組織曾在非生產環境中發生敏感資料未充分匿名化導致的洩露或竊取。當環境在數秒內建立和銷燬時，傳統的手動資料掩碼方法無法擴充套件。治理必須自動化，否則便無法實現。

審計追蹤和成本歸屬資料也暗示了一個更微妙的變化：DBA的角色正在從被動的工單處理轉向戰略性的平臺架構設計。當前，DBA大量時間用於環境配置、模式稽核、資料重新整理、訪問授權等操作請求。一個六人開發團隊每個Sprint可能產生30+工單，DBA的日程變成佇列。而真正有價值的專業知識——資料完整性、效能和治理的深刻理解——被重複性的配置工作掩埋。

當分支自助化且治理自動化後，重複性工作消失。開發者一秒內自助配置環境。模式變更透過拉取請求非同步稽核——DBA看到CI釋出的格式化模式差異，按自己的時間表稽核，透過正常PR工作流批准或請求更改。有更多時間後，DBA能進行更深入的稽核：幫助團隊成員理解生產中的現有資料和結構，共同達成更優解決方案，進行維護資料完整性和治理標準的徹底稽核。資料掩碼由策略而非人工干預強制執行。成本歸屬自動完成，無需月度對賬。

釋放出來的是實際發揮DBA專長的工作：定義分支策略、設計治理規則、架構提升工作流、調優效能、建立使自助服務平臺安全的護欄。DBA從執行工作轉變為設計工作方式——從每個Sprint 30+運維工單降至少於5個高價值策略稽核。上述審計追蹤不僅是合規工件，更是DBA新的戰略儀表盤——平臺使用情況的即時檢視及下一步投資方向。

兩個開源工具（均部署為Databricks Apps，受同一Unity Catalog授權和審計追蹤治理）閉環了這一轉型：LakebaseOps（平臺自主執行：三個Agent替代51項工單任務；監控UI展示即時pg_stat指標、慢查詢迴歸、分支TTL強制、9-KPI採用儀表盤；遷移向導評估十個源引擎並提供即時定價）和Lakebase MCP（DBA基於平臺的工作：Model Context Protocol伺服器向任何MCP相容AI Agent暴露46個工具；DBA無需開啟pgAdmin，而是描述意圖。

雙重治理設計確保安全：SQL語句防護和每工具訪問防護，四個預置配置檔案（read_only、analyst、developer、admin）對映到前述UC訪問模式。編碼助手以read_only執行，物理上無法刪除表。每條查詢均可歸屬——伺服器用來源工具標記每句語句。結合分支級成本歸屬，一個問題“哪個Agent在哪個分支上導致了凌晨4點CPU峰值？”可透過一個SQL查詢回答。

LakebaseOps為團隊執行，Lakebase MCP與團隊共同執行。兩者繼承前述治理態勢。本系列第三部分將探討最終成果：將Backstage內部的基礎設施所有權資料與雲賬單資料直接在一個SQL查詢中連線。