私有云：基础平台部门如何为企业内1500名工程师构建PaaS？- srvaroa

基础技术基础架构定义为“ 用于创建，发展和运营我们的业务的软件和系统。”包括云服务，构建工具，编译器，编辑器，源代码控制系统，数据基础架构（Kafka，Hadoop，Airflow…），路由和消息传递系统（Envoy，gRPC，Thrift…），Chef，Consul，Puppet，Terraform等。
达到一定规模的公司通常会创建一个或多个团队来负责这些工具的不同子集。他们被命名为“基础设施”，“平台”，“基础”……在本文中，我将使用“平台团队”。如果您是其中一员，您将知道平台团队的生活很艰难。
很多工作都是要在标准化和自治之间找到适当的平衡。为了产生有意义的影响，平台团队依赖于企业或公司组织内的标准。试图为每种可能的语言生态系统，框架，数据库，消息传递系统等提供支持，这会使平台团队变得过于专注而无法发挥作用。
另一方面，尊重其他团队的自主权来制定自己的技术决策也是明智的。平台化的平台团队可能会冒着光顾的象牙塔式住宅的麻烦，给其他工程团队带来反复无常的选择。标准化和自治是复杂的因素。
如果您将此问题乘以20怎么办？如果您有20家公司提供支持，每家公司都拥有自己的技术，文化，慈善和恐惧症，决策家谱以及自己的平台团队，那么该怎么办！
那是我团队在Adevinta的工作。Adevinta建立了在线市场。他们每个人都需要以自己的方式与众不同。同时，它们都共享许多其他不需要相同的点点滴滴。实际上，如果它们一次构建并由所有人共享，则更具成本效益。其中大部分属于技术基础架构类别。我的团队致力于这种类型的管道。

作为平台团队创造价值
平台部门属于企业的成本中心，这并不意味着它们对公司没有任何价值。相反：Kubernetes集群对于业务至关重要。很难用一幅图解释为什么工程团队应该花费从EC2迁移到Kubernetes，而不是仅仅交付更多可赚钱的功能。从某种意义上说，成本中心为利润中心提供动力。这就是平台团队应该意识到自己受到持续审查（无论是否可见）的原因。企业总是会怀疑，我们为什么要支付这支昂贵的工程师团队？亚马逊，谷歌，微软，数字海洋，Heroku或其他任何人不能提供这些人的服务吗？我们不能利用 由许多商业公司资助的许多开源项目，而在其他地方使用人员吗？
当平台团队（有意或无意）构建具有第三方替代方案的系统时，他们将在不平衡的竞争环境中竞争。 平台团队应真正避免与AWS，Google或任何商业公司竞争，比如他们自己的CI系统是否优于商业的集成系统，市场将以比预期更快的速度赶上来，并使平台团队变得多余。每个平台团队都应该问自己：我们的与众不同之处是什么？我们提供什么比使我们的公司值得投资于我们的团队，而不是让那些工程师投入产品更有价值？
到目前为止，回顾一下：由于平台团队是成本中心，因此他们必须真正专注于制定与业务相关的清晰，现实的价值主张。他们还必须确保其影响对企业而言是可理解的并且是可见的。最后，他们必须确保自己仍属于快速发展的行业。

我们的PaaS
我的团队专注于PaaS，可帮助Adevinta的工程师在云中构建，部署和操作软件。我们主要关注无状态工作负载（例如微服务）。
我们对产品工程师的建议很简单：“ 看，我们知道您在竞争激烈的市场中奋斗。我们的任务是帮助您赢得比赛。您更喜欢自己做管道？我们尊重您。但是，如果您希望将注意力集中在产品上，我们将有一个领域专家团队为您服务。我们会尽力为您提供所需的技术基础架构，以便您专注于赢得比赛 ”。
我们定义了一条黄金之路：减少了一系列精干的，行之有效的工具选择，这些工具可以有效地构建，部署和操作微服务（我们支持的核心系统在下面的左侧幻灯片中）。每个工具在它们的类别中是最好的吗？可能不会。但是我们知道他们可以完成工作，在行业中得到良好的支持，维护和标准化。它不是关于局部最优，而是关于全局最大值。
这也不是要选择一堆随机的零件，而是给产品团队一个类似于宜家的平台，他们必须逐个组装。
我们将GitHub，Travis，Artifactory，Spinnaker，FIAAS，Kubernetes，Prometheus，Datadog，Sumologic，ELK捆绑在一起。

