虽然使用平台工程功能模型实现平台工程的方法不同，但用户研究表明，大多数Microsoft客户属于三个客户细分市场之一：新兴创新者、战略构建者和平台先驱。 本文将指导你完成每个细分中真实客户的案例研究。 为了隐私，公司名称被删除。
新兴创新者：保险公司
| 客户细分 | 重点区域 | 团队规模 | 组织特征 | 频率 |
|---|---|---|---|---|
| 新兴创新者 | 快速产品开发，自动化手动流程，解决效率低下问题 | 1-5 （来自 DevOps 或云基础结构团队） | 确定改进交付的瓶颈，开始意识到组织范围的解决方案需求 | 第二最常见 |
一家大型保险公司意识到，他们不同的基础设施分布在大型技术堆栈中。 有多个平台和环境，但开发人员很难不依赖其他团队就独立入门。 该公司需要降低不断增长的劳动力成本，并拥有更标准化的系统。
临界点非常明确。 鉴于我们有多个工程平台、多个基础结构环境，包括混合、无自助服务开发人员门户功能，以及整个体系结构中的三大不同堆栈，因此我们必须引入 Terraform 或 GitLab 或 GitHub 等企业级玩家。 为了管理端到端的容器化平台，我们考虑了 OpenShift、用于工作流自动化的 Ansible，以及作为 IDP 的 Backstage 等内容。 我们进行了大规模的评估，以在这样一个大型的技术栈上实现协同效应。这是一个非常简单的成本计算，涉及减少30%的劳动力或开发人员数量。——来自保险公司的首席架构师。
挑战： 他们的主要挑战是云成本、合规性问题、基础结构工程专业知识不足、流程不协调和团队沟通不一致。
保险公司计划为所有开发和部署活动实施标准化平台，以促进协作、加快项目设置和简化治理。 该公司专注于所有五个关键平台工程驱动因素的增长。
投资： 该公司正与外部合作伙伴合作，使用生成、运营和传输（BOT）模型实现平台工程。 外部合作伙伴在获得内部管理该平台的专业知识和能力后，先开发并运营平台。
采用： 采用新做法遇到显著的内部阻力。 开发人员不希望从传统方法转向较新的平台和工具集。 为了克服这一点，组织的领导通过将平台工程采用与生产力福利并使其成为员工目标的一部分来推动平台工程采用。
统辖： 企业规划和部署（EPD）团队负责合规性和安全性。 集中式治理结构被有意设计为保持高安全性并避免漏洞，使得去中心化成为一个挑战。 推动向开发人员实现部署的民主化，同时维护治理协议以防止数据泄露并确保合规性。 目标是在安全性和敏捷性之间取得平衡。
供应： 该公司通过采用更集成的自助服务模型来提高效率和减少预配时间。 预配所花费的时间和资源可能会减少，是变革的关键驱动因素。
接口： 组织采用 Backstage，因为它具有开源的灵活性、成本效益和开发人员的熟悉度。 Cortex 也被考虑在内。 选择 Backstage 的决定是由其成本和集成功能推动的。
度量和反馈： 很难迁移到更有意义的反馈系统，因为公司具有旧式度量系统，需要将技术指标与业务 KPI 保持一致。 该公司计划努力使工程工作与业务成果保持一致，以采用更集成的度量方法。 在此过渡期间，公司添加了提供实时分析和可观测性的工具和平台。
战略建设者：金融机构
| 客户细分 | 重点区域 | 团队规模 | 组织特征 | 频率 |
|---|---|---|---|---|
| 战略构建者 | 协作，减少冗余工作量，共享解决方案，标准化，成本管理 | 1-15 技术专家（开发人员和基础设施专家） | 领导将开发人员视为客户，部分集成平台工程功能（自助服务未完全采用） | 最常见的 |
金融机构处于 DevOps 成熟度中层，拥有一些可重用的中心项目、标准化指南和通过代码管理的基本自动化。 组织已经达到了一个点，即其开发团队的规模及其工具和做法的多样性造成了巨大的成本。 该机构拥有公司中使用的数千种自定义工具，以及许多复杂的组织需求。 该银行计划为开发人员提供一条“黄金路径”，以提高工作效率，同时避免采用一刀切的方法。
“因此，我们的想法是，我们将向他们（开发人员）表明，这种[黄金路径]是一种做能够提高工作效率的事情的方法，但这不是唯一的方式。 对吧？ 因此，我们希望为开发人员留出足够的空间，让他们觉得他们有权更改我们告诉他们的道路。 因此，当这些路径在 CTO 团队中定义时，问题始终是，要定义哪些路径将适用于银行中的大多数人？ 正如我说的，我们非常复杂。 银行内使用数千种工具。 因此，“一刀切”始终是最大的问题。——金融机构执行董事
挑战： 由于许多不同的工具和做法，他们的主要挑战是高成本和效率低下。 该公司希望确保该平台能够满足每个团队的特定需求，同时不会因为问题或过于强硬的方式而阻碍其采用。 金融机构还缺乏内部开发自定义平台解决方案的专业知识。
金融机构计划专注于三个关键驱动因素的增长：采用、治理以及配置与管理。 该行希望提高平台工程解决方案的采用率，更好地集成治理，并构建自动化资源预配工具。
投资： 该金融机构拥有一个中心工程团队，全世界有120人分布在多个地点。 大约20名成员组成了卓越中心（COE）团队。 COE 团队跨所有其他业务部门推出工程最佳做法、平台和 DevOps 实践。
采用： 平台工程团队侧重于强制实施 COE 团队设置的策略，以指导工程运营。 该公司还计划利用公开可见的性能指标激励团队。 总体而言，该银行希望在不依赖严格的指令和指标的情况下扩大平台使用量。 但是，他们在提高 COE 团队技能方面面临挑战，以处理跨工程团队使用的各种技术。 一个主要障碍是，平台可能无法满足各个团队的特定需求，这可能会导致问题。
统辖： 平台工程解决方案是一个内部开发的门户，充当开发人员的中心中心，提供工具、指南、编码标准和视频。 该解决方案包括一个关于最低企业要求（MERS）的测验，以确保在编码开始之前符合性。 门户网站提供一个支持版的 Stack Overflow、认证工程师的个人资料，以及帮助新开发人员熟悉现有标准和工具的引导流程。 该公司计划简化资源管理并将治理集成到开发生命周期中，消除瓶颈，并使用现代工具集吸引顶级技术人才。
供应： COE 团队为开发人员创建了“快乐路径”，以提高工作效率，同时保持灵活性。 目标是在允许自定义的同时提供有效的路径。 在设计这些路径时，CTO 团队旨在满足大多数开发人员的需求，但该银行的复杂性（使用数千种工具）使得实施标准化方法。 为了扩展平台，组织计划实施自动化资源预配，以满足其许多工程团队的各种需求。
接口： 内部开发人员门户主要是内部开发的。 它在内部称为 DevOps 门户，尽管它包含更广泛的平台工程功能，而不仅仅是 DevOps。 门户作为开发人员的集中资源，提供各种工具、学习材料、视频和培训课程，还可以访问自动化工具、自学指南以及用于开发的容器化映像。 门户还与 Sonatype 等安全工具集成，用于代码扫描，并包括已批准的映像和样本代码的注册表。
度量和反馈： COE 团队愿意提供反馈，并积极征求工程团队的意见。 开发人员倡导者和大使还代表 COE 团队收集反馈。 反馈过程大多是非正式的。
平台先驱：软件公司
| 客户细分 | 重点区域 | 团队规模 | 组织特征 | 频率 |
|---|---|---|---|---|
| 平台先锋 | 将开发人员视为客户、将平台作为产品管理、强大的开发人员体验 | 16+ 版本，带有专门的小组 | 强调问责、授权和创新，促进自助服务和最小上下文切换 | 最不常见 |
软件公司处于 DevOps 成熟度的高水平。 公司的开发人员可以根据公司准则自行预配云服务。 该公司拥有 250 多名成员的大型平台团队已成功为组织开发自定义平台工程解决方案。 该公司计划调查如何通过平台工程继续改进其组织。
“我们如何让我们的开发人员更快地提供更好的软件（更便宜）?..我们仍然需要调查并投资可能适用于我们的多云策略的理想解决方案...有一个系统可以扩展到开发人员的各种需求?..我们使用内置用于文档和信息发现的生成 AI 和 AI 驱动的解决方案。我们的目标是让开发人员承担责任。“ - 软件公司高级工程主管
挑战： 该公司的主要挑战是找出如何继续优化他们已经强大的平台工程实践，以节省资金，探索生成 AI，增加采用，并为多云环境工作。
软件公司计划专注于发展四个关键驱动因素：投资、采用、预配和管理以及接口。 软件公司已经处于高平台工程水平，并希望继续工作。 该公司计划探索将生成 AI（与治理）集成的方法，提高平台采用率，并实施指标驱动的反馈循环。
投资： 该平台通过 CTO 和 CFO 办事处之间的协作得到资助和支持。 由重新分配资源组成的专用平台团队包括架构师和工程师等 250 至 280 名成员。 该团队负责监督计算、运行时、CI/CD、工具和可观测性，重点是成本效益。 他们正在探索生成式 AI，以提高基础设施的可扩展性，但认识到还需要进一步的研究和投资。
采用： 开发人员最初采用的平台主要是成本优化和效率，由疫情推动。 内部活动，包括黑客马拉松，推广平台，展示服务成熟度见解等优势。 平台团队很难说服某些团队从现有设置迁移到平台。
统辖： 平台的治理模型围绕管理核心元素的中心平台团队进行构建。 单个服务团队贡献插件。 所有贡献都有一个审查流程，用于验证它们是否符合组织标准并满足更广泛的需求。 平台团队维护服务目录和服务映射来跟踪元数据和依赖项，这有助于确保责任和资源管理。 此外，专门成立了专用治理机构，供 AI 应用程序管理其使用并确保符合标准。
供应： 平台团队提供了一个集中但灵活的平台，用于资源创建、部署和管理。 该平台基于 Kubernetes 构建，将 Argo CD 用于 CI/CD。 该工具提供自定义生成的模板和预定义工作流。 该平台包括开发人员主页，用户可以在其中管理其基础结构生命周期，从预配到部署。 团队贡献定制插件以增强功能。 目标是使用可缩放的平台无缝管理多云基础结构。
接口： 开发人员使用平台中的开发人员主页来管理基础结构、预配及其整个开发生命周期。 平台的基于插件的体系结构允许自定义，而生成 AI 增强了文档和可搜索性。
度量和反馈： 组织通过调查收集反馈，并使用 DORA（部署频率、潜在时间、更改失败率和平均恢复时间）等指标来评估平台有效性。 这些指标分为敏捷性和稳定性，以查明瓶颈并提高结果。