我们是怎样为 1500 名工程师构建一套 PaaS 平台的？

技术基础架构，这个词最早是我在 Will Larson 的演讲上听到的。啥叫技术基础架构？他这样定义：用于创建、发展和运营我们业务的软件和系统。这里面包括云服务、构建工具、编译器、编辑器、源代码控制系统、数据基础架构（Kafka、Hadoop、Airflow……）、路由和消息传递系统（Envoy、gRPC、Thrift……）、Chef、Consul、Puppet、Terraform……

那些达到一定规模的公司，通常会创建一个或多个团队来负责这些工具的不同子集。这些团队被命名为诸如“基础设施”、“平台”、“基础”…而我用“平台团队”（Platform team）这个名称。

如果你是其中一员，你肯定知道平台团队的生活很艰难。这就是一支平台团队的日常状态（下图）。

Pieter Brueghel the Elder——“死亡的胜利”（1562）

到头来，很多工作都要在标准化和自治间找到适当的平衡。为了产生有意义的影响力，平台团队依赖组织中的标准。如果试图为所有可能的语言生态系统、框架、数据库和消息传递系统等提供支持，就会使平台团队的精力太过分散，难以发挥作用。

另一方面，尊重其他团队的自主权，允许他们制定自己的技术决策也是明智之选。强势的平台团队可能目空一切，把什么事情都想得太过完美，结果会给其他工程团队带来一堆反复无常的选项。标准化和自治都是复杂的取舍因素。

如果你将这些问题乘以 20 会变成什么样子？如果你需要为 20 家公司提供支持，每家公司都拥有自己的技术、文化、偏好和恐惧的事物、决策树甚至是自己的平台团队，那会是怎样的光景！

这就是我在 Adevinta 团队的工作。

Adevinta 建立了许多在线市场（Marketplace）。每个市场都需要有自己的独特之处。同时，它们在不需要特立独行的方面共享许多相同事物。实际上，如果这些事物只构建一次并由所有市场共享，就会大大节省成本。这些事物中大部分属于技术基础架构类别。我的团队就致力于开发这种类型的管道。

作为平台团队创造价值

如果说上图是利润中心，那么下图则是成本中心。

利润中心往往具有清晰易懂的价值主张，而成本中心则相反。但是，这并不意味着后者对公司没有任何价值。

相反：对业务而言，Kubernetes 集群至关重要。你很难向第一张图的人们解释，为何工程团队应花时间从 EC2 迁移到 Kubernetes 上，而不是专心开发更多赚钱的功能。

从某种意义上说，成本中心在为利润中心提供动力，前者价值就体现在这。这就是为何平台团队应意识到自己受到持续审查（无论是否可见）。

企业总会怀疑，为何要为这支昂贵的工程师团队支付薪水？

亚马逊、谷歌、微软、Digital Ocean、Heroku 或其他人提供的服务难道不能取代这些人的工作吗？

我们难道不能利用由商业公司资助的开源项目，然后腾出人手做其他事吗？

在 2020 年，技术基础设施会成为一个热门市场。当我演讲时，亚马逊 AWS 正在拉斯维加斯举办Re:Invent年度大会。大会第一天，他们宣布推出量子计算即服务。

就像这样：

所以，当平台团队做自己的季度演示时，那种感觉简直是小巫见大巫，令人绝望：

别误会我的意思。这些内部演示的确很棒，他们付出许多努力。

但是，当平台团队（有意或无意）构建具有第三方替代方案的系统时，他们将面临一个不平衡的竞争环境。

平台团队真应该避免与 AWS、谷歌或任何商业公司竞争。即使他们自己开发的 CI 系统优于$commercial_ci_system也没意义。

市场迟早会赶上来，速度比人们预想得更快，结果让这支团队显得很多余。每支平台团队都应该问自己：

1.我们有什么与众不同的东西？

2.我们提供的哪些东西让公司值得投资团队，而不是将这些工程师转到产品开发岗位上？

我们回顾一下。由于平台团队是成本中心，因此他们需真正专注制定与业务相关的清晰且现实的价值主张。他们还必须确保自身的影响力对企业而言是可理解且可见的。最后，他们必须确保这些特性跟得上快速发展的行业。