我们提供的主要价值在于类似人体关节或胶水。我们是如何将所有这些系统集成在一起的。我
们的PaaS支持由多个模块化组件组成，试图成为一种 可穿透的抽象。主要好处是：

• 避免输掉与商业公司的战斗。我们每个组成部分背后至少都有一个完整的公司。期望我们能聘请5-7名工程师（占团队的1/4！）来针对拥有20名员工的企业构建内部配置，以替代CI系统，CD系统，指标平台等几乎是不现实的。或50倍的容量。相反，我们注重的是具体针对我们的 公司，裁剪过的，现成的解决方案，我们的需求。商业竞争者更可能将注意力集中在该行业的大部分通用产品上。
• 对于那些不能或不会使用整个捆绑包的团队来说，定义明确的清晰度很重要。这是能够像我们一样支持高度异类的公司和团队的要求。我们经常看到采用其中一种工具的团队如何逐渐逐渐采用其他全部工具，因为他们获得了信任，并意识到我们可以免除他们进行大量无差别的繁重工作的麻烦。
• 相同的灵活性使我们能够在合理的时候更换单个零件，从而对用户的影响最小。我们当前的一项举措是确保升级或切换这些组件对用户完全透明。

冲击小，重复多次
我们使用的策略之一是发现可以引入对整个表面产生较小影响的工具的位置。这在减少开发过程中的工作量方面非常有效。
在将新变更合并到主树中涉及的大多数任务中，可能只有真正需要涉及人脑的两项工作：编写代码和进行审查。我们着手使开发过程中的其他许多琐事自动化：分配审阅者，分析覆盖率和静态分析报告，传播依赖关系更新，使分支机构保持最新，合并已批准的PR ...这些动作中的每一个都可能具有影响很小。但是，乘以数百名工程师的人口，一个月又一个月就能得到规模经济。
等等，您之前说过，我们应该避免与商业公司竞争。 GitHub在今年早些时候发布了Actions，您刚才提到的一些自动化似乎与公共GitHub上的自动化非常相似。这是否意味着您的团队已经过时了？
记住创建差异化因素的要点。使得PaaS的核心功能迟早会变得商品化。但是胶水是另一回事。我们的区别很简单：GitHub动作只能对GitHub事件做出反应。我们的自动化可以对整个Adevinta开发生态系统中的所有事件做出反应。
因为我们没有花太多时间来构建核心工具，所以我们可以专注于胶水。我们的Devhose组件可以从开发生态系统中的每个工具（GitHub，Travis，Spinnaker，Artifactory，JIRA，Slack，Kubernetes甚至是Golden Path之外的几个工具）收集事件，并将其存储在日志中，并在“工程事件总线”中进行广播。我们还围绕它构建了一些工具，使我们能够轻松实现与生态系统交互的新功能。例如，我们最近原型化的一个机器人在Kubernetes中侦听事件，检测到被杀死的Pod，收集故障排除信息并将其发送到Slack通道，以便向拥有该服务的团队发出警报。
多亏了在胶水上的投资，当GitHub Actions达到企业版时，它将带来我们可以利用的价值，而不是存在的威胁。

