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查询中连接。