在银行业为基于 Kubernetes 的平台打造云原生文化

在银行业环境中，开源可以通过运行真实工作负载来建立信任，正如 Marcy Paramonova 和 Stéphane Cusin 在 KubeCon & CloudNativeCon 欧洲大会上的演讲《在银行打造云原生文化》中所说的那样。部署 Kubernetes 是容易的部分，难的部分是文化建设：实践社区、共享知识、协作机制、权责归属。团队不断尝试，保留有效的做法，并自下而上地改进。 Cusin 提到，在他们所处的银行业环境中，开源并不是顺理成章的选择。当时不少人质疑开源的技术支持与责任界定问题。他们没有试图用理论说服人们，而是开始运行真实的工作负载。随着时间的推移，信任通过日复一日的平台运营建立起来： 开源不再被视作风险，而是成为了底层基石。 他们把第一版 Kubernetes 当作一个项目来落地。Cusin 说：“我们完成了交付，也获得了不错的采用率。”但运维工作极其痛苦，并不是因为技术本身有问题，而是配套的文化体系还没有建立起来： 没人知道出问题该找谁，职责边界模糊，团队在使用平台，却很少参与贡献。每一次故障都像一场仓促的应急演练。 他们意识到，部署 Kubernetes 是容易的部分，困难的部分是围绕它建立一种文化，形成实践社区。知识共享、协作机制、权责归属模式，Cusin 解释道： 没有这种文化，任何平台都无法在其自身的成功中生存下来。 他们鼓励大家尝试创新，例如每年举办创意征集竞赛，任何人都可以提交想法，胜出方案会真正得到实施。Paramonova 表示，很多优化改进都来自自下而上的反馈。 他们将开源比作指南针，用来帮助他们确定方向，Cusin 解释道： Kubernetes 出现的时候，我们一眼就认准了它。成熟的 Kubernetes、透明的治理机制、真实的生产用户。指南针指明了方向，我们就跟进。现在我们也在用同样的方式关注 OpenStack。 指南针不会强迫你朝某个方向前进，而是帮你在机会到来时识别正确的方向，Cusin 说。 他们尝试了各种方法，有些并不奏效。他们保留了有效的方法。Cusin 认为，尝试的行为、刻意设计团队互动方式的行为，塑造了现在的文化。结构先行，文化随之而来。 每个组织都不同，每个受监管的环境都有自己的约束，Paramonova 说。在这个旅程中你需要一个指南针。当其他一切都不确定时，它会指引你。对我们来说，它就是开源，她总结道。 InfoQ 在演讲结束后采访了 Marcy Paramonova 和 Stéphane Cusin。 InfoQ：你们是如何获得开发团队信任的？ Stéphane Cusin：随着时间的推移，信任从透明度和可靠性的结合中显现出来。当开发者看到平台持续帮助他们安全高效地交付应用，自然就愿意采用。 Marcy Paramonova：信任不是靠一份路线图或者完善的文档就能建立起来的，尽管这两者都很重要。它来自于实际的运行，来自于在出现问题时及时到场，来自于诚实地说明哪些能力还没有准备就绪。 Cusin：如今，我们的文化以权责归属、自动化、透明度和持续改进为核心。团队拥有快速迭代的自主权，但他们是在共享标准和平台能力的框架内这样做的。最终不仅效率更高，整个组织内的规范性、可靠性和可观测性也得到提升。 InfoQ：Kubernetes 给组织的软件构建方式带来了哪些改变？ Cusin：Kubernetes 为我们提供了统一的平台和运维模式。我们的第一个版本给了团队灵活性。我们直接暴露了许多 Kubernetes 能力，并允许团队深度自定义部署模式。在实践中，这往往导致不同团队出现不同的模式。作为平台工程师，我们学到的一个教训是：开发者来到平台不是为了寻找更多的基础设施选择。他们的目标是为了交付软件。在当前的平台版本中，Kubernetes 不再是产品，而是实现细节。产品是一个简单、安全、标准化的软件交付体验。我们提供预设的部署模式、标准化的 Helm charts 和通用的平台能力。因此，当工程师从一个团队转到另一个团队时，部署体验基本保持一致。他们不需要重新学习应用如何打包、部署、监控或运维。 Paramonova：我感受最深的是组织层面的变化。Kubernetes 给了团队一种共同的语言，形成共享的抽象，让工程部门不同团队之间的协作变得更加顺畅。以前，很多知识按团队或技术栈割裂沉淀。Kubernetes 并没有在一夜之间消除这些孤岛，但它给了每个人一个统一的构建基础。这改变了大家沟通的方式，也打开了更多可能性。 查看英文原文： https://www.infoq.com/news/2026/11/culture-kubernetes-bank/ "