平台工程只是 DevOps 专业化的另一个术语，还是有什么不同？事实可能介于两者之间。DevOps 及其相关的 DevXOps 风格具有浓厚的文化色彩，将各个团队置于中心位置。不幸的是，在许多地方，DevOps 导致了新的问题，例如工具激增和整个企业缺乏协调。有人可能会说，为了应对过去非常严格的孤岛和强烈的集中化，DevOps 已经将钟摆推向了联合——因此，在团队层面上进行了次优化——从而损害了组织。规模更大、更复杂的企业对此感受最深，因为它们必须处理整个组织中不同的技术堆栈和不同的成熟度水平。
平台工程的发展是为了应对这一企业范围的挑战。平台工程并不能替代DevOps。相反，平台工程补充了 DevOps，以解决企业范围内的挑战，并提供一个工具平台，使各个团队更容易做正确的事情，而不是破坏事情，同时尝试保持整个组织的一致性。
过去几年，随着越来越多的应用程序以更快的速度发展，IT 交付的复杂性不断增加。这意味着组织不能依赖个人来控制复杂性；它们需要由适当工具支持的系统答案。这就是平台工程想要解决的问题。因此，平台工程师对于组织来说变得至关重要，因为他们的角色掌握着实现安全和工程标准的关键。
什么是平台工程师？
平台工程师的角色分为三个不同的部分。
图 1.平台工程师的角色
最明显的一个是技术架构师的角色，因为他们必须构建一个连接所有工具并启用流程的工程平台。第二个方面是社区推动者，类似于技术工具公司的开发人员关系角色。第三部分是产品经理；开发者社区的相互竞争的利益和需求需要根据平台的技术需求来优先考虑（考虑安全强化和过时组件修补等问题）。
平台工程师作为技术架构师
在技术堆栈具有中等或高度复杂性的组织中，构建、发布和维护软件所需的工具数量至少有十几个，有时甚至更多。集成这些工具并实现有意义的指标测量与集成业务应用程序一样棘手。毕竟，挑战非常相似：需要协调不同的流程，需要转换数据模型以使其可用，需要连接集成点以启用端到端流程。
运行业务软件方面的系统也变得同样具有挑战性。平台工程师在这里的角色是照顾运行软件端的工具的架构 - 目标是让工具“消失”并使软件的构建和发布看起来很容易。
平台工程师作为社区推动者
软件工程师倾向于认为他们的解决方案比其他人的解决方案更好。因此，工程平台的采用是一个需要克服的挑战。告诉工程师使用特定工具常常会遇到阻力。平台工程师必须是社区推动者，与工程师合作推广平台并让他们相信平台的好处。在这部分角色中，沟通是双向的，因为平台工程师还必须倾听平台的问题和挑战，并确定需求量大的新功能。这就引出了角色的第三部分。
平台工程师兼产品经理
对平台的竞争需求来自组织的工程师和其他利益相关者，例如安全性，当然还有平台工程师。以有意义的方式优先考虑这些需求是一项艰巨的任务，因为您必须在所有相互竞争的利益之间找到平衡，特别是平台的资金本身往往是一个挑战，因此价值实现速度对于平台的持续支持至关重要。平台工程师需要良好的谈判技巧来应对这些挑战。
平台工程架构概述
我们讨论了平台工程师的角色，但是平台工程师正在构建和维护的平台中包含哪些内容？最容易考虑三层和一个目标环境：
- 最顶层是开发者体验。这些是开发人员直接使用的工具——驱动整个工作流程的工具，例如敏捷生命周期管理工具、服务管理工具和开发人员 IDE，都适合于此。
- 底层包括必须组合起来才能构建应用程序环境的基础设施组件。这可以来自公共云或私有云，包括传统的数据中心技术。
- 中间是最复杂的地方——软件工程平台。在这里，创建和交付软件所需的所有流程都在编排：CI/CD、安全扫描、环境配置和发布管理。
图2.平台结构
做出转变：如何在 DevOps 团队中采用平台工程
那么你应该从哪里开始呢？一种成功的采用模式侧重于确定开发人员的旅程以定义最小可行平台。需要哪些能力才能使开发人员的旅程取得成果？想象一下这样的任务：配置环境、将新 API 部署到生产环境或运行性能测试套件。每个都是一个有效的开发者旅程，具有多个接触点，可能需要大量工具。一旦您为第一组应用程序或技术创建了最小可行平台，采用就会遵循三个维度：更多的应用程序（一旦所需的功能可用）、更多的功能和更高的成熟度，从而提高自动化和/或性能的水平。
除了担心如何以合理的方式构建平台之外，还应该尽早解决其他三个方面的问题：
- 社区参与
- 资金
- 衡量平台的结果
定义社区参与策略非常有帮助。该策略应包含如何与开发者社区共享信息、如何提出功能请求以及如何传达平台的优势。定义论坛、通讯及其各自的频率也很有帮助。
资金很快就会成为瓶颈，因此应该在平台工程师采用的早期就资金策略达成一致。这可以是多种策略之一，例如专用资金、为所提供的服务提供资金或对所有软件开发征收服务税。每个都有其自己的优点和挑战，其讨论超出了本文的范围。重要的是要有一个不依赖于利益相关者善意的可持续的长期融资战略。
最后但并非最不重要的一点是，平台工程师需要能够展示结果，这意味着我们需要衡量有意义的指标，以展示为什么公司在使用平台后会变得更好。这常常被遗忘或事后才想到。了解组织的优先事项并根据其调整衡量框架有助于获得持续的支持。不幸的是，这通常需要跨多个工具进行数据对齐，并且在预先考虑时最容易实现 - 各个工具的数据模型保持隔离的时间越长，它就会变得越来越困难。
结论
平台工程仍然是一个相当新的事物，但已经有很多内容，这表明它很快就引起了组织的兴趣。甚至还有一个专门的会议，于 2022 年开始，有数千名参与者。现在还处于早期阶段，但目前的迹象表明，平台工程已迅速获得市场采用和热情的社区。在这种情况发生的同时，平台工程师的角色的重要性将稳步提高，这也已经体现在薪资中。
希望平台工程将继续帮助组织降低开发人员的复杂性，同时兑现 DevOps 承诺：更快、更安全地提供更好的解决方案。
