第 10 章：平台工程方法论：现代 DevOps 的新范式
前面的章节描绘了现代软件交付的诸多系统和实践。这段漫长的旅程也揭示了现代软件团队必须面对的艰巨复杂性。此外，现代软件开发倾向于将许多以前由运维团队处理的问题——安全、可观测性和基础设施管理工作——“左移”到开发环节。如果就连经验最丰富、资源最充足的开发团队都因这种复杂性和额外责任而感到吃力，我们又该如何应对？
平台工程应运而生，旨在帮助现代软件组织解答这一核心问题。它是一门设计、构建和维护内部开发者平台的学科，旨在为软件交付提供集成的工具和基础设施。虽然前几章探讨了现代软件交付的各个组成部分，但本章我们将深入探讨平台工程如何将这些能力整合到一个为开发团队服务的协同平台中。
在本章中，我们将探讨组织如何构建和运行高效的平台工程团队。我们将研究这些团队在组织中的定位，以及它们在实现快速、安全交付方面所扮演的角色。然后，我们将深入探讨构建和运营高性能平台团队的实际方面——从团队结构到日常运营无所不包。我们将探索衡量开发者平台有效性的具体方法，确保我们的投资能带来真正的价值。我们还将讨论标准化与团队自主性之间的平衡——如何在提供保障的同时不扼杀创新。最后，我们将审视平台可持续演进的策略，确保我们的平台能与组织的需求共同成长。
为何选择平台工程？
我们理解，传统的开发者工具方法通常要求开发团队独自应对复杂的工具和实践环境。平台工程将内部开发者平台视为一种战略产品，将开发团队视为有价值的客户。这一转变正当其时，因为软件实践的快速演进给开发者带来了认知负荷危机，他们必须同时处理日益增长的责任。平台工程旨在解决这一危机，我们将深入探讨其商业价值以及它如何增强协作的 DevOps 文化。
开发者的认知负荷危机
我们工具链中添加的每一个新工具，以及交付流程中加入的每一个新实践，都承诺能加速交付或提高软件质量。然而，其累积效应可能给我们的开发团队带来不可持续的认知负担。试想一下，开发者必须同时处理版本控制系统（SCM）、CI/CD 流水线配置、基础设施即代码（IaC）模板、安全扫描工具、部署策略、监控系统以及许多其他专业工具。每种工具都有其自身的复杂性、最佳实践和故障模式。
随着团队在整个开发生命周期中采用 AI 驱动的工具，这种认知负担尤为突出。虽然这些工具承诺加速交付，但它们通常需要深厚的专业知识才能有效实施。平台工程可以封装这种复杂性，通过标准化的接口和模板让 AI 能力易于访问，无需每个开发者都成为 AI 专家。
数据揭示了一个令人担忧的现实：Harness 最近对工程领导者进行的一项调查发现，78% 的开发者至少有 30% 的时间花在手动、重复的任务上，而不是编写代码。时间被运维职责和工具管理所消耗——这些活动虽然必要，却将开发者从他们最有价值的工作中拉开：为业务问题创造创新解决方案。除了时间损失本身，更令人担忧的是专注力的分散，这会产生认知负担，直接影响交付质量和速度。遗留流程往往会加剧这一挑战，产生低价值的工作，阻碍深度和创造性思维。
上下文切换的代价是巨大的。当开发者不断在编写应用程序逻辑、调试流水线、调查安全警报和排查生产问题之间切换时，每一次转换都会带来精神上的损耗。这种损耗不仅会减慢功能交付速度，更从根本上破坏了实现开发者卓越的条件。深度、不受干扰的专注时间能驱动软件质量和创新。当开发者不断在编码和运维任务之间跳跃时，技术卓越和创造性问题解决能力都会受到影响，从而导致技术债务的累积。
这个问题不仅影响生产力指标，还直接影响士气、员工留存和吸引顶尖人才的能力。最优秀的工程组织都明白，卓越的开发者体验——即工程师能花更多时间解决问题，更少时间与低效作斗争——不仅能带来更好的软件，还能培养出顶尖人才蓬勃发展并留下的文化。一个成功的平台将解决这些不满的根源，开发者会蜂拥而至。如果大多数开发者都必须被迫使用某个平台，那么该平台或其推广方式很可能存在问题。
从工具链到平台即产品
平台工程师通过创建能够让开发者最大限度地提高生产力的环境来直接解决开发者体验问题。这意味着设计、构建和维护底层的开发者平台，以实现应用程序和服务的顺畅开发、部署和运营。
开发者平台通常涵盖多个领域，如图 10-1 所示。这包括一个门户、CI/CD 流水线和 IaC。确保安全、合规和云成本合规的自动化措施贯穿始终。
开发者平台可以通过多种方式构建：平台团队可以从各种工具中组装它们，组织可以从 GitLab 或 Harness 等供应商那里购买预打包解决方案，或者他们可以使用 Humanitec 等编排工具在现有工具集之上创建一个统一层。实际上，大多数实施方案都是这些方法的组合，而不是遵循单一的纯粹策略。团队通常会选择一个策略，并对组织重要但不完全符合策略的事项做出一些调整。作为务实的解决问题者，工程师们经常混合使用策略，根据关键的组织需求调整他们选择的方法，并最终使其奏效。
平台提供“铺就的道路”——开发团队可以自信遵循的成熟模式和实践。“铺就的道路”通常以应用程序或基础设施模板的形式出现。以一个标准的 Web 应用程序模板为例。从零开始，开发者可能需要几天时间才能手动将基础功能连接起来并设置部署——这是一项繁琐且重复的工作。而平台提供的模板预配置了必要的框架。这包括指标收集的标准化方法、容错模式、具有合理默认值的安全配置，以及带有请求跟踪的结构化日志——所有这些都集成在一个内聚的框架中。模板可以超越应用程序代码，包括基础设施定义和部署流水线配置，形成一个全面的应用程序基础。
此外，平台通常还提供模板，这些模板在应用程序层面标准化了处理认证、日志记录和错误处理等横切关注点的方法，并封装了组织的最佳实践。运维层包括集成安全扫描、负载测试和自动回滚程序的部署流水线。基础设施层利用自动化来配置具有适当安全组、监控配置和灾难恢复程序。
这些能力通过自助服务门户或接口暴露，这些门户或接口抽象了底层复杂性，同时维护了安全和合规的护栏。例如，平台可以提供一个用于配置数据库的 API，该 API 根据组织标准自动配置备份计划、加密和访问控制。
其好处显而易见：模板自动化了繁琐的设置和配置工作，同时嵌入了最佳实践、安全和合规标准，而不是让团队自己拼凑工具。这使得开发者效率更高——有了模板化的代码，他们可以立即专注于构建功能。此外，当他们转到另一个项目时，无论是由于团队变更还是需要更新依赖项，由于熟悉的环境，他们会感到更舒适、更高效。同时，这种增加的一致性降低了风险，因为管理少量标准工具和模板的风险比管理组织中散布的独特“雪花”更容易。
值得注意的是，平台团队提供的具体模板和自动化工具会因组织而异。没有“一刀切”的方法。平台团队的重点必须是精准地解决其内部开发团队的独特需求和用例。一个拥有严格合规要求的大型金融机构适用的方案，很可能与为快速发展的初创公司构建的平台截然不同。关键在于平台团队要深入理解其“客户”——开发团队——并根据他们具体的痛点和工作流程量身定制其产品。在本章后面，我们将深入探讨平台工程所需的产品思维，以确保团队真正成为一个以开发者体验为核心的服务提供商。
平台工程的商业价值
平台工程的商业价值建立在一个简单的前提之上：通过简化软件开发和运维，我们可以实现开发者和运维的生产力提升，从而提高团队效率并降低与风险相关的成本。考虑一下开发者时间的成本。如果大多数开发者将大约 30% 的时间花在重复、无附加值的任务上，对于一个只有 250 名开发者的组织来说，这将转化为可观的可回收成本。在我们调查的公司中，开发者的年平均收入为 107,599 美元，相当于每年每位开发者损失超过 32,000 美元的生产力。对于拥有 250 名开发者的组织来说，这代表了每年因开发时间损失而产生的 800 万美元隐性成本。
平台工程提供的开发者平台自动化了许多此类重复任务，从而挽回了损失的时间。平台标准化和集中式平台开发消除了跨团队重复的努力。这使得运维团队能够在现有人员编制下支持更大的应用程序组合，同时保持一致的安全和合规标准。
平台工程的投资回报率（ROI）超越了开发者生产力。它解决了让团队夜不能寐的业务风险。开发者平台的铺就之路通过消除跨团队不一致实施所产生的安全漏洞，降低了安全漏洞的风险和潜在成本。凭借标准化的部署流程和监控实践，平台团队可以降低服务中断的频率和影响。通过将高可用性和灾难恢复的成熟模式嵌入到平台组件中，组织即使在事件发生期间也能保持业务连续性。同时，内置的合规控制和自动化审计追踪帮助组织避免代价高昂的监管违规。
平台工程还可以作为更广泛组织举措的强大加速器，例如云迁移或应用程序现代化。通过提供标准化和自动化的基础，平台工程创建了可重复的路径，从而加快了时间表并降低了风险。
支持协作式 DevOps 文化
平台工程支持开发、运维和安全团队之间的协作，这是我们在前面章节中反复提及的主题。一个统一的、自助服务的平台充当着协作的桥梁。平台不再是孤立的职责和潜在的摩擦点，而是带来了更集成的生态系统，其中运维和安全要求在平台的铺就之路上得到直接和自动的解决。
这些“铺就之路”为开发者提供了预先批准的、安全的模式和自动化工作流程，它们天然地融入了安全最佳实践。
这在受监管的环境中尤其强大：平台团队无需为每个应用团队重复实施新的规定，从而避免了极可能出现的不一致性；相反，平台团队可以在平台层面一次性实施这些规则，确保所有团队都符合要求。开发者可以专注于创造业务价值，同时通过平台护栏自动遵守运维和安全标准。最终结果是一个更加精简、安全的软件交付流水线。
创建和运营平台团队
既然我们理解了平台工程的价值（“为什么”），接下来我们将转向实施（“如何做”）。在本节中，我们将探讨如何建立和运营高效的平台工程团队。我们将研究成功团队的关键特征，讨论使平台团队与开发需求紧密结合的协作模式，并审视支持可伸缩、高性能平台工程职能的运营模式。
平台团队的关键特征
最成功的平台工程团队不仅拥有深厚的技术专长，还具备产品洞察力和客户同理心。从平台领导层开始：领导者需要具备深厚的技术功底，以理解组织中开发者面临的挑战，同时还要具备战略眼光，使平台与业务目标保持一致。他们必须在工程师和业务利益相关者之间保持信誉，弥合技术与战略之间的鸿沟。理想的领导者应在开发、运维和安全这三个领域拥有深厚的背景。这种侧重将有助于指导团队和组织朝着正确的方向前进。
平台团队本身应该成为您开发组织的一个缩影，涵盖开发、安全和运维方面的专业知识。这种跨职能的知识使团队能够创建集成的解决方案，以满足开发者的所有需求。团队应包括在安全和合规等关键瓶颈领域有经验的工程师，以及精通开发、企业架构和现有工具的工程师。随着 AI 成为软件交付的基础组成部分，平台团队受益于至少包含一名具有 AI/ML 运维专业知识的成员。这个角色弥合了数据科学和软件交付之间的差距，帮助团队有效地将 AI 驱动的工具集成和管理到平台中。他们确保 AI 组件保持可靠、可解释，并符合组织治理要求。
请记住，平台是一种产品，而开发者是其客户。为了确保平台基于开发者需求而非仅仅平台团队偏好而发展，团队需要强大的产品管理能力。这包括用户研究、路线图制定和采用率衡量等技能。通过理解开发者需求并衡量平台有效性，团队可以确保平台始终是整个组织的宝贵资产。
有效的协作模式
在开始平台实践时，首要考虑的问题之一是确定团队将如何与更广阔的组织进行协作。一个成功的平台团队需要一种协作模式，这种模式能深入理解开发者需求，并促进组织内部的有效协作。平台团队还必须以周到且结构化的方式与其“客户”——开发团队——进行互动。
“沉浸式项目”是一些组织中效果良好的协作模式的一个例子。在这种模式下，平台工程师会暂时嵌入到各个开发团队中。这种亲身体验的方式让团队能够洞察开发者日常面临的挑战；它培养了同理心，并加深了对他们需求的理解。通过与开发者并肩工作，平台工程师可以识别痛点、瓶颈和改进机会。这确保了平台在保持中心化治理结构的同时，与特定团队的独特需求同步发展。当你刚开始进行平台工程时，这种模式尤其有效，因为它有助于深入了解团队的挑战和限制。
另一个选择是建立一个卓越中心（Center of Excellence）。这种类型的平台团队作为一个独立的、跨职能的团队运作，服务于所有开发团队。他们就平台功能提供反馈，倡导采用，并协助将平台能力整合到开发工作流程中。组织内部的协作确保平台与开发社区不断演进的需求保持一致。这种模式适用于项目多样化的大型组织，因为它提供了清晰的所有权和集中的最佳实践，同时减少了重复工作。
此外，混合模式（即平台工程师既作为集中式专家又作为嵌入式资源）提供了两全其美的优势——工具和流程的一致性与对特定产品挑战的深入了解相结合。
选择正确的模式取决于您组织的规模、复杂性和战略重点。您平台的成熟度阶段也可能是一个因素。随着平台成熟和用户群增长，协作模式需要扩展。虽然对于早期采用者来说，高接触支持可能可行，但对于广泛采用来说，更具可伸缩性的方法是必要的。通过全面的文档和直观的工具实现的自助式入职，允许团队无缝且自主地与平台集成。
最后，尽管这些模式都为平台的成功提供了结构基础，但它们必须通过强大的机制来衡量和验证平台的有效性。在本章后面，我们将探讨如何确保建立系统化的反馈循环，以衡量开发者满意度和平台采用情况。
高效的运营模式
协作模式指导平台团队如何与开发团队互动，而运营模式则定义了平台团队的内部流程和原则。运营模式对于服务开发团队同时保持高运营标准至关重要。它决定了团队如何运作、分配资源以及与更广泛的组织互动。一个有效的模式能在赋能与控制之间取得平衡。
一个强大的运营模式会优先考虑自助服务能力，从而赋能开发团队快速且独立地行动。平台团队通过自动化和模板产品维护适当的护栏，这些产品封装了组织的最佳实践。
清晰、及时和易于访问的文档是有效运营模式的另一个特征。文档应赋能开发者理解和采用平台功能，而无需平台团队的亲自指导。
最后，您的运营模式应能同时处理战术和战略需求——为关键问题实施服务水平协议（SLA），同时预留专用时间用于平台改进和处理开发者反馈。支持轮岗和工程冲刺等技术可以帮助团队管理这种平衡。
定义您的平台战略
一个连贯的平台战略应完全聚焦于您的开发者需求。它考虑了您组织的限制以及对您业务最重要的目标。在本节中，我们将讨论您的战略应如何清晰地阐明一套指导决策的原则。我们将探讨深入理解平台客户应如何驱动初始范围的确定。最后，我们将讨论您在通过平台实现标准化与在需要时允许团队灵活偏离之间可能遇到的挑战。
设定平台原则
平台战略始于清晰的原则，这些原则阐明了您的平台团队将如何处理解决方案。当团队被拉向许多不同的方向并被要求解决日益增长的问题时，清晰的原则就像指南针。它们指导决策，并为评估权衡、解决冲突以及在平台开发的复杂性中保持专注提供了框架。一旦您定义了这些原则，将其在整个组织内分享以获得一致性，这将有助于团队取得成功。
以下原则是任何平台战略都应具备的基础：
- 开发者体验和效率是平台设计的主要驱动力。 每项功能都应旨在降低认知负荷并简化开发工作流程，而不是增加复杂性。
- 安全和合规要求无缝嵌入平台。 这使得开发者“做对事情”比绕过控制更容易。这种方法在不阻碍生产力的情况下，培养了一个安全的开发环境。
平台演进由可衡量的开发者需求和可证明的业务成果驱动。
平台演进并非仅由平台团队的技术偏好或任何特定开发团队的强烈意见驱动。平台团队将征求开发者的反馈，跟踪平台使用情况，并衡量其对部署频率和交付周期等关键指标的影响。
一个关键的战略决策是平台采用应该是强制性的还是可选的。强制性平台可以推动一致性和标准化，但有降低提供卓越开发者体验的激励的风险。另一方面，可选采用则迫使平台团队赢得信任并证明价值，从而带来更多以用户为中心、创新的解决方案。虽然这种方法可能造成碎片化，但它在实践中而非仅仅理论上促进了卓越。有些组织从可选采用开始，后期再引入强制性措施，以巩固成果并吸引后来的采用者。
平台反模式与冲突解决
与您的平台战略应该包含什么同样重要的是，它应该避免什么。常见的、会破坏平台成功的反模式包括：
完美主义而非进展
延迟平台发布直到“完美”，通常意味着开发者在此期间会创建自己的解决方案，从而使最终的采用变得更加困难。
技术驱动的开发
构建平台功能仅仅因为它们在技术上有趣或很酷，而不是因为它们解决了真实的开发者问题。
未证明价值的强制采用
在平台价值尚未证明之前就强制团队使用，会产生抵触情绪，并可能长期损害平台的声誉。
当原则相互冲突时（这不可避免），拥有一个清晰的优先级框架会有所帮助。例如，当安全要求与开发者体验发生冲突时，大多数组织需要一种结构化的方法来解决这种矛盾。成功的平台团队通常会优先考虑：
- 具有监管风险的安全和合规要求
- 针对高频活动的开发者体验
- 运营一致性的标准化
- 创新和灵活性
这种层级结构有助于团队在原则冲突时做出一致的决策。面对此类冲突时，平台团队应记录矛盾、决策过程和最终解决方案，为未来的决策创建先例。
允许这种模式以安全之名支持导致糟糕开发者体验的选择是危险的。你已经种下了规避或操纵平台的种子。将此类决定视为必要的权宜之计，然后努力开发一种更高效、更愉快的方式来满足治理控制，才是长期成功的关键。
了解您的平台受众
回到我们的第一条原则：开发者体验和效率是平台设计的主要驱动力。一个成功的平台战略始于深入了解您的开发团队需求以及更广泛的组织背景。沉浸式协作模式在这里可以发挥作用。通过这种模式，平台工程师会暂时嵌入到各个应用团队中。通过与应用开发者并肩工作，并通过密切观察和提问来了解他们的工作，平台团队成员能够更好地识别常见的摩擦点、瓶颈和改进机会。在考虑时，既要关注阻碍开发者生产力的即时痛点，也要关注长期的战略目标。
选择平台范围
一旦您开始对平台受众有了清晰的认识，下一步就是定义平台功能的初始范围。最有效的方法是从小处着手，专注于能够立即提升开发者生产力的基础要素。精简的基础设施配置、自动化交付流水线和集成安全自动化都是很好的例子。随着平台成熟和组织需求演变，您可以逐步扩展到更高级的领域，例如创建全面的开发者门户或引入自助分析工具。关键在于抵制一次性解决所有问题的诱惑——成功的平台会稳步增长，以所展示的价值和其服务团队的持续反馈为指导。
一个实用的路线图示例
让我们通过一个实际例子来说明如何根据对受众的理解来选择初始范围。一个有用的方法是，将重点放在那些已经在推动快速创新的团队和用例上。例如，正在采用新技术或向云平台跃迁的团队常常面临严峻的挑战，即使是一个简单的平台也能迅速帮助解决这些问题。
在我们的例子中，我们决定将精力集中在支持一个正在向 AWS 和 Kubernetes 上的微服务转型的应用团队。这个团队正 struggling with 标准化的基础设施和部署模式。通过解决这一具体需求，我们可以展示平台的价值，并在组织内部获得牵引力。在确定早期采用者团队时，我们谨慎地选择了一个积极参与平台产品改进并乐于提供频繁反馈的团队。
在这种情况下，我们首先创建一条“铺就之路”，以简化常见任务。我们自动化了从仓库创建到 CI/CD 流水线配置和基础设施配置的整个新微服务创建过程。一开始，这不需要涵盖流水线中的所有工具。我们专注于只包含核心的构建、部署和治理层，并将组织标准直接嵌入到我们的模板中。根据我们的第二条原则，安全要求、合规控制和运维最佳实践都已内嵌。我们与合规和安全团队紧密合作，以确保我们的自动化模式符合他们的要求。目标是，通过使用我们的平台，应用团队默认就能“做对事情”。
另一个容易取得成功的建议是，考虑将审计帮助作为一项服务，作为平台的一部分提供给应用团队。构建自动代表他们回答某些审计问题的功能。因为您在构建系统时就考虑到了内部审计，所以这将很容易提供，并有助于推动采用并取悦您的用户。
平衡标准化与灵活性
在建立平台工程实践时，您可能会发现在通过平台路径标准化软件交付与赋予团队所需（或仅是想要）的灵活性之间存在挑战。通过标准化平台路径实现一致的软件交付，是确保平台可靠性、运营效率以及最终业务价值的关键。然而，您的平台应允许一定程度的团队自主性；团队应能够创新，以找到最适合其特定需求且高效的解决方案。一个过于主观且路径僵化的模板只会阻碍您平台的采用。
解决这一挑战的一种方法是将模板组件分为以下三类：
强制性组件
这组组件处理日志配置、监控设置和安全控制等功能。这些都是任务关键型关注点（安全、可观测性、合规性），并且严格标准化。它们的包含是强制执行的。
可配置组件
这些组件包括资源扩展配置、缓存设置和数据库连接。团队应能根据需要进行配置，而不会影响标准化的总体目标。
扩展点
最后，扩展点应允许团队自定义健康检查、配置专用中间件以及定义团队特定指标等方面。清晰的 API 文档提供了这些扩展点，定义了标准化组件和灵活组件之间的明确接口。
通过这种模块化方法，团队可以使用铺就的路径模板，同时又具有根据自身需求进行调整的灵活性。构建高吞吐量服务的团队可能会自定义扩展配置并添加专门的性能指标，而构建安全敏感服务的团队可能会添加额外身份验证中间件和审计日志。
治理在这种平衡中起着至关重要的作用。有效的平台利用策略即代码（PaC）和自动化验证来创建护栏，防止严重问题，同时允许在安全范围内进行偏离。例如，您可能不会强制规定每一种技术选择，而是实施自动化检查，以验证是否满足了关键要求，而无论具体实现如何。这种方法允许团队创新，同时确保维持基本标准。
平台度量与演进
平台战略就绪后，下一步是衡量其有效性并推动其采用。本节将探讨如何定义和跟踪指标以证明平台价值，然后审视鼓励开发者参与和平台利用的策略。
衡量平台成功
不衡量，便无法改进。将您的平台视为一个同时拥有技术和业务关键绩效指标（KPI）的产品。各项指标应帮助您评估平台对开发者和业务的价值。关键指标类别包括：
开发者生产力
团队使用平台能以多快的速度发布功能？跟踪部署频率、变更交付周期和平均恢复时间（MTTR）等指标。利用这些指标更好地了解编写代码与管理基础设施所花费的时间。
平台采用率
团队是否真正使用平台？指标应衡量广度（活跃用户数量、利用平台的项目以及新项目入驻的百分比）和深度（团队对现有功能的利用程度）。使用模式可以帮助识别成功的产品和潜在的摩擦点。
运营效率
平台在多大程度上降低了成本或提高了运营性能？查看基础设施成本、事件发生率和支持工单量。
业务影响
最终，平台是否为业务目标做出了贡献？指标应将平台投资与组织成果联系起来，例如更快的上市时间、提高客户满意度或改进产品质量。
我们跟踪平台性能和价值创造，以验证持续改进并指导平台计划。接下来，我们将探讨鼓励平台初步采用并促进平台演进以解锁更多价值的策略。
推动平台采用
在清晰的平台愿景武装下，并基于对受众最迫切痛点的理解，我们接下来的挑战在于推动平台的采用。一个执行良好的采用策略结合了仔细的能力选择、无缝访问和积极主动的参与。
最小可行平台（MVP）方法将有助于推动早期采用。平台工作应专注于交付一组小而高价值、低投入的功能，以解决开发团队最紧迫的痛点，而不是试图一次性构建所有功能。这些初步的成功将建立信誉并展示我们平台的潜力，从而更容易获得未来扩展的认可和资源。基于我们对受众的理解，考虑那些消耗最多开发者时间或造成最大摩擦的任务。通过首先解决这些挑战，我们可以迅速展示切实的好处，并激发对平台的兴趣。
最后，如果您是一个平台团队，您必须积极推广您的能力。构建一个出色的平台只是成功的一半；您还需要说服开发者使用它。考虑开展开发者教育项目、技术展示，并清晰地沟通平台优势和路线图。举办研讨会和培训课程，教开发者如何有效地使用平台。展示成功的用例，并强调平台对其他团队产生的积极影响。维护一个清晰的路线图，并沟通即将推出的功能和改进，以激发兴趣并鼓励采用。通过积极与开发者社区互动，平台团队可以培养采用文化，并确保平台成为开发工作流程不可或缺的一部分。
利用内部开发者门户推动平台成功
内部开发者门户（IDP）充当着开发团队与您的平台能力之间的接口。门户将所有内容汇集一处，使平台易于发现和使用。最有效的门户包括服务发现、上下文相关文档和自助服务功能，使其成为开发者与平台进行任何互动的自然起点。
核心门户组件
一个精心设计的 IDP 通常包括：
软件目录
一个集中式的服务、API 和组件注册表，包含所有权信息和依赖映射
自助服务工作流
用于常见任务的自动化流程，例如使用“黄金路径”模板创建新服务或配置环境
文档中心
在需要时出现的上下文相关、可搜索的技术资源
记分卡
显示服务成熟度、合规状态和最佳实践采用情况的指标
AI 增强的开发者体验
现代 IDP 越来越多地利用以下 AI 能力来降低认知负荷并加速平台采用：
自然语言界面
允许开发者使用会话式查询查找资源和执行工作流。
智能推荐
根据开发者的上下文和历史记录，推荐相关文档、服务和配置选项。
自动化故障排除
分析错误模式，并在开发者遇到问题时建议潜在解决方案。
预测性辅助
根据开发者的当前活动预测其需求，并主动提供相关资源。
这些 AI 能力将门户从一个被动资源转变为一个主动助手，引导开发者完成复杂操作，而无需他们成为专家。
构建一个有效的门户
为了实现可持续成功，请将您的 IDP 视为一个产品，并为其持续开发投入专用资源。通过衡量开发者采用率、通过自助服务工作流节省的时间以及新开发者达到生产力所需的时间等指标来评估其有效性。
IDP 最近已开始提供现成解决方案。Backstage 最初由 Spotify 开发，于 2020 年开源并捐赠给云原生计算基金会（Cloud Native Computing Foundation）。包括 Roadie、Spotify 和 Harness 在内的供应商已推出了简化 Backstage 采用和管理的商业产品。非 Backstage 的商业 IDP 也已上市，例如 Atlassian 的 Compass。
一个精心设计的 IDP 能够降低认知负荷，加速入职流程，并使平台采用成为阻力最小的路径，从而彻底改变开发者体验您整个平台产品的方式。
平台的可持续演进
在初步采用之后，下一步是确保平台的可持续演进。这取决于平衡开发者赋能与平台完整性，这通过策略即代码（PaC）和自动化、持续反馈循环以及对可靠性和可伸缩性的持续投资来实现。利用实现“信任但验证”的 PaC 自动化是实现这种平衡的一种方式。通过将组织标准编码为可编程策略（使用 OPA 或自定义强制执行引擎等工具），您的平台团队可以在保持合规性的同时委托控制权。
策略和策略即代码可以赋予开发团队一定的控制权，以减少瓶颈并提升敏捷性，同时又不牺牲标准化。例如，策略可以定义可接受的资源使用限制，强制执行安全最佳实践，或确保符合组织标准。开发者可以在预定义的边界内操作，知道他们的行为不会损害平台的稳定性或安全性。至关重要的是，策略还可以用于预告即将到来的变更，例如弃用旧系统或模板。通过提前发出警告，开发者有时间迁移到更新、受支持的选项，确保平稳过渡，并在旧系统最终退役时最大程度地减少中断。
AI 技术正在迅速发展，为平台团队带来了机遇和挑战。在将新兴 AI 工具整合到您的平台之前，建立一个系统化的评估方法至关重要。创建一个沙盒环境，您可以在其中使用您组织的数据针对真实世界的场景测试有前景的技术。制定明确的标准，将 AI 能力从实验阶段提升到生产就绪阶段，包括对可靠性、可解释性和治理的考虑。这种方法允许您的平台受益于 AI 进步，同时管理快速发展技术带来的风险。
平台演进必须由经验证据而非假设来指导。您的团队必须养成定期审查“平台智能三角”的习惯——即平台使用指标、支持请求和开发者反馈的组合。利用这些信息来指导路线图制定，并识别开发者需求和痛点。某些功能是否未充分利用？是否有常见的支持请求表明需要改进的领域？例如，如果您注意到某个特定服务的支持工单量增加，同时使用模式下降，这可能表明存在需要立即关注的可靠性问题。定期平台健康检查应同时检查技术指标（错误率、响应时间）和采用指标（功能使用情况、团队入职成功率）。
最后，对平台可靠性和可伸缩性的持续投资是必不可少的——一次重大的中断可能会抹去数月建立的信任。随着平台采用率的增长——以及平台负载的增加——对可靠性工程的投资变得更加关键。开发者需要相信平台在需要时可用，并且能够持续稳定运行。这包括实施
健壮的可观测性、建立清晰的事件管理流程，并与开发团队保持透明的沟通渠道。
一个实际案例：平台工程实践
举例来说，一个拥有 1400 名开发者、分布在 80 个产品团队的金融服务机构正面临着严峻的交付挑战。一项审计揭示了安全实践的不一致性，而首席技术官（CTO）则担忧速度和合规风险。同时，内部指标显示开发者将近 45% 的时间花在了非编码活动上——管理流水线、配置环境以及处理安全和合规要求。
为了应对这些挑战，该组织组建了一个由六人组成的专门平台团队：一名平台工程主管、一名拥有 CI/CD 专长的高级开发者、一名安全工程师、一名运维工程师、一名拥有 Kubernetes 专长的平台工程师，以及一名兼顾文档工作的技术产品经理。
发现与战略制定
团队首先进入了密集的发现阶段，以了解开发者痛点和合规要求。他们实施了一个结构化的沉浸式项目，将团队成员嵌入到代表性的产品团队中，观察工作流程并记录挑战。这项研究揭示了常见的痛点：
- 跨团队维护独立 CI/CD 流水线的重复工作
- 安全扫描实施不一致
- 手动环境配置导致延迟和不一致
- 跨团队对合规要求理解不清且实施方式不同
同时，团队通过与首席信息安全官（CISO）团队、企业架构、合规和法务部门的研讨会，与治理利益相关者进行互动，以了解安全控制、技术标准、审计要求和数据处理要求。
基于这项研究，团队制定了具有明确原则的平台战略：
- 开发者体验驱动平台设计——降低认知负荷。
- 安全与合规内置，而非外挂。
- 一切皆可衡量——只关注有价值的产出。
- 平台可选但具有吸引力——解决实际问题。
团队特意将初始范围聚焦在一个高影响力能力上：带有嵌入式安全控制的安全 CI/CD 流水线。
构建最小可行平台
团队在八周内交付了 MVP：一个模板驱动的流水线系统，内置安全扫描。主要组件包括：
- 包含不同应用类型最佳实践的流水线模板
- 直接集成到流水线中的预配置安全扫描
- 针对合规要求的自动化证据收集
- 通过简单的 YAML 文件实现自助服务配置
团队将所需的安全控制直接嵌入到流水线模板中，并自动运行静态分析、依赖扫描、容器扫描和合规性检查。结果反馈到一个集中式仪表板，同时自动化证据收集简化了审计准备。
通过自动化关键检查，包括所需的代码覆盖率，平台上的应用团队的变更管理流程得到了显著简化。他们很高兴获得免于参加 CAB（变更审查委员会）的特权。
平台团队与两个试点团队紧密合作，根据每周反馈完善他们的产品。文档与代码同步开发，包括技术参考资料和实用指南。
在三个月内，MVP 在试点团队中显示出令人印象深刻的成果：
- 部署时间从五天缩短到六小时。
- 安全扫描覆盖率从 40% 提高到 100%。
- 审计准备时间从几天缩短到几小时。
- 通过自动化扫描发现并修复了关键漏洞。
在六个月时，有 15 个团队（约 250 名工程师）正在使用安全流水线模板，这些团队的安全事件比非采用团队减少了 40%。
扩展平台能力
基于全面的遥测数据和用户反馈，平台团队确定环境配置为他们的下一个目标。他们也意识到，随着采用率的增长，他们需要一种更具可伸缩性的方法来进行入职和支持。
他们的下一阶段专注于两个关键能力：
- 一个作为所有平台能力单一接口的 IDP，包括：
- 带有自动化发现的服务目录
- 安全流水线的自助入职
- 集成文档和指南
- 流水线状态和安全发现的实时可见性
- 适用于常见应用模式的 IaC 模板，其中包含了以下最佳实践：
- 安全网络配置
- 正确配置的访问控制
- 符合合规性的日志和监控
- 资源限制和成本控制
这些模板与 IDP 集成，使开发者能够以最少的努力配置符合要求的环境。
扩展后的平台显著提高了采用率。在六个月内：
- 45 个团队（约 600 名开发者）正在使用安全流水线。
- 30 个团队已采用 IaC 模板进行环境配置。
- 平台每月处理超过 2000 次部署。
- 由于自助服务能力，每位用户的支持请求下降了 70%。
尽管服务了数百名开发者，平台团队仍保持六人规模，通过利用自助服务能力和自动化来扩大其影响力。
企业级采用和业务影响
为了推动更广泛的采用，平台团队制定了一个多方面的策略：
- 内部活动，展示平台能力和成功案例
- “平台冠军”计划，在每个部门识别倡导者
- 高管仪表板，展示采用指标和业务影响
- 培训计划，包括自学和讲师指导选项
首席技术官（CTO）建立了采用激励机制，平台用户在云资源和简化合规审查方面获得优先权。
随着平台采用的增长，治理方法也随之演进。安全和合规要求不再通过手动审查和文档，而是直接通过以下方式编码到平台中：
- 自动强制执行标准的策略即代码（PaC）框架
- 满足审计要求的内置证据收集
- 针对合法边缘情况的自助服务异常处理流程
- 通过平台遥测实现自动化合规报告
截至第 18 个月，平台取得了显著成果：
- 85% 的开发团队（约 1200 名开发者）使用该平台。
- 开发者生产力提高了 35%。
- 组织范围内的部署频率增加了 6 倍。
- 从故障中恢复的平均时间减少了 70%。
- 平台用户的安全事件减少了 65%。
- 审计准备时间缩短了 90%。
- 新功能上市时间缩短了 40%。
这些改进转化为切实的业务成果：更快的功能发布、对市场变化的更迅速响应、更少的停机时间以及更低的安全和合规风险。
持续改进
在旅程三年后，平台团队持续发展其产品。他们的路线图包括 AI 辅助开发能力、高级可观测性工具、扩展的安全自动化，以及基于持续研究的开发者体验改进。
本次平台工程之旅的关键经验包括：
产品思维至关重要 将开发者视为客户能驱动更好的决策。
自助服务是规模化的关键
采用敏捷方法，迭代交付。
指标驱动投资
衡量技术成果和业务影响。
治理集成创造双赢
正确的工具可以将合规性从束缚变为加速器。
这个例子展示了一个小型、专注的平台团队如何通过系统性地满足开发者需求，同时精简治理要求，从而推动组织实现重大转型。通过从高影响力能力入手，衡量成果，并将平台视为产品，该团队实现了惊人的规模，仅用六名平台工程师就服务了 1400 名开发者。
结论
当我们结束对现代软件交付的探索时，有一点是明确的：AI 不仅仅是 DevOps 工具箱中的另一个工具；它正在从根本上改变我们构建和交付软件的方式。
在本书中，我们已经看到 AI 如何影响软件生命周期的每个阶段。从仓库中的代码模式检测到测试选择优化，从识别安全漏洞到自动化云成本优化，AI 能力正迅速成为现代交付实践不可或缺的一部分。
平台工程将这些元素结合在一起，创建了一个基础，其中 AI 驱动的能力协同工作，在保持治理的同时加速交付。通过构建抽象复杂性并嵌入最佳实践的开发者平台，团队可以更多地专注于创造业务价值，而减少在传统上消耗大量开发者时间的无差异繁重工作上。
撰写本书时，用于开发者编码助手的 AI 比用于软件交付许多其他部分的 AI 更加成熟。这预示着 DevOps 团队将面临新的压力，因为创新将越来越受限于组织验证和交付这些应用的能力，而非生成代码的能力。交付卓越性，越来越依赖于 AI，将是决定谁能充分利用编码技术进步以及谁将感到沮丧的关键因素。
展望未来
向 AI 原生交付实践的转变仍处于早期阶段，但方向是明确的。有效将 AI 整合到其交付流水线中的组织将获得显著优势：
- AI 消除瓶颈并自动化常规任务，从而加速交付周期
- 通过 AI 驱动的测试和漏洞检测，提高质量和安全性
- 通过智能资源优化和自动化修复，降低运营成本
- 随着认知负荷从运维问题转向创造性问题解决，开发者体验得到提升
在实践中，这意味着部署决策将越来越多地基于复杂的 AI 分析而非仅凭人工判断。测试策略将根据代码变更动态调整，而非遵循僵化的模式。基础设施将根据应用需求进行自我优化，而无需人工调优。
开始行动
如果您希望在您的组织中实施这些实践，我们建议采取务实的方法：
- 首先找出您最痛苦的瓶颈。您的团队在哪些低价值活动上花费了最多时间？这些是您采用 AI 驱动自动化时的主要目标。
- 小步开始，持续衡量。实施聚焦的改进，验证其影响，并利用这些成功推动进一步的采用。
- 为您的开发者构建，而不是为工具构建。对您的交付平台采取产品思维，确保它真正解决了团队的实际问题。
- 内嵌治理，而非事后补救。利用您的平台使合规性和安全性成为开发流程的无缝组成部分，而不是事后考虑。
在这个新时代中蓬勃发展的组织，不一定是拥有最大工程团队或最多预算的组织。相反，它们将是那些最有效地利用 AI 来交付更好、更快软件，同时保持企业运营所需的治理护栏的组织。
这不会一蹴而就。像任何重大转型一样，它需要坚定的领导力、持续学习以及挑战既定流程的意愿。但其回报——以开发速度、产品质量以及最终的业务成果衡量——使得这一旅程值得 undertaking。
软件交付的未来是智能的、自动化的，并为以人为本的开发者需求而构建。我们希望本书为您提供了技术理解和实用策略，助您今天就开始在您的组织中构建这样的未来。