在 N26，在生产环境中仅需一小时即可完成启动一个新的服务，包括所有必要的基础设施依赖项、功能，以及专用的数据库集群，并且其 API 可以用于通过身份验证的请求。在激烈竞争的金融市场中，迅速推出新产品和服务对于吸引和保持客户尤为重要。

当前，初创企业在融资方面的关注点已经从追求快速交付转变为关注生存能力和盈利能力。初创企业需要更加注重预测客户需求，而不是通过不断试错来吸取经验教训。

平台工程之所以如此受欢迎，是因为它对于提高产品团队的效率非常关键。强大的平台通过自动执行重复性任务以及处理安全性、合规性和可观测性等跨领域问题，消除了处理基础设施的痛苦。

经过两年的努力，我们的平台工程战略取得了成效。在 2022 年 DevOps 现状报告中，我们的表现优于金融服务行业 97% 的受访者。现在，让我们一起来了解一下 N26 的平台是如何运作的，也希望我们的平台工程之路能够为您提供一些实用的见解。

根据2023年7月的数据，我们的软件工程师保持了每两天至少一次的部署频率。每次部署的平均耗时为9分钟，准备工作非常高效。而且仅有1.2%的部署发生事故，变更失败率极低。即使发生故障，我们的团队也能在平均21小时内完成恢复工作，保障系统平稳运行。

01 平台工程文化的重要性

2021年7月，我们致力于制定 N26 巴西企业的工程战略，积极投入了大量的努力，以交付一款专为巴西市场定制的首个移动应用程序的首次迭代版本。与我们在欧洲市场的扩张不同，巴西市场对我们来说需要重新构建一切。考虑到巴西中央银行（BACEN）制定的严格规定，我们的首要目标是测试运营效率，并建立必要的基本框架。为了确保产品的质量和稳定性，我们最初仅内部测试，并限制了内测版的使用人群为亲友和熟人。

这个新的项目虽然看起来很幸运，但实际情况并非如此。当我加入 N26 时，所有的产品和工程工作都是通过外包进行的，我们甚至需要依赖合作伙伴的基础设施来支持我们的工作。

我们的第一个应用程序版本已经通过了内部测试，这个版本已经达到了我们的要求。然而，在竞争激烈的新银行市场中，我们需要做的更多。我们致力于为客户提供独特的价值主张，这要求我们的专业员工不断学习，并提供切实可行的解决方案来解决客户的实际问题。

当时的工程团队中一共有五人。我们展开了三天的研讨会去确定战略和文化，由于我们即将扩大工程团队规模，需要为下一阶段的运营做好准备。因此，在加快生产力的同时，快速招聘和入职人员是一项具有挑战性的工作。

在我们讨论原则时一直在重复责任的重要性，我们希望 N26 有一支自主和负责任的团队，并且积极维护其交付的成果。这种方法允许团队与其应用程序的运行方面和客户进行互动，创建反馈回路，从而交付高质量的产品。这种方式就是 "you build it, you run it"。

此外我们还确定了其他原则，就是将所有基础设施抽象为一个平台，以及利用成熟的管理实践（如产品管理）来有效管理我们的工程部门。因此，平台工程成为了我们企业文化不可分割的一部分。

02 战略规划

为了更好地推动战略规划，我们通过影响地图（Impact Mapping）来探究四个问题：为什么需要平台工程、谁是用户、如何实施以及具体做什么。重要的是要明确为什么我们要这样做，因为只有了解了目标，我们才能更好地应对突发状况。

我们的业务计划在客户增长方面取得了积极反馈，到2022年底，我们的团队计划扩大20倍，人数从5人增加到100人。在短短1.5年内实现巨大增长，除了实力雄厚的平台，还需要卓越的开发者体验。

对于 "为什么需要平台工程？"这个问题，我们的答案是因为希望开发人员在 Day 1能轻松部署。但是，在讨论我们需要开发哪些功能来实现这一目标之前，我们先讨论了谁会受到这一目标的影响。也就是“谁是我们的用户？”

我们对 "谁是我们的用户？"这个问题的回答是产品工程师。作为工程部门，我们对业务的主要贡献是为团队配备足够的人员，并使他们富有成效。这些团队将通过解决客户的具体问题直接为业务做出贡献。然后，我们跟进了解希望产品工程师具备哪些行为，以帮助我们实现预期目标。

在回答"怎么做？"这个问题时，我们关注两个方面。首先，我们期望产品工程师能够负责并维护他们所开发的产品，确保产品的稳定性和可靠性。其次，我们希望他们能够从 Day 1 开始就提高工作效率，为公司创造更多的价值。这些是我们想要实现的目标。最后，我们一起讨论了采取哪些措施来支持我们期望产生的影响。

我们提供了一份功能列表，以回答“要做什么？”的问题。这些功能是根据预期效果和业务目标而定的、完全适应具体情况的功能。此外，我们还提供非技术性功能，例如入门指南和文档索引，以更好地满足用户的需求。

在充分理解了我们的战略重要组成部分之后，再来聊聊对产品工程师的体验有什么规划和期望。

03 绘制开发人员体验图

我们的影响地图呈现了两个特征，这两个特征进一步强调了基础架构的抽象原则（即将基础架构的底层细节进行抽象化，以便产品工程师更好地应用）以及我们在文化中设定的同质性和一致性原则。我们需要思考向产品工程师提供怎样的开发者体验才是我们希望达到的目标。

我之前曾在一家新银行工作过，这家银行拥有近 2000 万客户和 350 多项服务。少数几个知道新服务供应所需步骤的人很自豪。平台工程非常强大，但开发人员体验的这一部分缺乏自助服务功能。我记得有人说过，由于大量未记录的手动工作，平均部署一个新服务到生产环境需要至少两周的时间。

你能想象要等三个月才能有一个工作环境来部署服务吗？Rafay Systems 最近的一项研究发现，每四家企业中就有一家需要三个月或更长时间才能将应用程序或服务从代码完成阶段部署到生产阶段，9%的企业需要六个月或更长时间。这是一种巨大的资源浪费。

因此我们需要考虑优化配置流程，以实现快速将新的服务部署到生产环境，并能够在入职培训时进行演示。为了减轻产品和平台工程师的配置工作负担，我们提出了一套简化流程，让产品工程师能够轻松完成配置工作。

我们希望平台将通过自动化来解决配置问题，这是一种类似 PaaS 的体验：产品工程师只需要在一个代码仓库中提交包含 yaml 代码的拉取请求，该代码仓库就可以编排在云环境中启动新服务的过程。

在拉取请求批准后开始准备生产环境，包括集群管理、配置数据库、设置消息基础设施等。先基于服务框架创建代码仓库，并进行首次部署以确保环境配置正确，然后产品工程师克隆新创建的服务代码仓库。每当将代码推送到主干分支时，就会自动将服务部署到生产环境。

有了对开发人员体验较为全面的了解和认识，接下来我们会在第二部分深入探讨平台需要构建的内容。