银行平台工程转向开发者自助模式

Marcy Paramonova 与 Stéphane Cusin 在 KubeCon & CloudNativeCon Europe 的一次演讲中，以一家银行的云原生转型为例提出：平台不应被视为单纯的基础设施，而是一套承载沟通、协作和共同标准的系统。开发者和产品团队需要平台能力，平台团队也依赖应用团队的反馈和参与，因此双方必须围绕共享标准共同演进。

他们认为，云原生转型不只是技术替换，更是工作方式的变化。为了减少传统工单支持带来的等待和依赖，平台团队引入开放支持会，让开发者可以直接带着问题与平台、基础设施、网络安全、网络、身份和云团队成员一起讨论解决方案。Cusin 指出，如果每一步操作都必须提交工单或等待平台工程师介入，组织就会形成“等专家”的文化，而不是培养团队自主运营能力。

为了鼓励平台采用和共同改进，团队还设立了“超级用户奖”，表彰积极反馈、参与建设的开发者。Paramonova 表示，一些反馈虽然尖锐甚至令人不适，但正是这些意见帮助平台变得更好。她还强调，基于开放标准和开源技术构建能力，可以让工程师技能更容易迁移；真正关键的不是掌握某一项当前技术，而是持续学习、解决问题并分享经验的工程思维。

在后续交流中，Cusin 介绍称，团队从一开始就确定平台能力不能依赖人工干预。应用团队不需要提交工单等待变更，而是通过声明式配置和自动化工作流使用平台能力。例如在 Git 中修改配置后，GitOps 流程会自动应用变更。这种方式既提供了自助体验，也让平台采用情况具备完整的可追溯性和可见性，团队可以判断哪些能力正在使用、哪些已经闲置，以及某项调整会影响哪些用户。

Paramonova 进一步说明，文化无法靠命令建立，但可以通过结构设计促成。团队每周举行两次名为“Genius Bar”的开放时段，每次两小时，开发者可就平台问题、功能异常或组件关系直接沟通，无需排队等待。团队还会举办用户洞察会，共享优先事项、已完成工作和可见性信息，并与用户共同确定优先级；同时通过演示说明已发布能力、路线图和日常使用方式。平台团队内部也保留规划会议，以避免长期陷入被动响应。

Cusin 总结称，平台决策应尽可能透明，平台能力通过版本化制品、可复用部署模式和文档化接口交付，而不是依赖个别团队之间的口头约定。每项平台功能也应具备生命周期管理，明确谁在使用、如何使用以及是否仍有价值。通过把自助服务、标准化、透明度和共同所有权嵌入平台本身，组织更容易摆脱对少数专家的依赖，并让期望中的工程文化成为默认工作方式。