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查詢中連接。