开源如何促进平台构建过程中的协作

作者 ｜Ben Linders

译者 ｜ 平川

在 KubeCon & CloudNativeCon 欧洲大会 上，Marcy Paramonova 和 Stéphane Cusin 发表了题为“在银行中构建云原生文化”的演讲。他们指出，平台是一种协作系统：平台团队依赖于应用团队，两者需要共同的标准。工程师对平台的信任源于其可预测的行为，而非其功能。

Cusin 提到，开源为我们提供了亟需的东西：一套在团队、供应商和各类工具之间通用的共享标准与统一语言。在银行环境中，开源并非一个显而易见的选择。人们对技术支持和责任归属等问题存在诸多疑虑。

Cusin 认为，银行业环境首先需要信任：

信任并非一蹴而就的决定。它是通过日复一日地运营平台以及保持一致性而建立起来的。作为平台工程师，我们了解到，开发者信任一个平台并非因为它的功能，而是因为它的行为可预测。

Paramonova 表示，平台是一种协作系统。开发人员和产品团队依赖于平台团队。平台团队依赖于应用团队，双方需要共同前进；为此，他们需要共同的标准。

Paramonova 指出，开源用户不仅使用这项技术，还会为其做出贡献，围绕它建立社区，并就技术问题交流想法。我们对这种交流的一种诠释就是我们的“天才吧”活动：

我们希望跳出以往仅提供技术支持的常规模式，为用户带来一些新颖的内容。我们曾经开设过开放式支持环节，用户可以随时前来，我们会与他们一起解决问题。随着时间的推移，越来越多的人对此产生了兴趣。实际上，已经有许多基础设施团队加入了我们。

Paramonova 表示，工程师可以通过提升软技能获益，这有助于大家更好地协作。她提到，他们采取了一种社区驱动的方式，即人们围绕技术创建并维护各类俱乐部或社区。

Paramonova 指出，责任感的增强改变了工程师之间的互动方式。公司不仅信任他们能够完成任务，也信任他们能够做出实际决策并产生切实的影响。

Paramonova 提到，作为一名工程师，关键在于解决问题并对此充满热情。而成为一名工程师，也意味着要分享你对解决问题的热情。

Cusin 表示，开源不仅仅是一种软件选择，更是一种承诺。如果只是更换工具，却不改变人们的思维方式、协作方式和开发方式，最终会陷入僵局。

Cusin 提到，开源从来都不是管理层下达的指令，也从来不是必须恪守的教条，也不存在“没有人告诉我们必须使用开源”。Cusin 总结说，它更像一个指南针，帮我们在这个领域找准了前进的方向。

在演讲结束后，InfoQ 采访了Marcy Paramonova和Stéphane Cusin。

InfoQ：你们采取了哪些措施来赢得平台用户的信任？

Stéphane Cusin：我们在标准化、自动化和运营卓越性方面投入了大量的资源。无论团队将应用部署到开发、测试还是生产环境，都应该拥有相同的体验和预期。我们还明确了平台的职责范围。各团队都清楚地知道哪些服务由平台团队负责运维、可以期待什么样的服务水平，以及自身的运维职责从何处开始。

另一个重要的方面是减轻认知负荷。我们没有将 Kubernetes 的每一项功能都暴露出来，而是尝试提供合理的默认设置和具有明确指导性的工作流，使开发人员应该能够专注于自己的应用程序，而不是去理解底层基础设施的复杂性。

Marcy Paramonova：在推出新组件或新功能时，我们不会等到它们臻于完美才与用户分享。我们会让用户了解我们的工作内容及背后的原因。

事实证明，这种透明度比一个精雕细琢的产品更有价值。用户不再是被动的消费者，而是成了早期测试者和合作伙伴。随着时间的推移，依托这种关系所构建出来的成果，是任何发布公告都无法比拟的。

InfoQ：你们的工程文化随着时间的推移发生了怎样的变化？

Paramonova：开源社区有着独特的文化。他们会记录决策过程，积极回馈社区，并明确责任归属，让人们清楚谁负责维护某个组件、谁负责决策，以及遇到问题时该向谁寻求帮助。

我们试图将这些实践内化。当你采用 Kubernetes 时，你不仅仅是在采用一个容器编排工具，你是在加入一个拥有明确规范、预期和协作方式的社区。这促使我们走向了更大的透明度、更广泛的共同责任感，以及更强的工匠精神。

这种文化的转变并非源于某人宣布了一项文化倡议，而是因为工具要求采取特定的工作方式。随着时间的推移，这种工作方式逐渐成为了我们自己的。

https://www.infoq.com/news/2026/07/open-source-platform/

声明：本文由 InfoQ 翻译，未经许可禁止转载。