平台工程与DevOps：有何区别

平台工程和 DevOps 都是利用敏捷软件开发方法来缩短发布时间并减少开发障碍的 IT 实践，但它们应用的时机不同，关注的焦点问题也不同。了解它们之间的区别有助于您选择契合自己目标的方法。DevOps 是一种软件开发方法，企业组织可利用它将开发和 IT 运维功能整合到迭代工作流中。而平台工程的重心则在于创建为这些工作流提供支持的内部平台和工具。 

DevOps 结合了开发和运维这两个领域，并通过工具和流程将传统上在企业组织内部彼此隔绝的团队整合在一起。DevOps 采用敏捷原则，这是一种依赖于自我管理团队和快速迭代的开发方法。由于 DevOps 的实施需要团队间的协作、跨职能配合以及建立信任与凝聚力，人们普遍认为，推行 DevOps 需要企业组织进行变革，而不只是简单的流程改变。企业组织的文化需要转变，DevOps 才有可能落实。

软件行业发展到如今，传统的瀑布式软件开发方法往往会减缓创新速度，给企业组织造成障碍与瓶颈，DevOps 和敏捷开发方法的诞生正是为了解决这些局限性。在瀑布式开发体系中，代码需求要先经过功能、效率、标准化以及文档方面的测试，之后才能集成到应用中。预先对这些方面进行测试可能会导致流程冗长，使得项目更难在既定的范围、时间和预算内执行，特别是当项目情况不明或不断变动时。

而 DevOps 则可以运用自动化和循环流程，使开发团队能够迅速将软件从开发阶段推进到生产阶段，并且在软件投入生产后持续进行改进。DevOps 需要通过促进共享专业知识的实践来实现团队之间更紧密的沟通与协作，这些实践也意味着产品改进可以通过迭代的方式集成和开发，而非提前执行，从而避免发布周期过长。实施 DevOps 的企业组织可以随着时间的推移系统地改进软件，从而使团队能够以传统开发模式往往难以实现的方式，适应变化并尝试新方法。

平台工程通过提供标准化的工具、服务和工作流来扩展 DevOps 实践，以便开发团队能够更高效地构建软件解决方案。平台工程是一个近年才出现的术语，它描述了一种对内部服务和资源进行组织的实践；通过这种实践，开发团队能够构建解决方案，而无需直接管理底层元素。平台工程师负责整理和维护开发团队所需的各种工具、服务和文档，并借助称为“黄金路径”的自动化流程，使 IT 组织中的每个人都能更高效地完成工作，而不需要完全靠自己解决所有问题。随着 DevOps 的广泛采用，平台工程也得到了发展，因为平台工程能够提供支撑 DevOps 工作流的底层组件，并助力其在企业组织中实现规模化应用。

在伦敦 DevOpsDays 大会的演讲中，Abby Bangser 用烹饪作比喻，解释了平台工程在 DevOps 中的作用。如果您打算“烹饪”软件（一顿饭），需要一个工具（锅）或配料（欧芹），您可以提出请求，但可能无法得到确切需要的物品。负责置备供应的人员可能无法提供（或者无法获取）您想要的特定食材或物品。在 DevOps 模式下，您可以避免因提出请求和依赖资源置备，但您必须自己创建所需的组件或工具。按照 Bangser 的烹饪类比，这就好比得自己用金属打一口锅，或者从种子开始种植欧芹，这两件事都既困难又低效。

在这一自助服务模式下，日常任务所需的各种技术会让开发团队应接不暇。要在众多工具中不停切换既繁琐，又会降低效率，还会增加团队的认知负担。入职难题也会随之出现：新员工需要费力应对众多工具和系统，这使得他们难以高效融入团队；而资深团队成员也不得不分出精力提供协助，从而偏离自己的主要工作，最终导致整体工作效率下降。平台工程旨在通过减轻这些负担来支持 DevOps 工作流，以便 IT 组织能够专注于创新，同时由平台工程师为其集中整合最佳实践和自助服务体验。