良性反馈循环
在事件总线中注册和广播我们开发人员生态系统中发生的所有事情，对于多种用途而言非常有价值。其中之一是对开发过程本身建立见解。
我们构建了一个名为Ledger的系统来帮助解决此问题。这是一个事件使用者，它从Devhose的事件总线中读取数据并处理所有类型的生产率指标。我们的参考文献之一是 Accelerate 及其年度“发展状况”报告（2018年， 2019年）。他们的主要主张是软件交付团队的绩效可以而且确实为公司提供了竞争优势。这得到了广泛的行业研究的支持，该研究将特定的实践与开发和交付技术的最有效方法结合在一起。这正是我们团队的使命。
作者确定了捕获开发和交付过程有效性的四个关键指标：变更准备时间，变更失败率，部署频率和恢复时间。这些可用作高级绩效指标，可可靠地衡量组织实现其目标的能力。
因为我们为大多数工程过程提供管道，所以我们在正确的位置进行测量。这是我们有关连续交付的仪表板之一，包括“部署频率”（加速指标之一）。
使用我们PaaS的团队可以立即使用这些技术，包括更多指标：构建持续时间，代码覆盖率，静态分析问题，安全性问题，更改的前置时间，有关代码审查过程的统计信息等。
比如“拉取请求”大小与在其团队中合并的时间之间的相关性：

• 显而易见，小型PR的合并速度更快。实际上，只有几十行的差异使合并时间从几小时到几天增加了一倍。
• 即使合并时间随PR大小而增长，但看起来非常大的PR（最后一个存储桶）合并所需的时间要少得多。您可以猜测为什么。

投资组件
有时我们会投资于平台的组件。
在演讲中，我没有时间讨论 Spinnaker，在那里我们与Netflix，Google，Target和许多其他公司一起（并且一直是）活跃的撰稿人已有4年了。成为社区的一员使我们更容易地获得对我们有意义的上游功能，例如云形成支持或 与Travis的集成，以及数十个错误修复和其他改进。
但是，内部投资的最佳示例是我们在EC2上构建和运营的Kubernetes集群。不可避免的问题是：为什么不使用EKS，GKE或其他托管解决方案？
“胶水”策略应该已经浮现在脑海。
以下是Kubernetes原始安装提供的内容以及集群提供的内容的简化比较。一个简单的Kubernetes集群可以工作，您可以调度容器，但是仅此而已。GKE，EKS等提供的功能比左图略多：它们可以自动缩放节点并处理其他基本操作负担。但是，它们仍然远远不能满足希望安全运行生产工作负载而几乎没有运营负担的产品团队的典型需求。
一些差异例子：
我们的集群是多租户的，允许多个市场安全地共享基础架构，同时通过更高的密度来优化成本。我们处理多租户的所有弊端。我们为每个租户处理网络隔离。我们提供合理的默认值，pod安全策略等。我们向上游贡献的NGINX入口控制器添加了一个验证Webhook ，以减小破坏NGINX配置的入口 爆炸半径。
我们在多个地理区域维护集群。这对于Adevinta的一些中央团队至关重要，这些团队建立了诸如消息传递，信誉系统等集中功能，这些功能将在多个市场中使用，这些市场服务于遥远的地理位置（从欧洲到拉丁美洲）的用户。我们的集群提供了一个统一的，托管的运行时环境，靠近所有可以部署中央功能的市场。
在每个群集中，我们都提供开箱即用的集成。您会利用cert-manager和Let's Encrypt获得自动证书 。用户可以使用通过我们公司的SSO生成的身份验证令牌。他们通过简单的配置选项选择自动获取的指标并将其发送到Datadog或我们的内部Prometheus。日志提供了相同的功能。
用户可以避免学习完整的Kubernetes，而可以使用 FIAAS（基于Kubernetes的商品抽象）。它是在大约7年前在我们的一个市场中内部创建的，并于2019年初进行OSS开发。
在每个群集中，我们定期运行自动金丝雀测试，以部署规范的应用程序并测试连接性和大多数集成，我们尝试比用户更早地发现问题。我们的团队提供专职的24/7/365通话服务。
我们会进行全栈升级。因为Google或AWS可能会升级您的Kubernetes版本，但不会在乎您在那里运行的所有内容的完整性。我们的升级速度比GKE / EKS慢，但何时才能确保群集中捆绑的整个堆栈都能正常工作，而不仅仅是Kubernetes的核心。
并且，我们可以深入了解您的费用（直至pod级别），并通知用户有关过度配置的潜在节省。这是带有此信息的Grafana仪表板的PoC：
在提出明确的主张之前，我已经提出了要点，以便在商品选择商品化后便可以轻松转向商业选择。这是我们与EKS合作的策略。我们密切关注其路线图，并已向AWS提供了有关我们需求的反馈。一旦对我们来说，EKS是适合Kubernetes的基础安装，我们就准备在顶部提升和转移我们的集成。

