本文翻译自 Architecture and Design Considerations for Platform Engineering Teams 。

究竟什么是平台？它是内部开发人员平台、开发人员自助服务门户还是仅仅是开发人员入职工具？

平台工程并不是一个新概念，在谷歌、亚马逊、Facebook、Netflix 和许多其他大公司中已经存在了很长时间。对于任何大型产品工程团队而言，平台是一组标准服务、框架和模式，最初由一个或多个团队开发供其使用，组织的其他团队可以利用这些服务、框架和模式。

工程组织的其余部分要么使用这些平台服务来开发其他应用程序或服务，要么用作内部工具。

产品团队过去常常在开放源、商业框架和平台服务，以及工具尚不可用时，自行构建许多这样的共享服务和工具。一个很好的例子就是 Google 的内部容器管理平台Borg，后来成为了 Kubernetes。

另一个很好的例子是 Kafka，它是 LinkedIn 最初为内部使用而构建的开源消息传递平台。同样，Amazon Web Services (AWS) 的 S3 和 EC2 最初是为内部使用而开发的，后来成为 AWS 公共云的核心基础。

由于这些平台、框架和工具作为开源或商业产品的可用性，平台团队不再需要为应用程序开发或自助服务云基础设施构建它们。

在云原生应用开发、部署和管理的背景下，平台到底是什么？它是内部开发者平台，开发人员自助门户，开发体验工具，还是简单的开发人员上手工具？除了开发人员之外，还有没有其他使用此平台的用户？

答案似乎对所有问题都是“是的”。我们现在提到的平台是所有这些的组合。由于大多数基础服务可以作为开源或商业产品，或二者兼而有之，因此平台工程团队的主要目标是使这些服务和工具变得易于发现、可自助使用，并通过API、UI、自助门户、Terraform等标准接口更易于使用。

例如，平台团队可以将集群或容器作为服务提供给他们的最终用户，这样每个业务单元或应用程序团队就不必配置或管理 Kubernetes 基础设施。另一个例子是应用部署作为服务，其中平台团队通过提供如 Argo CD 之类的工具作为服务来自动化应用程序部署过程。

为了最终取得成功，平台团队不仅要解决自己的开发人员用例，还要解决其他内部团队的用例。

在背后，平台团队可能会利用各种商业或开源框架，并增加一些自定义自动化功能。尽管开发人员是平台的主要内部用户，但 SRE、安全、产品支持和 FinOps 等其他团队也可以从平台中获益。

这样的一个平台可能拥有一个或多个用户界面，开发人员和其他内部用户可以轻松地利用这些服务以自助方式进行使用，而无需平台团队提供太多的帮助。

用户界面可能会因用户的不同而有所不同。例如，开发人员可以使用Backstage，一个开源框架，来构建内部开发门户，供用户自助访问全部开发资源，如目录、模板、部署管道、开发/测试环境等。团队可以使用 Terraform 进行基础设施管理和维护。

在用户界面的背后是平台的后端，它将所有组织的公共框架、基础设施、服务和工具集中在一起，并通过一个或多个用户界面向最终用户提供标准化服务。

组织的安全、治理和合规要求也被烘焙到后台，以在所有平台服务上应用，以便在整个组织中一致地执行这些要求。

最简单的形式中，平台可以看作是两部分（如下所示）—— 一个由一个或多个最终用户界面组成的前端和一个后端，它为前端提供必要的基础设施，服务和工具自动化，因此使最终用户能够以自助方式使用这些功能，以实现更高的生产力，加快产品开发进度和保持安全性和治理策略的一致性控制。

开发人员的前端可以是简单的本地门户，一个先进的后台部署，或者是一个商业内部开发平台(IDP)解决方案。同样，对于 SRE 团队来说，前端可以由平台团队开发的一组常用 Terraform 模块组成，用于预配和管理基础架构。

一些团队可能意味着将基础架构资源的声明性规范检入到 git 存储库中，并通过 GitOps 自动配置和管理基础架构资源。

