平台工程是为开发人员构建和维护自助服务平台的学科。该平台提供了一套云原生工具和服务，可帮助开发人员快速高效地交付应用程序。平台工程的目标是通过标准化和自动化软件交付生命周期 （SDLC） 中的大多数任务来改善开发人员体验 （DX）。开发人员无需进行上下文切换（如预配基础结构、管理安全性和学习曲线），而是可以专注于使用自动化平台编码和交付业务逻辑。
平台工程具有内向的视角，因为它专注于优化组织中的开发人员以提高生产力。组织从以最佳级别工作的开发人员中受益匪浅，因为它可以缩短发布周期。该平台通过提供开发人员将代码投入生产所需的一切来实现这一目标，这样他们就不必等待其他 IT 团队提供基础架构和工具。使开发人员的日常活动更加轻松和自主的自助服务平台称为内部开发人员平台（IDP）。
从 devops 到平台工程的转变可能是变革性的。以下是实现这一飞跃的原因和内容。
不久前，工程师还需要手动配置系统。在那些日子里，开发人员起草了程序文档供管理员在部署应用程序时遵循。 Devops 工具和实践，包括使用 CI/CD 进行部署、将基础架构配置为代码以及管理容器化系统，所有这些都使 IT 团队能够提高系统可靠性、安全性和性能。
结果是更多的 DevOps 团队可以更快地部署应用程序更改和扩展云基础架构。 Devops 团队从季度发布周期转变为更持续的部署实践，云工程师开发了自动化以根据计算需求扩展云基础设施。
使用 devops 实践，敏捷开发团队构建并增强了应用程序以实现关键任务工作流和创收体验。开发微服务并部署到多云架构提供了更大的灵活性，但也增加了响应中断、性能问题或其他重大事件时的复杂性。许多组织采用站点可靠性工程 (SRE) 实践并部署了 AIops 平台，以提高其服务和应用程序的可靠性和性能。
IT 在普遍在 devops 方面苦苦挣扎
成熟的 DevOps 和 SRE 能力需要在开发技能、实践和文化变革方面进行大量投资。对于 CIO 和 IT 领导者来说，往往会出现两个基本问题。
首先，许多组织都在为技术能力和技能差距而苦苦挣扎，因此尽管他们的开发运营和 SRE 实践很先进，但广泛采用更具挑战性。这些组织可能会成功地为其云原生和现代化应用程序构建 CI/CD 和 IaC，但他们很难将这些功能用于标准化实践。
对于技术更先进的组织，问题就不同了。这些组织更有可能采用自组织实践，并授权团队配置特定于其应用程序架构要求和实施价值的 DevOps 工具。他们可能拥有标准化平台，但每个团队使用这些工具的方式不同。因此，他们部署定制的 CI/CD 管道、IaC 自动化、云架构和监控配置。
对于这些组织及其领导者来说，问题是如何将 devops 最佳实践转化为可重新利用的模式。更具体地说，如何使敏捷团队能够花更多的时间开发应用程序，减少花在云配置和自动化上的时间。
平台工程发展了 devops
平台工程是 devops 实践的演变，旨在帮助大型组织制定标准、支持可重用配置，并将系统工程作为内部产品功能交付。
“平台工程是 devops 向前迈出的一步，”Semaphore CI/CD 的联合创始人 Marko Anastasov 说。 “平台工程通过创建开发人员可用于快速应用程序开发的“黄金路径”，使开发人员能够更轻松地遵循 DevOps 实践。”
对于大型组织，平台工程可能需要将构建应用程序的开发人员与创建 devops-as-a-product 的平台工程师的职责分离。 Anastasov 说：“平台工程师专注于为开发人员创造方法，让他们能够自助服务编写应用程序所需的工具、库和基础设施。”
改善开发人员体验和生产力
虽然概念简单，但平台工程执行起来并非易事，因为它需要产品开发的思维方式。平台工程师必须开发敏捷开发团队想要使用的产品，而开发人员必须放弃他们对 DIY（自己动手）devops 方法的渴望。
一个起点是基础设施和云供应，IT 可以从标准中受益匪浅，开发人员不太可能有特定于应用程序的架构要求。
Percona 产品管理高级副总裁 Donnie Berkholz 说，“平台工程涵盖团队如何使用自动化和自助服务提供正确的开发人员体验，这样开发人员就可以开始编写代码和实施应用程序，而不必等待用于根据票证请求设置基础设施。”
这就是客户的痛点。如果我是一名想要编码的开发人员或数据科学家，我最不想做的就是开一张计算资源的票。但 IT 和安全领导者也希望避免让开发人员自定义基础设施的配置，这可能会产生高昂的成本并产生安全漏洞。
“公司将更多地采用平台工程，因为他们关心内部开发人员的体验。当这些员工的工作效率较低时，任何阻碍开发人员的事情实际上都是在浪费金钱，”Berkholz 继续说道。
创建可重用、可配置的自助服务组件
考虑平台工程的一种方法是要求开发人员填写以下声明：“我的团队无法投入足够的时间来解决<技术问题>，因为我们正在花时间开发、维护或改进<技术自动化>和<基础设施配置>。”
技术问题通常表示为非功能性需求，例如提高可测试性、性能、可扩展性和安全性，同时减少技术债务。这些都改善了应用程序的最终用户体验，许多 devops 团队希望在这些领域投入更多时间。
与技术自动化和基础架构配置相比，构建基本功能可能是软件开发的先决条件，而持续的投资可以提高开发团队的生产力。不幸的是，开发团队投入到这些领域的时间越多，他们花在交付功能和改进非功能性技术问题上的时间就越少。
在团队在这三个领域投入大量时间并且多个团队有共同需求的情况下，平台工程作为一种可以产生收益的解决方案应运而生。
“正如 devops 框架重塑了可扩展性、可用性和可操作性，平台工程为开发团队的装配线提供了可交换工具的传送带，”Saucelabs 技术战略副总裁 Marcus Merrell 说。 “这使他们能够绕过测试等传统瓶颈，跨项目高效执行，并部署必要的工具来实时满足各种需求并更快地进入市场。”
平台工程的好处
提高质量和更快地交付功能是平台工程的共同目标，那么这种方法如何解决这些问题呢？
“平台工程是创建共享的内部服务的实践，这些服务可以在一个地方为工程师解决问题，”Coralogix 的开发倡导者 Chris Cooney 说。 “平台工程非常擅长解决大规模发生的一些关键问题。”
换句话说，拥有许多开发团队的大型 IT 部门将从平台工程实践中受益。 Cooney 确定了这些问题的平台工程目标：
换句话说，拥有许多开发团队的大型 IT 部门将从平台工程实践中受益。 Cooney 确定了这些问题的平台工程目标：
- 提高团队之间的一致性并减少单一解决方案的心态
- 发现并重用共享组件，而不是重建和定制
- 在平台中构建合规性
所有这些听起来很有希望，但持怀疑态度的人会指出，这并不是大型 IT 部门第一次尝试将内部技术解决方案和平台产品化。在深入研究平台工程之前，组织领导者及其团队可能想回答几个问题
- 平台工程可以在哪些方面通过效率或合规性改进来跨多个团队交付价值？
- 如何在不产生新瓶颈的情况下组织平台工程开发工作？
- 平台工程是否转移了重点，以便开发团队将更多时间花在交付功能和改进非功能性能力上？
虽然平台工程大有可为，但 IT 组织应该从小处着手，抱负简单。确定具有明显优势、技术障碍少且需求普遍的领域，然后从那里开始。