零摩擦入门
所有这些（可能）非常酷，但是如果工程师需要数周或数月才能开始使用它，没有人会这样做。这是一年前我们面临的最大挑战之一。PaaS的核心组件大部分都在那儿，但是每个团队将不得不花费数天或数周的时间在其存储库上手动配置它们。在过去的一年中，我们在简化入门流程上投入了大量资金。我们将类似于宜家的经历变成了几乎无缝的过程。用户获得一个Web界面，输入其存储库URL，单击一个按钮，然后我们的自动化程序便从那里获取它。他们的存储库需要约10分钟的时间自动配置为CI / CD管道，然后部署到其团队的私有名称空间，并与度量标准和日志记录系统集成。如果某些操作失败或需要我们的平台团队采取手动操作。
这里有一点关于自动化的重要性，但是我想强调一下。如果您认为平台团队与商业公司具有相当大的竞争范围的主张，则 UX用户体验专家是必不可少的。一个足以服务数百名工程师的庞大团队必须为优秀的UX设计人员保留人员。它将得到回报。您不仅将不再向工程师施加后端UI，而且因为平台团队将学习如何理解用户的需求，测试他们的假设（其中大多数是错误的），他们对他们的影响工作，并提供更专业的产品。
负责这些自动化和UI的团队一直在使用入职过程中收集的仪器数据来改善体验，提高故障率并掩盖极端情况。上个季度，他们着手解决平台中的其他难题。例如，对失败的部署进行故障排除。圣诞节后不久，我们计划发布一个团队仪表板，其中包含由给定团队维护的所有应用程序。它总结了每个状态，并突出显示了何时发生构建，部署管道或运行时失败的情况，以及从PaaS中的任何系统收集的相关信息。再次，胶水。

变化很痛，我们也应该感到
无论我们为改善用户的入门体验付出了多少努力，最终，我们都将工程师从已知领域，其内部基础架构EC2或他们今天运行其服务的任何地方转移到了未知领域一。在某个时候，每次迁移都像这样。
发生这种情况时，我们团队中的某人应该和他们一起漂流。
特别针对中型/大型迁移项目，我们至少分配1-2名工程师来支持现场团队。举个例子，我们现在有一个正在进行的迁移项目，该迁移项目旨在从西班牙所有站点迁移约200个微服务。几个月来，我们的团队中的工程师以及西班牙阿德温塔内的本地Platform团队一起坐在一个共享的座位区中。两者共享OKR，定期计划，每周同步等。在我们先前与Subito.it团队的合作中，我们的三名工程师在本季度内前往意大利呆了几个星期。我们还创建了不同的研讨会，供我们重新使用并适应新加入的团队，包括Kubernetes基础知识，动手练习等。
与我们的用户紧密合作有两个关键成果：

• 信任：产品团队中的工程师不再以松懈的态度来感知平台团队中的工程师，但是实际的人却可以放心地向他们提问。市场上的本地平台团队开始将我们视为合作伙伴，而不是存在的威胁。
• 我们平台团队的工程师学习产品工程师的需求，并获得使用我们构建的工具的感受。他们还利用本地平台团队的专业知识，这些团队已经在各自的市场中从事该领域多年的工作。尽管很难离开您的团队数周或数月，但这种经历令人大开眼界，每个人都为我们的团队带来了宝贵的见解。