我们的 PaaS

我的团队专注开发一套 PaaS 平台，可帮助 Adevinta 的工程师在云中构建、部署和运营软件。

我们主要关注无状态负载，例如微服务。

我们针对产品工程师的宣传很简单：

“看，我们知道你们在竞争激烈的市场中努力奋斗。我们的任务是帮助你们赢得比赛。你们更喜欢自己来做管道？那是你们的选择，我们尊重它。但是，如果你们希望将注意力集中在产品上，我们会有一个领域专家团队为你们服务。我们会尽力为你们提供所需的技术基础架构，以便你们专注赢得比赛。”

我们定义出一条黄金路线：

这是精选出的一套出色和经过验证的工具，这些工具可以有效地构建、部署和运营微服务。工具包中的每个工具都是其所在分类中最好的吗？可能不是。但是我们知道它们可以完成工作，能得到良好的支持和维护，还符合行业标准。目标不是做到局部最优，而是全局最大化。

我们挑选的也不是一堆随机零件，而是给产品团队一个类似于宜家的平台，让他们一件一件自己组装起来。

我们将 GitHub、Travis、Artifactory、Spinnaker、FIAAS、Kubernetes、Prometheus、Datadog、Sumologic 和 ELK 打包在一起。

我们提供的主要价值都体现在连接、枢纽和胶水里，体现在我们将所有这些系统集成在一起的方式中。我们的 PaaS 由多个模块化组件组成，试图成为一种可穿透的抽象。

它的主要好处有：

不会在竞争中输给商业公司。我们每个组件背后至少都有一整家公司。我们不能指望就靠 5-7 名工程师（占团队总人数的 1/4！）来构建内部的 CI/CD 系统和指标平台等选项，却要满足 20-50 倍人数的业务需求。相反，我们专注于自己公司特有的事务，将现成的解决方案根据我们的需求再做定制和适配。市场上的服务商则更可能专注于行业中大多数的需求来制作比较通用的产品。

对那些无法或不会使用整个服务包的团队来说，良好定义的枢纽就成了他们的救星。为了像我们一样支持高度多样化的公司和团队，这种需求是必须满足的。但这对我们也有好处，因为它可以提高采用率，并为整套 PaaS 创造低摩擦的“入门良药”。我们经常看到有团队先是采用了一种工具，之后逐渐自然而然地用上更多服务，因为他们对我们产生信任，并意识到我们可以将他们从大量重复繁重的工作中解放出来。

这种灵活性使我们能在需要时更换单个零件，同时对用户的影响控制在最小水平。我们当前的一项举措是让升级或切换这些组件的行为对用户完全透明。

小规模的影响，多次重复

我们使用的一项策略是找出一种位置，在这种位置上引入工具时对宏观层面产生的影响较小。这种策略可以显著减少开发流程中的工作量。

在大多数需要将新更改合并到主树的任务里，可能只有两项工作真正需要人脑参与：那就是编写代码和审查代码。

我们设法让开发流程中的其他琐事都尽量自动化处理：分配审查者、分析覆盖率和静态分析报告、传播依赖项更新、使代码分支保持最新状态、合并已批准的 PR……每个动作的影响都可能很小。

但这些影响在数以百计的工程师手中日积月累，就能产生足够大的规模效应。

上图是服务用户的配置文件，其在我们内部的 GitHub Enterprise 实例中执行所有这些动作。假设每个动作的价值为 1 分钟（实际上很多动作节省的时间更久），一年下来就能节省 62 个工程师工作日。这种影响可以很容易地转化为金钱，转化为其他业务可以理解的术语。

此时，你的脑海中响起警笛声。“且慢，你上文说过我们应避免与商业公司竞争。GitHub 在今年早些时候发布Actions，你刚提到的一些自动化操作似乎与 GitHub 上的自动化服务非常相似。这是否意味着你的团队已经过时了？”

记住，关键在于创建差异化要素。PaaS 的核心功能迟早会商品化。但是，胶水是另一回事。

