我和捷克共和国 Komerční banka (KB) 的开发主管兼首席工程师 (COE) Jindrich Kubat 坐下来讨论开源和开发。
Ben Rometsch：您在 KB 的正式职位是什么？
Jindrich Kubat：我的正式职位是 Komerční banka 的开发主管，COE（专业中心）。
Ben：您的职责范围和日常工作具体是什么？
Jindrich：作为开发 COE 的负责人，我考虑的是使数百名开发人员成功进行软件开发所需的专业知识、结构和能力。 我们在更广泛的开发团队中大约有 600 人，但我并不直接负责管理他们。 我负责定义他们将如何完成工作。 因此，对于开发最佳实践、标准统一等等。
Ben：您目前在 KB 的主要关注点是什么？
Jindrich：我们的转型项目。 我们有当前的银行，它建立在典型的传统银行系统之上，这些系统是庞大的、分布式的单体架构系统。 我们的大部分开发人员（约 400 人）每天都在那里工作，因为它为银行创造了大部分收入。
除了传统应用程序之外，我们还决定完全现代化，采用我们称之为“数字中心”的东西，它正在取代银行当前的 инфраструктура。 前端应用程序是原生移动和 Web 应用程序。
数字中心和新的前端应用程序完全建立在微服务之上，因此我们必须重新设计很多东西，并为人们引入新的指南。 所有这些加在一起就是我们所说的“新数字银行”。 这是一个庞大的项目！
Ben：这种转型会在某个时候停止吗？
Jindrich：我们从两个主要部分考虑转型
- “新数字银行”计划为期 5 年，我们已经进行了大约 2.5 年。 它最初规模很小，只有少数团队准备采用最现代化的开发方法，并且每年都在增长。 今天，我们大约有 180 名工程师分布在 50 个团队中。 这些团队是从外部聘用的，或者从遗留系统转移过来的。 他们 100% 致力于“新银行”的工作。
- 另一方面是文化转型。 我们称之为“敏捷 2.0”，它适用于整个团队（包括遗留系统和新系统团队）。 采用敏捷和 DevOps 完全是采用一种新的工作方式。 我们也在推动遗留系统团队进行这种转变。 虽然构建会在某个时候结束，但希望新的文化能够扎根，并成为 KB 的新工作方式。
[ 接下来阅读： 敏捷采用：6 个战略步骤 ]
Ben：除了敏捷之外，你们还采用了其他新的方法吗？
Jindrich：是的，我们采用了三种新方法
- 转向 OKR，这与敏捷非常吻合。
- 我们为所有会议采用了一个协作聊天应用程序，这有助于远程工作。
- 我们有功能性的“部落”，其中包含每个部落开发和运行自己的项目或自己的应用程序所需的人员和技能。 这与我们正在转向的微服务架构非常吻合。
Ben：那么工具、语言和基础设施呢？ 您如何管理这么多人和团队？
Jindrich：作为 COE，我们主要负责统一人们的工作方式。 我们在这方面非常严格。 我们开发了自己的 KB 框架，我们称之为 Speed，它分为三个部分
- 首先是一个 Java SDK，建立在 Spring Boot 之上，Spring Boot 是一个用于构建云应用程序的框架。
- 然后，CI 和 CD 管道用于自动化部署。 这是建立在 Jenkins 和 Argo CD 之上的。
- Kubernetes 用于部署和运行我们的应用程序。
我们构建了自己的云基础设施，所以今天一切都必须在本地。 如果一个团队需要什么东西，他们需要提出要求，并由我的团队审查。 如果我们有解决他们问题的东西，那么我们会要求他们使用它。 如果没有，我愿意采用一项新技术。
我们从两三年前开始使用 Speedy Framework，它仍在不断发展。 第一个版本是为单体应用程序和单体工作构建的。 我们现在是第 4 版。 微服务方法在第 3 版中实现。
缺点是我们必须遵循一些产品更新和生命周期，这对我们来说真的很痛苦。 例如，Kubernetes 每年有三个主要版本。
展望未来，我们希望使其更加独立于这些周期，并在未来实现升级自动化。 有趣的是，我们的母公司采用了 OpenShift，我们正在密切关注它。 我们将看看未来是否统一这些框架。
Ben：听起来您在新平台中使用了大量的开源技术。 您一直都这样做吗？
Jindrich Kubat：不，我们使用了大量典型产品，如 Oracle 和 Sun Microsystems。 对于新的数字银行，我们决定采用更多的开源技术，如 Kafka 和 Flagsmith。 这很好，因为它们是免费的，但我们负责保持它们的运行。 这对团队来说是一种全新的心态。
Ben：您必须争取在内部使用这些产品吗？
Jindrich：不，他们只是接受了，因为他们知道原因。 如果我们向他们展示与 Oracle 的合同，它有多贵，那么采用开源就有一个很大的商业案例。 即使您必须有更多的人来管理 инфраструктура，它也会对我们的成本产生积极影响。
Ben：那么功能标志呢？ 这是您在开始之前就知道需要的东西吗？
Jindrich：这是一个好问题，因为，你知道，即使在当前的银行（遗留系统）中，人们也在使用功能标志，但他们已经开发了自己的系统。 它们是非常简单的系统，用于管理配置文件。 这仅仅是因为遗留系统每年只部署 3 次。 所以你可以想象，要兑现其他团队的所有承诺是多么困难。 因此，它们实际上只是为了保持企业发布管理和测试的按时和协调。 很容易打开或关闭一些尚未准备好部署的功能。
但是对于新的数字银行，我们有微服务和持续集成。 我们每天都部署到非生产环境。 有趣的是，我们只有两个非生产环境。 其中一个仅用于构建期间的测试，另一个是最终的非生产环境（暂存）。
Ben：减少环境是一个有意识的决定吗？
Jindrich：是的，这是我带到银行的一种方法，我们完全重新设计了一些环境以及我们如何部署它们。 目标是尽快投入生产，以尽可能保持生产和非生产环境的接近。
Ben： “圣杯”是只有一个环境——生产。 肯定这在您的业务中是不可能的？
Jindrich：我在这方面有一些经验，你只需在生产中测试一切。 但在银行业，这是不可能的。 我们的许多开发人员甚至无法访问生产环境。 有规定。 例如，一项规定说你不能在生产环境中拥有一个测试帐户，因为你是在用真钱操作。 在生产中一切都必须是“真实的”。
Ben：您如何减轻这种情况？
Jindrich：尽可能减少非生产环境的数量。
Ben：当您选择功能标志系统时，您是否考虑过 SaaS 服务，还是您立即将其排除在外？
Jindrich：是的，我们决定评估三个系统。 Flagsmith、LaunchDarkly，以及我们自己构建一个。 我们做了三个“概念验证”。 首先是 LaunchDarkly，然后是 Flagsmith，然后我们研究了我们自己的自建系统。 我们决定选择 Flagsmith 不仅仅是因为系统的灵活性，还因为出色的支持。 你们是开源的以及出色的文档也帮助了我们的决定。
Ben：现在功能标志的进展如何？
Jindrich: 我们已经在非生产环境中使用特性开关一年了，效果很好。至于生产环境，从安全的角度来看，在生产环境中实施特性开关花了一些时间。之所以花了这么长时间，是因为最初负责将特性开关引入 KB 的人离开了。然后安全团队改变了他们的评估标准。最终，经过三次尝试，我们通过了所有的渗透测试和要求，成功地将其部署到生产环境中！
Ben: 在银行做出改变可不是一件容易的事！
Jindrich: 是的，由于安全标准，整个银行业对此非常敏感。现在我们已经启动并运行，专注于权限模型，并记录一切，以便可以进行审计。
Ben: 这改变了你的工作流程吗？
Jindrich: 是的！我们决定从前端开始，特别是移动团队。人们一直在等待这种能力，因为他们在以前的角色中使用过特性开关。我们团队中有人在推动采用，因为如果没有特性开关系统，一切都必须等到完全完成后才能进行。现在他们可以将部署到生产环境，并且有更多的团队正在加入 The New Bank。对于那些采用微服务架构的团队来说，团队能够更加独立至关重要。
到目前为止，我们大约有 85 名工程师在生产环境中使用 Flagsmith。这几乎已经是 The New Digital Bank 的一半了！
Ben: 你在服务器端也使用特性开关吗，还是仅仅在前端使用？
Jindrich: 目前只在前端使用，但我们正准备将其推广到利用微服务的后端系统。这将很快实现！
Ben: 未来你还想以什么方式使用 Flagsmith？
Jindrich: 是的。我们正在考虑将 Flagsmith API 集成到我们的 Bug 追踪器中，以便能够向上游推动问题，并使 QA 团队与产品负责人保持一致。
评论已关闭。