采用平台工程实践意味着从共享平台和功能的非正式和不一致的使用过渡到整个组织内更协调、标准化和参与性的方法。 本文概述了采用阶段，重点介绍组织如何发现、选择和有效地使用服务、工具和技术来创建一个凝聚力高效的平台工程环境。
采用共享平台和功能是零星的和不一致的。 没有组织范围的策略或指南可用于选择和集成所需的支持服务和技术。 各个团队可能会应用平台实践来改进自己的流程，但整个组织没有协调的工作或标准化。 这种采用级别没有一致的方法。 采用此方法的组织认为，外部工具比内部提供的工具更有效。
发现服务、工具和技术：工具和功能是非正式发现的，通常是通过口碑或机会相遇发现的。
选择服务、工具和技术：工程团队根据其特定需求独立选择并集成服务和技术。
使用服务、工具和技术：工程团队维护自己的脚本、工具和流程，这些脚本、工具和流程特定于其特定上下文和需求。
授权
该组织认识到共享平台和功能的价值，并努力鼓励和培养它们。 内部指令激励甚至要求对某些用例使用共享平台服务。 某些产品团队比其他团队使用平台功能更多;功能涵盖组织中的典型用例，但并不罕见。 很难将这些离群值添加到通用平台。
用户发现功能及其使用方式不一致;除非由平台团队指导，否则产品团队上的用户可能会发现受支持的功能。
发现服务、工具和技术：工程团队必须查找平台团队指南才能使用特定的工具和功能。 本指南可能显示在内部文档和/或组织宽指令中。
选择服务、工具和技术：工程团队可能依赖于与平台团队进行非正式讨论，以选择和集成授权的服务和技术。 如果工程团队满足特定需求，请选择并集成授权的服务和技术。
使用服务、工具和技术：流程是围绕平台团队创建的标准构建的，但如果它们不完全满足需求，则工程团队无法轻松扩展这些流程。 工程团队要么无法使用授权的标准，要么无法使用，但对最终结果不满意。
广告
组织通过明确传达符合团队需求的权益和特定用例来积极提升平台的功能。 平台团队与工程团队密切合作，不仅突出了这些优势，而且通过记分卡和服务管理指标（SMIs）等工具促进性能比较和目标设置。 提供高质量的支持服务以减少运营开销，使平台成为产品团队的有吸引力的选择。
但是，尽管这些努力，但一些团队在将服务迁移到平台时仍可能会发现低 ROI，这使得他们犹豫不决地退出既定的例行公事和做法。 此外，组织还面临着将技术债务减少与将服务迁移到平台的持续需求之间平衡的复杂任务。 克服这些障碍需要平台团队持续参与和支持，以确保平台的价值主张与整个组织的所有团队产生共鸣。
发现服务、工具和技术：通用平台公开涵盖组织典型用例的功能。 工程团队通过平台团队指令发现平台功能。
选择服务、工具和技术：平台团队与工程团队协作，鼓励选择平台功能。
使用服务、工具和技术：与服务、工具和技术相关的问题和解决方案通过组织内部的非正式实践社区共享。 例如，他们任命开发团队中的大使或冠军来倡导使用这些功能。
Value-Driven
产品和服务团队中的用户选择使用平台及其功能，因为他们在减少产品团队的认知负载时提供了明确的价值，同时提供更高质量的支持服务。 文档和人体工学界面使产品团队用户能够快速预配和使用平台功能。 用户选择内部平台实现，而选择替代方法，例如自行开发功能或雇佣提供商。
发现服务、工具和技术：工程团队积极与平台合作，发现各种功能 - 自助服务 UX。
选择服务、工具和技术：工程团队使用平台查找技术要求的解决方案。 该平台描述了每个功能提供的价值，并驱动工程团队做出的选择。
使用服务、工具和技术：平台通过模板、支持论坛、文档等完全支持平台功能的使用。
参与
来自产品团队的用户通过加入生态系统并为其贡献来进一步投资平台功能。 一些贡献可改进和修复现有功能;其他人引入了新功能和功能来应对新的用例。 定义流程和服务，使用户能够识别要求并在多个产品和平台团队之间协调贡献。 新功能通过一致的接口和门户发布，以及完整的文档和标准版本控制。
发现服务、工具和技术：开发人员倡导者和内部大使构建并支持将平台所有权扩展到应用和服务团队参与者的内部用户社区。
选择服务、工具和技术：平台工程师参与产品团队计划，了解要求并建议现有功能。
使用服务、工具和技术：工程团队有权为平台功能提供修补程序、功能和反馈。 工程团队使用所需的扩展生成拉取请求并参与评审。