平台工程的幕后故事。视频时长：2:31

进一步了解平台工程

平台工程让 DevOps 团队无需事必躬亲，从而有助于 DevOps 实现规模化扩展。平台工程还可协助建立一套标准化的工具、知识、服务及流程，服务于整个企业组织内的众多开发团队。有了精心打造的平台，开发团队便能够构建、部署、维护并支持自身组件，而平台团队则负责构建、部署、维护并支持平台组件。两个团队都能集中精力，更快地交付成果。平台团队提供“X 即服务”，这样 DevOps 团队就无需每次都临时创建所有内容。

如果平台团队为开发团队提供各种组件，那么平台工程就有可能会产生与 DevOps 最初试图缓解的相同问题和内部依赖关系。如果应用团队需要等待平台团队提供他们所需的资源，那么在这个过程中是否会出现瓶颈？

理论上有这种可能，但平台团队也有潜力减少冗余和重复工作——而这往往会浪费整个企业组织的时间。多个开发团队可以使用同一个自助服务平台，而不必每个团队都创建具有相同功能的自有平台。这样一来便可长久保障一致性，即使现有的开发团队不再负责该项目。此外，这些平台团队会将开发团队视为客户，他们明白，如果不能满足目标用户的需求，这些内部客户就会采用其他类型的基础架构或部署机制，这已然成为他们快速交付的动力。最佳实践和成熟的解决方案均可整合到平台中，团队之间也能更高效地共享知识。

对于了解站点可靠性工程（SRE）的人来说，平台工程可能听起来并不陌生。SRE 是 Google 引入业界的一个术语，用于描述以自动化方式运行产品的系统，而该系统旨在替代传统上由系统管理员执行的手动工作。SRE 负责处理底层基础架构，SRE 团队负责开发流程和自动化功能，以确保基础架构的完整性并维持正常运行时间。SRE 从业者和平台工程师有着共同的目标，但两者的侧重点不同：SRE 侧重于软件的性能、可靠性和规模，而平台工程则侧重于旨在提升开发人员体验的系统。

进一步了解红帽的 SRE 方法

团队通常会利用平台工程，在自助服务门户中创建自己的内部开发平台（IDP）、工具、服务以及文档。平台工程师能够依据用户需求与最佳实践来设计并交付 IDP，并通过用户调研与测试对其进行迭代优化。以开发团队为目标用户，平台工程师可以交付能够实现开发人员自助服务的 IDP，并帮助开发团队减轻认知负担。

对于希望在软件开发生命周期中建立持续集成与持续交付（CI/CD）管道的企业组织，采取 DevOps 实践势在必行。CI/CD 可实现代码测试与构建的自动化，并使软件开发与更新周期处于持续整合状态下，从而最大限度降低漏洞和代码故障所带来的影响。在整个软件开发生命周期中集成并自动化 CI/CD 管道，能让企业组织获得构建高质量平台和更快交付应用所需的可见性。

红帽® 的产品和服务可以协同运作，促进提高开发人员的工作效率，并为企业带来所需的灵活性，从而在提高团队工作效率的同时，增强自助服务能力、加速新员工入职流程，并减少团队间的重复性任务。

红帽开发人员中心是一个基于云原生计算基金会（CNCF）项目 Backstage 而搭建的企业内部开发人员门户。红帽开发人员中心有助于企业组织整合技术选择，增强自助服务能力并加快新员工上手速度，进而提高工作效率。借助该门户，企业组织可以使用内部开发人员门户来整合开发流程元素，简化工作流，并促进内部协作。

红帽 OpenShift® 则可以搭配红帽开发人员中心，使开发人员能够在各类应用中使用其惯用的工具，这些应用包括云原生应用、传统应用以及现代化应用，且无论它们部署在本地、云端还是边缘。