我们的差异化要素很简单：GitHub 动作只能对 GitHub 事件做出反应。相比之下，我们的自动化动作可以对整个 Adevinta 开发生态系统中的所有事件做出反应。是所有的事件。

因为没花太多时间来构建核心工具，所以我们可以专注于胶水（the glue）。上面的幻灯片展示了 Devhose，它是一个组件，可从我们开发生态系统中的每个工具收集事件，将其存储在日志中，并在一个“工程事件总线”中广播出去。

我们还围绕它构建一些工具，让我们能轻松实现与生态系统交互的一些新功能。

例如，我们最近开发的一个原型机器人能在 Kubernetes 中侦听事件，检测到被杀死的 Pod，收集故障信息并将其发送到一个 Slack 通道，以便向拥有该服务的团队发出警报。

多亏我们在胶水上所做的投入，当 GitHub Actions 发布企业版时，它将带来可以被我们利用的价值，而不是对我们产生威胁。

良性反馈循环

将开发生态系统中发生的所有事都在一条事件总线中注册和广播的做法，为许多用途带来价值。其中之一是在开发流程内建立洞察力。

我们构建一个名为 Ledger 的系统来帮助解决这个问题。这是一个 event consumer ，它从 Devhose 事件总线中读取数据并处理所有类型的生产指标。哪些指标呢？我们的一个参考是Accelerate和其年度“DevOps 现状”报告（2019）。

他们的主要观点是软件交付团队的绩效可以而且确实为众多公司提供竞争优势。这一看法得到一份行业研究的支持，该研究将特定实践与开发和交付技术的最有效方式链接在一起。

这正是我们团队的使命。

作者确定评价开发和交付流程效率的四大关键指标：更改前置时间、更改失败率、部署频率和恢复时间。这些可用作高级绩效指标，以可靠地衡量组织实现其目标的能力。

因为我们为大多数工程流程提供管道，所以我们要测量这些指标是非常方便的。下面是我们关于持续交付的一个仪表板，其中包括“部署频率”（Accelerate 指标之一）。

使用我们 PaaS 的团队可以直接使用它们和其他众多指标，包括构建持续时间、代码覆盖率、静态分析问题、安全性问题、更改的前置时间、有关代码审查流程的统计信息等。

我特别喜欢“Code”选项卡，它显示了 PR 大小与在团队中合并它们所需时间之间的相关性。下面是一个例子：

你肯定至少注意到两个有趣的细节：

• 很明显，小型 PR 合并得更快。实际上，只不过几十行的大小差异就能让合并时间从几小时增长到几天。

• 虽然合并时间随 PR 大小而增长，但看起来非常大的 PR（最后一个存储桶）合并所需的时间要少得多。你可以猜猜这是为什么。

这个例子很好地说明 Ledger 如何帮助我们改善最佳实践，同时不会导致冲突，不需要强制举措，也不会引起工程师的反感。

我们没有摆出任何道理。我们展示了超过两年的数据，这些数据可用于整个团队乃至整个公司，但绝不会暴露个人的身份信息。

我们关心是团队的绩效，而不是$engineer负责多少代码覆盖点。这不是管理人员用来衡量绩效的工具，而是帮助团队了解他们的流程，并做出相关的明智决策工具。

同样问题是，这与SonarQube之类的工具有重叠吗？当然有，但是我们有差异化要素。我们可以分析开发流程中的所有内容，而不仅仅是代码质量。

我们可以为团队量身定制最适合的部署和发布流程。我们还可以使用适用于 Adevinta 组织结构图的组织信息来丰富数据，并将质量与流程中的其他阶段关联起来。我们能按需重新处理超过 2 年的原始数据，并在处理它们时生成新的统计信息（或修正错误。

Accelerate 报告指出，这些指标可以用两种方式来利用。团队能通过这些指标获知其软件交付水平的改进情况，而组织则可以学习如何通过非技术领域的利益相关者能理解的指标来支持工程生产力。

换句话说，提供这些指标后，我们促进了技术与业务间，成本与利润中心间的交流。正因为我们衡量团队的生产力，所以也可以衡量我们的工作能在多大程度上实现自身的使命：支持团队交付最佳产品。

