平台团队最常见的困境是被业务团队当作”外包”——业务团队提需求，平台团队去实现。这种模式下，平台团队永远在疲于应付各种定制化需求，无法沉淀真正的平台能力。根本原因在于边界不清：平台应该提供的是”铺好的路”，而不是替业务团队”修路”。
好的平台像是一条高速公路——它定义了车道宽度、限速标准和出入口规范，但不会规定每辆车要去哪里。平台团队的职责是提供高质量的基础设施和合理的抽象，让业务团队能够自助式地完成部署、监控、扩缩容等操作，而不是每次都提工单等排期。
平台能力的提供方式大致分为两种：自助式和全托管。自助式意味着平台提供工具和文档，业务团队自行操作；全托管意味着平台团队包揽一切，业务团队只需要提交代码。两者各有优劣——自助式灵活但学习成本高，全托管省心但容易成为瓶颈。
实践中我们发现，最佳的模式是”分层提供”：底层基础设施（网络、存储、计算）全托管，中间件（数据库、缓存、消息队列）提供标准化的自助式申请和管理界面，应用层（部署、灰度、回滚）提供 CLI 和 CI/CD 集成。这样既保证了基础设施的一致性，又给了业务团队足够的自主权。
“系统的架构反映组织的沟通结构”——Conway 定律在平台建设中有着非常直接的体现。如果平台团队和业务团队之间沟通成本很高，那么平台和业务系统之间的集成必然也是笨重的。反过来说，如果你希望平台的 API 是简洁易用的，那就需要平台团队和业务团队之间有高频、低摩擦的沟通渠道。
我们的做法是在每个业务域设置一个”平台对接人”角色，由业务团队的工程师兼任。他们既了解业务需求，又熟悉平台能力，能够在两个团队之间高效地传递信息。这种组织设计上的投入，往往比任何技术方案都更能影响平台的最终效果。