后端实际上是基础设施自动化、应用服务、开发人员体验工具、SRE 工具和框架以及安全性和治理策略管理工具的集合。平台团队通常通过在这些基础架构、服务和工具之上添加额外的自动化层，将它们通过各种前端技术提供给用户。

例如，它可能是开发一个定制插件，允许开发人员从 Backstage 门户创建一个开发沙盒。同样，它可以是一个 Terraform 模块，用于创建带有所有必需插件和策略的 Kubernetes 集群，SRE/运维团队可以使用它来创建具有一致配置的集群。平台后端的各个主要组件如下所述：

每个应用程序团队在其应用程序开发中使用各种服务和工具，这些服务和工具不属于核心应用程序的一部分。范围可能从基本服务（如容器注册表、CI/CD 管道和 Vault 即 secret 管理服务）到高级服务（如消息传递、缓存、数据备份、灾难恢复等）。

平台团队将这些服务自动化，并通过一个简单的界面将它们提供给应用程序团队以进行载入/集成——减少应用程序团队的工作量和认知负担，并使他们能够更多地专注于核心应用程序开发以加速产品交付。

可观测性涉及从正在运行的系统收集数据，这些数据可用于故障排除和修复问题、分析资源使用情况以优化性能、收集容量规划指标或构建预警系统，以在任何潜在问题发生之前检测到它们等。

Logging、metrics 和 trace 是可观测性堆栈的基本组成部分。平台团队通常使用开源和/或商业解决方案，并可能实施额外的自动化以与各种应用程序无缝集成以进行数据收集；他们将其提供给开发人员和 SRE/Ops 团队进行分析和故障排除。

除了可观测性工具，SRE 和运营团队还使用许多其他工具和技术来管理和运营大型应用程序基础设施。这些可能包括舰队基础设施管理和运营的自动化、混沌工程、事件管理、警报管理、用于高级调试的自定义故障排除工具、自我修复等。

平台团队可以针对其中一些工具对开源和商业产品进行标准化，并将它们提供给 SRE 团队。同样，平台团队可以为舰队管理、高级调试和自我修复类型的用例开发自定义解决方案，因为这些用例可能非常特定于他们的基础设施和应用程序。

每当开发人员开始开发新服务或应用程序时，他们常常被迫从事重复性工作。这在拥有许多内部应用程序团队、产品团队和业务部门的大型组织中尤其普遍，这些团队之间通常很少共享代码和工具。这些重复性任务可能包括为已经存在的新服务创建样板代码模板、设置测试平台、启动开发/测试环境等。

除此之外，开发人员还需要了解他们所拥有的服务的相关信息——它使用了哪些资源、服务的健康程度、上次更改时间以及如何查看最新日志。平台团队可以通过利用 Backstage 或其他一些开发人员门户的统一开发人员门户以及自动化此类任务中涉及的可重复任务的能力来提供这些能力。

InfoSec 和安全团队为整个组织使用的所有组件、服务和基础设施定义安全框架和基线安全态势。这可能需要在所有系统中一致地执行所有安全策略和实践以满足安全基线态势，持续验证基线以检测任何偏差并在发生违规事件时快速补救。

安全基线策略包括单点登录和基于角色的访问控制、网络安全、用于在资源级别实施精细合规性和安全策略的开放策略代理 (OPA)、镜像漏洞扫描、运行时容器安全、CIS 基准测试等等。

平台团队需要在应用程序开发、部署和管理的每个阶段以及基础架构级别自动应用这些成本控制策略。

对于治理，成本控制政策对每个组织都是必不可少的。平台团队需要在应用程序开发、部署和管理的每个阶段以及基础架构级别自动应用这些成本控制策略。例如，这可能意味着为 Kubernetes 集群部署自动安装一组批准的系统附加组件和 OPA 策略、网络策略和成本控制策略。

平台工程没有放之四海而皆准的方法。它归结为每个组织的具体要求、优先事项以及他们希望通过平台实现的目标。该平台不仅仅是 IDP、Backstage 部署或自助服务门户。开发人员不一定是该平台的唯一用户。平台团队必须彻底了解他们所有的内部用户角色和他们的需求，并为平台开发合适的后端和用户界面，为所有内部用户提供最大价值