投资组件

有时我们会在平台组件上进行投资。

我们内部投资的最佳实践是，我们在 EC2 上构建和运营的 Kubernetes 集群。很显然，面临的一个问题是：为什么不用 EKS、GKE 或其他托管解决方案？

这时，又应该想起“胶水”策略。

以下是 Kubernetes 原始安装提供的内容和我们集群提供内容的简化对比。

一个 bare Kubernetes 集群也能用，你可以用它调度容器，但也仅此而已。GKE、EKS 等提供的内容比左图略多：它们能自动缩放节点并处理其他一些基本操作。

但是，对于希望安全运行生产负载，同时几乎不想要运营负担的产品团队来说，这些服务仍然远远不够满足他们的典型需求。

一些例子：

我们的集群是多租户，允许多个市场安全地共享基础架构，同时通过更高的密度来优化成本效率。

我们不仅负责应对多租户的所有弊端，而且为每个租户处理网络隔离。同时，我们还提供合理的默认值和 pod 安全策略等。

此外，我们向上游贡献的NGINX Ingress控制器添加了一个验证 webhook，以减小 Ingress 对 NGINX 配置的破坏范围。

我们也负责维护分散在多个地理区域的集群。对 Adevinta 的一些中心团队来说，这是非常重要的，这些团队构建了诸如消息传递和信誉系统等中心化功能，这些功能会用在多个市场中，服务地理上分布广泛（从欧洲到拉丁美洲）的用户。

我们的集群提供一个统一的、托管的运行时环境，靠近所有市场，这样中心化的功能就可以部署在这个环境上。

在每个集群中，我们都提供许多开箱即用的集成。你可以获得利用了cert-manager和Let’s Encrypt的自动证书功能。用户能使用我们 SSO 生成的身份验证令牌。他们通过简单的配置选项选择自动获取的指标，并将其发送到 Datadog 或我们的内部 Prometheus 上。日志这边也提供相同的功能。

用户无需学习完整的 Kubernetes，就能使用FIAAS，它是 Kubernetes 上的一种商品化抽象。它是大约 7 年前在我们的一个市场内部创建的，并于 2019 年初上了 OSS。

在每个集群中，我们定期运行自动金丝雀测试，以部署规范的应用程序并测试连接和大多数集成，我们尝试比用户更早发现问题。

我们会做全栈升级。因为谷歌或 AWS 可能会升级你的 Kubernetes 版本，但不会在乎你那里运行的所有内容是不是能保持完整。我们的升级速度比 GKE/EKS 要慢，但升级时会确保集群中打包的整个堆栈都能正常工作，不会只关心 Kubernetes 的核心。

并且我们能深入探索你的成本节省空间（直至 pod 级别），并在用户过度配置时通知他们潜在的节省空间。下面是带有这些信息的一个 Grafana 仪表板的 PoC：

之前，我也提到过一种策略，就是创建一些枢纽组件，以便在市面上出现可选的商业方案后用这些枢纽作为支点与那些方案对接起来。

我们针对 EKS 使用了这种策略。我们密切关注他们的路线图，并向 AWS 提交反馈来表达需求。当 EKS 成为适合我们情况的 Kubernetes 基础部署时，我们已经做好准备将集成转移过去。

零摩擦上手

所有这些（可能）都很酷。

但如果工程师们要花费数周或数月的准备时间才能使用，那估计没人会感兴趣。这是一年前我们面临的最大挑战之一。

PaaS 的核心组件大部分已就绪，但每支团队不得不花费数天或数周时间在自己的存储库上手动配置它们。

去年全年，我们投入大量资源来简化入门流程。我们将类似于宜家的体验变成几乎无缝的流程。用户访问一个 Web 界面，输入自己的存储库 URL，单击一个按钮，然后我们的自动化流程就能接手剩下事宜。

他们存储库只需约 10 分钟的时间就能自动配置好 CI/CD 管道，然后部署到他们团队的私有命名空间上，并与指标和日志系统集成就绪。

如果出现什么问题，或者需要我们平台团队采取一些手动操作，那么上手工具会给出通知，在 JIRA 中跟踪该问题，并在我们解决问题后继续流程。

