为什么一家公司人数翻了四倍多，基础设施反而从“勉强能跑”变成“每人都能独占一台”？Databricks给出的答案有点出人意料：他们给现场工程师建了一台“自动贩卖机”。
事情要从三年前说起。当时Databricks的现场工程团队还不到1500人，几个共享工作空间就能覆盖大部分用例，靠人工维护也能转得动。但接下来增长来得很快——如今整个市场进入团队已经超过7000人，其中现场工程占了相当比例。一个人少时好用的架构，在人数高速增长后就不太对劲了。
挑战的核心在一个看似矛盾的设定上。Databricks的工作空间设计逻辑是少量管理员管理大量用户，这对多数企业部署来说完全合理。可现场工程师的要求完全不同：他们几乎人人都需要管理员级别的权限才能真正干活。配置演示环境、测试预览功能、运行客户特定场景——所有这些都离不开管理员级别的控制权。当一群人都在同一个共享环境里拥有高权限时，碰撞和干扰就成了高概率事件。
更麻烦的是，平台资源并非无限。目录数量、Lakebase实例、并发工作负载都有上限，在共享空间里这些上限随时可能从“背景参数”变成“现场事故源”。而一旦出问题，追溯过程更让人头疼：共享空间里某个意外发生时，谁干的、什么时候干的、为什么这么干，全部需要手动排查。成本归属同样随着使用量上涨而越来越模糊。
Databricks团队想通了一件事：如果每个工程师都能拥有自己的隔离环境，几分钟内完成配置、由中央统一治理、用完自动清理，那会怎样？这个想法就是FEVM（现场工程自动贩卖机，Field Engineering Vending Machine）的起点。
正好这时候Databricks Apps来了。此前环境维护靠的是一堆各自独立的任务，每个任务跑在各自的时间线上，状态总比现实慢半拍。Apps则提供了一种完全不同的抽象方式：把所有这些操作收拢到一个界面之后。工程师只需要告诉系统自己要什么，剩下的事情——从资源配置到生命周期管理——由系统自动完成。
就像一台真正好用的自动贩卖机，你描述需求，东西就出来，用完它就消失。更重要的是，FEVM的核心组件全部基于Databricks自身的原生能力构建，智能代理（agents）从设计之初就是系统的一等公民，而不是后来硬塞进去的附属品。这意味着每一次配置操作都从一开始就透明、可审计、可追溯，不再需要事后翻日志猜谜。
一个从1500人到7000人的扩张过程，暴露的不仅是服务器数量的压力，更是架构设计在面对权限模式、资源隔离和运维可见性时的根本矛盾。FEVM用一种近乎粗暴的隔离策略回答了这些矛盾：与其让大家学会共享，不如让每个人都有自己的一套。而这套“即取即用、用后即焚”的环境交付方式，正在成为Databricks现场团队在AI时代快速响应客户需求的关键底座。
热门跟贴