原文：Six pillars of platform engineering
作者：Michael Fonseca
平台工程和开发体验
平台工程是用来设计、构建工具链和工作流的方法，软件工程师团队在这些工具和流程的帮助下，获得自助服务的能力。这些工具和流程被称为内部开发平台，经常会被简称为平台。平台团队的目标是提高开发生产力、加快发布节奏、提高应用稳定性、降低安全及合规风险，以及降低成本。
HashiCorp 曾经协助很多组织通过平台团队来扩展其云运营模型，平台团队必须提供让开发者满意的体验才能达成目标。我们在这些经验中看到了两种提高开发者体验的方式：
对基础设施服务进行标准化，减少开发人员和运维团队之间的摩擦：小而集中的平台工程师团队能够使用合适的工具（例如 API、文档和推广等），来改善整个组织的开发者体验。目标是减少工具和流程碎片化，从而提高软件交付系统和环境的核心稳定性。
平台即产品：传统的 IT 项目通常有一个确定的开始和结束日期。但内部开发平台永远不会真正完成。包括 Backlog 管理、定期功能发布以及为利益相关者更新路线图等工作都是需要持续进行的。因此要以迭代和敏捷思维方式进行开发，而不是像瀑布式开发那样进行大规模的前期规划。
平台不是凭空产生的。只有在开发者想要使用平台的时候，平台才是有效的。构建和管理平台的过程中，需要持续的和开发者（平台用户）和利益相关人进行对话，并接纳其需求。本指南试图为平台团队提供一个对话的切入点，围绕软件交付过程中的六个技术元素（或者支柱）进行讨论，探讨每个要素的流程和一般需求，最终用这些要素进行产品组织。
平台工程的六大支柱
平台战略有哪些组成部分？在和业界大量客户协作的过程中，HashiCorp 认为，平台由六大基础元素组成。
安全
流水线（版本管理和 CI/CD）
基础设施发放
网络连通
编排
可观测性
接下来的章节会对这些要素的定义、流程、需求、依赖以及实现过程进行阐述。
支柱 1：安全
不管使用什么系统，开发者的第一个问题大概会是——“如何创建账号？怎么设置凭据？哪里能拿到 API Key？”虽说版本控制、持续集成以及基础设施发放才是平台工程的核心业务，然而默认安全是平台体验的基本要求。
历史上，很多组织都会构建基于网络边界的安全能力，形成一种“城堡+护城河”的防御方式。然而现在的基础设施变得越来越动态，边界也就越来越模糊，兼顾生产力和控制力，难度越来越高。
头部公司开始使用基于身份的安全、身份代理方案，以及凭据集中管理、加密方法论等现代方法来应对这一挑战。这些手段提高了审计过程的可见性和持续性，并且降低了碎片化方案带来的运营开销。
这些公司普遍采用了安全左移的策略：在软件开发的全生命周期中实现安全控制，尽早识别和修复潜在的攻击路径，并提高对审计以及合规的重视。这种方法不是临时措施，而应该是默认的用自动化的方式运行的。
DevSecOps 要求使用身份驱动的安全工具，并且用 As Code 的方式进行实现，而避免使用工单驱动的赋权过程。这种方式在传统和（例如基于特权的访问管理方式（PAM））和现代的安全方法论（例如 JIT 访问以及零信任）之间架设了桥梁。
身份代理
在云运营模型中，人类、应用和服务都有自己的身份，用权威的中性化机构对这些身份进行认证。可以使用身份供应者（idP）结合多租户机密管理和加密平台来作为组织的身份代理。
工作流：身份代理
在真实世界里，典型的身份代理工作流大概是这样的：
身份代理需求列表
身份代理有几个要素：
所有的人、应用和服务都有定义完善的身份
可以使用可信的 idP 进行认证
身份系统提供跨越多云、多运行时的互操作性
身份系统应该是中心化的，仅进行有限的分段，简化审计和多环境下的运营管理
为每个 idP 构建身份和访问管理（IAM）能力
客户端必须为认证和鉴权提供有效的身份
通过验证之后，就开始以默认拒绝的策略来进行访问，如果身份泄漏，这种策略能将最小化可能的不良后果
鉴权过程和审计一体化，如果能够做到即时（JIT）就更好了
通过支持异构运行时的灵活身份代理系统来防止碎片化：
包含确定 SLA 的 24/7/365 的企业级保障能力
自动化能力（IaC、Runbook 等）
访问管理：机密管理和加密
有了身份之后，客户会需要有办法操作机密数据，例如：
获取机密数据（凭据、密码、密钥等）
访问安全目标
管理安全数据（加密、解密、哈希、掩码等）
这些机制应该只需要极少的人工干预即可完成设置，更高的自动化水平更容易达成合规要求。这一能力还应该是可扩展的，确保后续能够有更多的工具加入系统。
工作流：机密管理和加密
典型的机密管理工作流应该包含五个关键步骤：
访问管理：安全的远程访问（人机交互）
传统上基于城堡-护城河模式的人机交互是不够的。传统过程需要用到多种身份，有认证和鉴权过程的介入，管理机密的生命周期，以及复杂的网络分区，这会造成非常大的开销。
过去十年中，尽管 PAM 解决方案已经发展出委托（如动态生成 SSH 密钥）能力，但这并不能满足更广泛的生态系统需求，包括多运行时审计或跨平台身份管理。引入云架构模式，如临时资源、异构云网络拓扑和即时身份管理进一步增加了传统解决方案的复杂性。
临时资源及其带来的复杂性问题，例如动态资源注册、身份、访问以及机密等问题，被一种现代方案解决了。这种现代的安全的远程访问方案不再依赖 VPN、CMDB、堡垒机、人工 SSH、机密数据签入签出等传统工作流。
企业级的安全访问工具可以使用零信任方案。这种方案里，用户和资源都有其身份，用户直接连接资源。通过动态资源注册表、控制器和密钥，作用域角色会自动注入到资源中，这样就消除了许多手动流程和安全风险，如频繁的网络打通和长期存在的密钥。
工作流：安全的远程访问（人机交互）
现代的远程基础设施访问工作流，通常有如下八个步骤：
请求：用户请求访问系统
验证（用户）：通过身份代理校验该用户的有效性
验证（到机器）：通过认证之后，进行鉴权，查看该用户对目标的权限。
请求：平台为目标系统申请一个凭据（静态的或者短期的）
注入凭据：平台把凭据注入到目标资源里
代理响应：平台向返回一个认证代理返回一个响应
客户端响应：平台授权给最终用户
访问机器/数据库：用户使用现代的安全远程访问协议访问目标资源
访问管理需求列表
机密管理系统应该包含：
中心化
传输和存储中的加密
用范围角色和访问策略进行限制
尽可能动态生成
时间相关（TTL）
全程可审计
机密管理应该有如下能力：
另外，要实现远程访问，应该提供：
支柱 2：流水线（版本管理、CI/CD）
平台团队的第一步通常是和软件交付流水线进行集成，或者重构。在这之前首先要审视一下团队所在组织的版本管理系统和 CI/CD 流水线。
很多组织都会有多个成熟程度不一的版本管理系统和 CI/CD 流水线。这些平台还在演进之中，所以建议采用基于组件的 API 平台或目录模型，以支持未来的可扩展性，这样就可以避免在功能上进行妥协，或者反复重构了。
在云原生模型里，基础设施和配置都是用代码的方式被管理的，因此版本管理系统是这一功能的核心。版本控制系统在这里起到了以下作用：
持久化和标准化
敏捷和效率
规模和弹性
配置即文档
复用和共享
灾难恢复和可重现性
合规与安全
版本管理系统和 CI/CD 使得跨基础设施、跨平台的交互称为可能，因此需要对这两个元素进行详细的评估。
工作流：版本控制和 CI/CD
典型的版本控制和 CI/CD 工作流有五个步骤：
编码：开发人员把代码提交到 VCS，随后自动触发流水线
校验：CI/CD 平台向 idP 发起验证请求（认证和鉴权）
响应：如果校验成功，流水线开始执行任务（测试、构建和部署）
输出：输出和制品被分享给平台组建或者外部系统，用于后续处理
操作：可能会进行一些安全方面的后续处理，例如权限清理等。
VCS 和 CI/CD 需求列表
成功的 VCS 和 CI/CD 解决方案应该提供：
VCS 和 CI/CD 系统可能有一些别的特别需求。
平台团队选择和演进他们的 VCS 和 CI/CD 解决方案，要考虑存量/传统的基础设施发放、安全以及合规要求的转型。团队应该假设新平台会影响到存量实践，应该识别、协作和协调随之而来的变化。
平台团队还要有前瞻性。VCS 和 CI/CD 平台会用更多的抽象来让研发人员远离 CI/CD 过程的复杂性。面对包含 Kubernetes 和 Serverless 在内的多种运行环境，HashiCorp 希望用 Waypoint 产品来提供对部署、管理和可观测性的支持。
流水线支柱：HashiCorp 和合作伙伴（VCS 以及 CI/CD）的方案 VCS：GitHub、GitLab、BitBucket CI/CD：Jenkins、CircleCI、GitHub Action 在目前，方案中的这些选择属于各个领域里面的最流行工具。这些工具已经流行超过十年，所以 HashiCorp 也就没有提供自己的 VCS 或者 CI/CD 方案。 HashiCorp 提供的是在各个平台之上的新的控制层，为平台工程师提供真正的一致的（Kubernetes、ECS 等）平台即服务（PaaS）工作流。HashiCorp Waypoint 承担了这一任务，让开发者能够用统一的工作流来跨平台的构建和发布应用。Waypoint 中，开发者用一个简单的 waypoint up 命令就能把应用运行起来。
参考
支柱 3：基础设施发放
前面提到的两个支柱，平台团队提供了自服务的 VCS 和 CI/CD 流水线，并且提供了安全能力作为防护。这是软件交付的先决步骤。那么要运行应用的时候，面临的问题就是——在哪里运行？
每个 IT 组织都需要为应用进行基础设施规划，而平台团队则应该把资源规划视为能力的基础。基于工单的工作流是无法适用于现代的动态 IT 环境的，因此平台工程的首要目标就是消灭这种工作流。平台团队一般会构建自助的基础设施供应服务，这种服务给开发者提供了工作流、模板和工具，这种服务是消灭工单流程的关键举措。当然，这一能力要和前面提到的安全和 VCS 等支柱结合起来。
通常会使用 IaC（Infrastructure as Code）技术构建有效的、现代的基础设施平台。基础设施的配置和自动化被变成代码了，那么不管多复杂的基础设施场景，也都能进行自动化了。基础设施代码能够非常方便地进行版本控制，从而进行审计、迭代和协作。市面上有不少的 IaC 工具，不过最常见的还是 HashiCorp Terraform，他的市占率远超同类其他产品。
大量组织采用 Terraform 的原因是它的庞大生态。这一生态让平台工程师能够满足基础设施能力的一个主要需求：扩展性。扩展能力强的社区让平台工程师能够在不开发新代码的情况下，快速采用新技术和服务。
基础设施发放：模块和镜像
要构建标准化的基础设施工作流，就要把基础设施重构为可复用的组件，理想情况下，这些组件还应该是不可变更的。不可变基础设施在现代 IT 世界里是一个普遍标准，这种概念能有效的降低复杂性，简化了排障过程，同时也提高了可靠性和安全性。
不可变意味着所有的变更都是对基础设施进行删除-重建的过程，这样就最小化了对服务器进行补丁和配置变更的要求，确保每次服务迭代都是用的是新建的、经过测试以及更新过的实例。不可变还实际促进了 Runbook 校验以及故障演练、金丝雀部署等能力的实际落地。很多组织会使用 Terraform 或者其他类似的工具来落地不可变原则——仅需修改配置代码，就能构建或者重构建大量基础设施资源。有些组织还构建了黄金镜像流水线，所谓黄金镜像，指的是经过测试的、符合安全以及合规需求的机器镜像，这种流水线专门用于黄金镜像的构建和部署。
除了机器镜像之外，现代 IT 组织还将基础设施代码组织成可复用的模块。软件开发的核心原则之一就是不要重新发明轮子，因此模块化对于基础设施代码化是非常重要的。模块化过程会根据架构原则，抽象出轻量级的模块，而避免直接使用孤立的对象。通常会对基础设施代码进行版本化管理，并和服务目录、测试框架等第三方系统进行交互。
高效 IT 团队会把黄金镜像流水线以及自己的模块仓库结合起来，来为应用程序构建基础设施。开发者无需知道太多的基础设施细节和内部机制，凭借黄金镜像流水线和基础设施模块，能够直接获得一个可重复、有弹性、可预测的工作流，其中甚至还包含了安全、合规以及最佳实践，
工作流：模块和镜像
典型的基础设施供应流程会有 6 个步骤：
编码：开发者提交代码，并向流水线提交任务
校验：CI/CD 平台向 idP 平台申请认证和鉴权
idP 响应：如果验证通过，流水线启动任务（例如测试、构建和部署）
请求：CI/CD 自动化工作流构建模块、制品、镜像以及其它基础设施组件
响应：（执行器）把响应结果（成功、失败，以及元数据）传递给 CI/CD 平台
输出：模块、制品以及镜像配置等基础设施组件被部署或者存储。
策略即代码
原本基础设施供应的重点被认为是运维问题，而敏捷开发实践已经将其转变为应用交付的需求。基础设施的发放现在已经变成了商业成功的基本要素。企业战略和顾客业务都和基础设施发放工作息息相关，这不仅仅关系到运维成本。
要实现转型，过程控制和工作流都是需要做出改变的。历史上，运维人员通过工单保障基础设施发放过程的合规。这些工单通常涉及鉴权、审批、安全性、成本等方面。整个过程都要进行合规性和控制实践的审计。
如今，开发人员和其它平台用户希望用自助方式来进行基础设施发放，这种流程必须改变。需要实现一系列的代码化安全控制以及护栏，满足合规和控制要求。
在云原生系统中，这些控制是通过策略即代码的方式来实现的。策略即代码是使用可编程的规则和条件，来完成应用和基础设施的部署，代码中包含了最佳实践、合规要求、安全规则以及成本控制。
有些工具和系统包含了自己的策略系统，也有高级策略引擎能够和多种系统进行集成。基本需求在于，在系统中能够使用代码的方式来管理策略，并且提供评估、控制、自动化以及反馈流程。
策略即代码造成了左移的效果，在基础设施发放过程中，能够更早的给用户提供反馈，并让用户能够更快更好地做出决策。策略是需要编写的。平台团队应该负责策略即代码的实践，协同安全、合规、审计以及基础设施团队，一起来保障策略的合理落地。
工作流：策略即代码
要在基础设施供应方面实现策略即代码，需要 5 个步骤：
编码：开发者提交代码，流水线发起任务
校验：CI/CD 平台向 idP 发起认证和鉴权请求
idP 响应：如果成功，流水线启动任务（例如测试、构建和部署）
请求：运行计划的基础设施交付任务之前，首先要通过策略引擎进行决策，确定放行还是拦截该资源计划
响应：包含元数据的响应内容经过 CI/CD 被发送给外部系统。
需求列表：基础设施发放
要用自助方式提供基础设施发放能力需要：
端到端自动化的控制和数据平面
自动化配置（IaC、Runbook）
预定义的、可配置的工作流
本地集成 VCS 和 CI/CD 工具
支持业务所需的多种容器和虚拟机镜像
为不同的角色和工作流提供不同的界面（GUI、API、CLI、SDK）
使用广为接受的 IaC 语言——强烈推荐声明式语言
和业界标准的测试、安全、加密以及机密管理系统保持兼容
能和通用的工作流组件（例如通知工具、Webhook）进行集成
支持代码化的门禁：
使用单点登录和 RBAC 可以集成到可信的鉴权 Provider
资源的元数据管理（状态、镜像、资源等）：
默认拒绝的控制
加密
为自然人和机器提供可编程的使用界面
用支持追溯的配置系统，对被管理对向进行隔离
可以支持大型分布式的团队
支持公开和私有模块
全面的审计和日志能力
用 FinOps 支持基于成本的政策和优化
明确定义的文档和开发者支持
基于 SLA（例如 24/7/365）的企业支持
基础设施支柱：HashiCorp 解决方案HashiCorp Terraform：基础设施发放方面的业界标准。很多组织都已经采用了 Terraform Cloud 或者企业级 Terraform 作为基础设施发放工作流和护栏。 HashiCorp Packer：构建黄金镜像的事实标准。 HashiCorp Cloud Platform（HCP）Packer：提供了增强的镜像元数据管理能力，合规自动化以及全局镜像查询能力，HCP 是 HashiCorp 的托管云服务。
参考
支柱 4：网络连接
如今很多企业还在用传统的模式和硬件，平台工程的讨论中，很少会涉及到网络连接方面的话题。应用间的数据交换依赖网络，基础设施和应用程序的架构也都跟网络强相关，因此连接性问题也应该仔细斟酌。
创建 DNS 条目，打开防火墙端口，设置网络 ACL 或者更新流量路由规则等日常活动，传统上也是使用工单系统来驱动的。即使是基础设施管理流程已经完全自动化，这种玩法通常也会消耗整天甚至整个星期的时间。另外这些简单的更新通常是人工的、易错的，并且不利于在动态的云环境中执行。如果没有自动化的实现，在高速运转的公有云系统里，IP 地址和连接性这些事情都会琐碎、易变和难于管理。
为了适应现代动态环境，平台团队将网络功能、软件和设备引入其基础架构的代码配置中。这样可以将基础设施代码化带来的速度、可靠性和版本控制追溯性等优势带到网络领域。
组织采用了微服务架构之后，紧接着就会意识到软件驱动的服务发现和服务网格解决方案的价值。这些解决方案会基于集中策略自动发现服务和尝试连接服务，在零信任网络中，默认会拒绝服务与服务之间的连接，仅在得到授权的情况下才会进行连接。在这个模型中，有了基于服务的身份，才能确保对常见安全框架的遵从。
组织的中央共享注册表应该是多云、多区域和多运行时的，这意味着它可以连接各种集群类型，包括虚拟机、裸金属服务器、无服务器或 Kubernetes。团队需要尽量减少对传统网络入口或出口点的需求，以避免将他们的环境带回过时的基于网络边界的安全方法。
工作流：连接性
典型的网络连接工作流应该有八个步骤：
代码：开发者提交代码
- 注意：开发者应该在 RBAC 允许的情况下，能直接访问网络的控制平面。
校验：CI/CD 平台请求 idP 平台进行认证和鉴权
请求：执行请求内容，例如构建模块、拉取制品、使用内外部策略进行验证等，最终完成资源发放
发放：发放缺失的基础设施
配置：在连接性平台上进行配置
连接：目标系统基于根据既定策略进行更新
响应：用元数据的形式，把响应内容返回给 CI/CD 系统，并且通知外部系统执行其它操作，例如安全扫描或者集成测试。
连接性需求列表
成功的网络连接自动化需要：
HashiCorp 的连接性解决方案HashiCorp Consul 提供先进的基于服务的网络功能，支持常见用例，如服务发现和服务网格。Consul 解决了多平台应用连接性挑战，能够在异构环境（私有云和公共云）和运行时（主机、微服务、传统虚拟机或裸金属基础设施）之间桥接工作负载。
参考
支柱 5：编排
当开始部署应用工作负载的时候，如果要处理分布式应用、微服务或者希望在云基础设施上实现弹性，工作负载编排器会让事情变得简单。
相对于传统技术，Kubernetes 或者 HashiCorp Nomad 这样的工作负载编排器好处多多。不同的选择性投入，会得到不同的收益。例如将应用程序重构为容器化形态，进而采用 Kubernetes，其投入就远高于采用 HashiCorp Nomad 这样的编排器，这是因为 HashiCorp Nomad 的原始设计目的就是支持多种工作负载类型。不管如何选择，工作负载编排器应提供如下能力：
提高资源使用率
弹性扩缩容
多云以及混合云支持
开发者自助服务
服务发现和网络（内置插件）
高可用和故障隔离
高级调度能力
资源隔离和安全
成本优化
编排器提供了优化算法，来确定将工作负载分配到基础设施资源上的最佳方式（例如 bin-packing、分散、亲和、反亲和、自动伸缩、动态资源分配等），这会显著降低成本。这些调度算法能在无需开发者知悉细节的情况下，自动地完成算力分配和韧性设置。
和其它平台支柱一样，能够前瞻性地兼容未来的环境变化和多样性工作流世很有必要的。编排器还应当具备处理多租户以及跨云、跨数据中心的能力
记住，不是所有的系统（例如供应商提供的单体应用）都能被容器化，或者转换为现代编排器，所以团队应当帮助其它团队优化转型和自动化编排的流程。现代化编排器提供了很多原生能力。尽管具体的实现和功能在不同系统中有所差异，但存在一些共性的核心要求。
工作流：编排
典型的编排工作流应该包含八个步骤：
Code：开发者提交代码。
- 注意：开发者应该有在 RBAC 许可的情况下，直连网络控制平面的能力。
校验：CI/CD 平台申请 idP 进行认证和鉴权。
idP 响应：如果认证和鉴权成功，流水线启动普遍任务（测试、构建、部署）。
请求：平台执行任务，例如构建模块、下载制品或者使用内外部引擎进行校验等，完成资源发放
发放：发放和配置基础设施。
配置：对被编排资源进行配置
Job：编排器在目标基础设施上根据既定任务和策略运行 Job。
响应：将请求的完成情况反馈给 CI/CD 平台，以便进行后续处理或移交给外部系统执行后续动作，例如执行安全扫描或集成测试等。
编排器需求清单
成功的编排需要：
服务/批处理调度程序
灵活的任务驱动能力
可插拔设备接口
灵活的升级和发布策略
支持联邦部署
弹性、高可用的部署拓扑结构
自动扩缩容
访问控制系统（IAM JWT/OIDC 和 ACL）
支持多个界面以适应不同角色和工作流程（GUI、API、CLI、SDK）
与可信 idP 集成，支持单点登录和委派式 RBAC
对任务进行功能、逻辑或物理隔离
原生配额系统
审计系统
基于 SLA 提供企业支持（例如 24/7/365）
通过自动化进行配置（IaC，Runbook）
HashiCorp 解决方案
HashiCorp Nomad 是一个轻量级的、健壮的、适配多种运行环境的编排器。在官方网站你可以看到 Nomad 的架构、能力、界面以及为客户运维工作提供的帮助。
参考
支柱 6：可观察性
任何平台工作流程的最后一步就是对部署结果进行监控和维护。将可观察性实践和自动化构建到平台中，能够衡量软件、服务、平台和产品的质量和性能，了解系统行为。良好的系统可观察性可以加快并简化问题调查和诊断过程。
从根本上说，可观察性就是对数据进行记录、组织和可视化处理。仅有数据的可用性并不能提供企业级的可观察性。SRE、DevOps 或其他团队首先确定要生成、收集、聚合、总结和分析哪些数据，以获得有意义且可操作的见解。
可观测性解决方案使用指标、跟踪和日志数据来对系统进行理解和调试。企业需要在整个堆栈上实现统一的可观测性：云基础设施、运行时编排平台（如 Kubernetes 或 Nomad）、云托管服务（如 Azure 托管数据库）以及业务应用程序。这种统一有助于团队了解云服务和组件之间的相互依赖关系。
但是数据的统一仅是将可观察性融入平台工程的第一步。平台团队还需要使用模块和部署模板等自动化方式，来落地可观察性的最佳实践。就像平台工程帮助安全功能向左移动一样，通过将可观察性融入容器和镜像，也同样能把可观察性向左移动到基础设施编码和应用构建阶段。如此一来，团队从开始就能够构建并实施全面的遥测策略，并将其自动化到平台工作流程中。
将可观察性解决方案集成到基础架构代码中的好处很多：开发人员可以更好地了解其系统的运行方式和应用程序的可靠性。团队可以快速调试问题并追溯到根本原因。组织可以通过数据驱动的决策来改进系统、优化性能和提升用户体验。
工作流：可观测性
企业级可观测性工作流应该有如下 8 个步骤：
编码：开发人员提交代码
- 注意：开发人员应该在 RBAC 许可的情况下直接连接到网络控制平面
验证：CI/CD 平台请求 idP 进行认证和鉴权
idP 响应：如果成功，则流水线触发任务（例如测试、构建和部署）
请求：执行请求内容，例如构建模块、拉取制品、使用内外部策略进行验证等，最终完成资源发放
发放：发放缺失的基础设施
配置：配置可观测性资源
收集：根据配置读取指标和跟踪数据
响应：将提供者请求的完成情况提发放 CI/CD 平台，以便进行后续处理和/或移交给外部系统，进行安全扫描或集成测试等。
可观测性需求列表
企业级的可观测性需要：
HashiCorp 合作伙伴的可观测性方案
下一步和技术选择的标准
平台建设永远不会完全完成。它不是一个事先计划好的项目，在每个人签署并开始使用后就结束了。它更像是一个迭代的敏捷开发项目，而不是传统的瀑布式开发项目。
平台工程可以从最小可行产品（MVP）开始，然后把平台推向组织市场。向团队展示该平台的常见模式和最佳实践如何能使团队从中受益，并适用于整个开发生命周期。与各个团队共同进行流程分析（当前状态对比未来状态），以便共同努力并理解采纳的好处可能会产生积极效果。最后，简化新员工上手过程是至关重要的。
选择上述，平台团队应该采取用户体验设计师的思维方式。调查各个团队的需求和期望之后，可能会发现，只有 80% 至 90% 的需求能被满足。有些工作流程太复杂或独特，无法纳入平台中。无法讨好每个人。工具链选择应该是一个跨职能过程，并且在一开始就需要高层支持来推动采用。
关键工具链的问题列表
实践者意见：您是否从询问开发人员对哪些技术感兴趣开始？这些技术能否快速支持业务？他们想学习什么，市场上是否普遍存在这种技能？
规模：该工具能否满足企业的期望，包括性能、安全/合规性和易于采用？您可以向同行机构学习，而不是冒险进入未知领域吗？
支持：所选解决方案是否得到组织的支持，以满足核心关键基础设施（24/7/365）的服务级别协议，并满足客户的可用性期望？
长期稳定性：这些解决方案供应商财务状况良好且有能力长期支持这些基本支柱和核心基础设施吗？
开发人员灵活性：这些解决方案提供灵活接口（GUI、CLI、API、SDK），以创建个性化用户体验吗？
文档资料：这些解决方案提供全面且最新的文档资料吗？
生态系统集成：是否有可扩展的生态系统集成来与其他工具（如安全或数据仓储解决方案）紧密连接？
