银行开源实践：从部署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 没能一夜之间推倒这些孤岛，但它给所有人提供了一个一致的构建基础。沟通方式随之改变，更多可能性也被打开。