旧系统的痛点
每个内部平台的诞生都不是凭空而来的。在启动重构之前，我们的研发基础设施已经运行了将近四年，期间经历了三任负责人、两次大规模组织调整。CI/CD 流水线散落在不同的 Jenkins 实例上，部署配置靠口口相传，新人上手一个项目平均需要两周时间。
最让人头疼的不是某一个具体的技术问题，而是整体的「熵增」——每个团队都有自己的一套工具和流程，没有人能说清楚全貌。线上出了问题，排查链路要跨越三四个系统，光是找到正确的日志入口就要花半小时。
重构的决策过程
决定做重构并不容易。管理层最关心的问题永远是「能不能边跑边换轮子」，而技术团队最担心的是「新系统会不会重蹈覆辙」。我们花了将近一个月时间做调研，走访了十几个业务团队，收集了上百条痛点反馈。
最终推动决策落地的关键因素有两个：一是量化数据——我们统计出平均每次发布耗时 47 分钟，其中 60% 的时间花在等待和人工操作上；二是一次严重的线上事故，根因是配置管理混乱导致的环境不一致。
团队如何对齐目标
技术方案敲定之后，最大的挑战反而是组织层面的。我们采用了「平台即产品」的思路，把内部开发者当作用户来对待。第一步不是写代码，而是定义清楚平台的核心价值主张：让业务团队专注于业务逻辑，基础设施的复杂性由平台来吸收。
为了避免「闭门造车」，我们从各业务线抽调了一名工程师组成虚拟小组，每两周做一次 Demo 和反馈收集。这种方式虽然推进速度慢一些，但保证了最终交付的东西是大家真正需要的，而不只是平台团队的「自嗨」。
写在最后
回头看这段经历，技术选型只占了整件事的三分之一，剩下的精力都花在了沟通、协调和取舍上。内部平台建设最难的地方不在于「怎么做」，而在于「做什么」和「不做什么」。这一篇算是开个头，后续会逐步展开每个技术决策背后的思考。
相关文章