在去年的KubeCon+CloudNativeCon欧洲大会上，两位工程师Eugenia Bergman和Hagen Tonnies分享了他们如何从一个为游戏流媒体服务的单一平台起步，最终将整个基础设施运营方式从项目管理彻底转向产品思维的历程。这一转变的核心矛盾在于：当平台只需支撑一个内部客户时，年度项目规划、预算锁定和里程碑交付能运转得很好；但当多个团队接入、需求开始分化，那种“一次交付、用完即止”的逻辑就开始反噬团队自己的节奏。

Bergman回忆，早期他们的平台开发周期完全围绕年度项目计划展开：年初划定范围、分配预算、定义交付节点，每一项改进都被包装成一个有起点和终点的项目，成功与否只看是否按时、按量、按里程碑完成。这套流程在支撑单一的游戏流媒体产品时，让一切显得可控。问题出现在平台慢慢演化为要服务多个内部团队后——不同团队对基础设施的诉求互相冲突，而项目制带来的却是一堆离散的能力堆积，缺乏整体向前演进的动力。

打开网易新闻 查看精彩图片

他们察觉到的第一个痛点是“一次性交付”造成的累积债。每一次平台增强都被当作独立项目交付，完成后即宣告结束，下一个项目的优先级总是重新排序，导致很多刚建立的能力转头就被搁置。平台没有清晰的产品定义，虽然一直在持续交付，但整体可用性和内聚性反而停滞不前。Tonnies补充说，当时的反馈循环基本是内向的，团队只关心迭代速度、完成度和质量，却很少有真正来自平台用户的验证，整个系统优化的只是“做完”而非“长期使用价值”。

转机的触发来自内外部思想的混合撞击。Tonnies提到，早期业内已有同行开始引入系统思维和产品思维，比如Prometheus和Grafana的生态文化；内部则开始集体阅读《Project to Product》和《凤凰项目》这类著作，很多人发现自己的痛点几乎被全盘复述。此后，一群架构师和高级工程师组成的小型实践社区开始密集辩论这些理念，一点点摸索出替代现有模型的方法。

他们的开发者平台也随之发生实质性的形态变化。以往它从来不是一个统一平台，而是围绕Kubernetes和GitOps实践有机生长出来的一组能力。早期主要以Helm部署、命名空间范围内的资源和GitLab驱动的流水线为核心，团队通过内部开发门户接入，大多运行在共享集群里。这套模型在标准化应用交付上很高效，但它本质上为单一服务团队优化，没有真正解决更复杂的多租户和多样化基础设施需求。随着公有云服务（如AWS）的引入，这种局限被进一步放大，也直接推动了向自助式、API驱动、多租户架构的跃迁，让平台所有权更清晰、抽象更合理。

整个转变可被看作一个分水岭：一旦平台从“内部工具”变成“内部产品”，团队就必须从完成交付的工程节奏中抽出身来，去构建可叠加的价值路径和真实闭环的反馈机制。对于任何正在规模化内部平台的工程师团队来说，Bergman和Tonnies的经历都是一个鲜活的注脚——扔掉旧的项目地图，不一定迷失方向，反而可能第一次看清用户到底需要什么。