这里可看出自动化的重要性，但是我想强调的是其他要点。如果你也认为平台团队与商业公司在很大的范围上存在竞争关系，那么 UX 空间专家是必不可少的。

一支足以服务数百名工程师的庞大团队必须有优秀的 UX 设计人员。这种投入是值得的。这样一来，你用不着再把后端做的 UI 推给你的工程师，而且平台团队也能学习如何理解用户的需求，知道怎样测试他们的假设（大多数假设是错误的），理解他们工作的影响力，并提供更专业的产品。

负责这些自动化和 UI 的团队一直在使用上手流程中收集的监测数据来改善体验，降低故障率并覆盖边缘情况。

上个季度，他们开始着手解决平台中的其他难题，例如对失败的部署进行故障排除。圣诞节后不久，我们计划发布一个团队仪表板，其中包含由给定团队维护的所有应用程序。

它提供了每个应用的状态概述，并高亮显示构建、部署管道或运行时出现的失败情况，同时提供从 PaaS 中所有系统收集到的相关信息。

改变是有阵痛的，我们也应该感同身受

无论我们为改善用户的上手体验付出多少努力，不管怎样，我们都是将工程师们从他们熟悉的领域，他们的内部基础架构、EC2 或他们之前运行服务的各种位置转移到未知领域。

任何迁移工作迟早都要面对这个痛点！

ThéodoreGéricault——美杜莎的木筏。（1819）

发生这种情况时，我们团队中应该有人出来和他们一起“激流勇进”。

特别是对于中型/大型迁移项目而言，我们至少会分配 1-2 名工程师来支持现场团队。

举个例子，我们现在有一个正在进行中的迁移项目，旨在从西班牙的所有站点迁移约 200 个微服务。几个月以来，我们的团队中的工程师以及西班牙分部的本地平台团队都坐在一起办公。双方共享 OKR、定期计划和每周同步等。

在先前与Subito.it团队的合作中，我们三名工程师在那个季度中前往意大利呆了几个星期。我们还创建了许多可以重用的研讨班，并针对新上手的团队做了针对性适配，其内容包括 Kubernetes 基础知识和动手练习等。

与我们用户的紧密合作带来两个关键成果：

• 信任：产品团队中的工程师不再把平台团队中的同事当成只会回复 Slack 消息的外人，而是可以放心提问的熟悉脸庞。各个市场中的本地平台团队开始将我们视为合作伙伴，而不是某种威胁。

• 我们平台团队的工程师学习产品工程师的需求，并获取后者使用我们构建工具的感受。他们还能利用本地平台团队的专业知识，后者已经在各自的市场中从事该领域的工作很多年。虽然离开你自己的团队数周或数月是很艰难的事情，但这种经历令人大开眼界，每个人都为我们的团队带来了宝贵的见解。

这样的做法行得通吗？

本质上来说，这是一条遍布荆棘的道路，但成果确实可见。那么，我们怎样衡量结果？

如上所述，类似 Accelerate 提出的那类指标应该是很有用的，因为它们可以精确衡量我们希望改进的属性。在获得专业产品管理顾问Itamar Gilad的帮助后，我们设置了每周成功部署这个指标作为我们的北极星。

我们认为，这是我们要培养生产习惯的良好代表：部署简单且自动化，成果可以尽早到达用户，可以快速修复缺陷。

对我们而言，更频繁的部署有两个积极影响：更多的服务使用我们的 PaaS，而使用它的服务则通过更频繁地部署来提高生产效率。我们仅计算“成功”部署的数量，以确保我们的工具能帮助并激励健康代码的发布。

下面是过去一年中我们的北极星跟踪仪表板记录（右侧的下降部分只是最后一个未完成的周期。）

本季度，我们花了一些时间收集一系列影响北极星的指标（例如活动仓库的数量、构建工期等），这些是定义良好 OKR 的基础工作。

来自用户的反馈更难量化，但更容易理解。

我们还有很多粗糙的边缘和改进的潜力，但看起来我们正走在正确的道路上。

英文原文：

Talk write-up: “How to build a PaaS for 1500 engineers”