如今，“平台运营（Platform Ops）”的势头似乎越来越盛。你可能会问，“我们已经有了 DevOps、NetOps、SecOps、DevSecOps，甚至是 FinOps！何苦再要一种‘Ops’？”实际上，与其他“运营”不同的是，平台运营更多地是充当粘合剂的角色，将所有不同的部门和用例整合在一起，以满足科技企业构建现代分布式和云原生应用的需求。换句话说，我们认为平台运营相当重要。

什么是平台运营？

所谓“平台”是指不同的工程团队使用的一套技术，他们用这个平台来实现各种依赖于算力的功能。Web 应用团队依赖 Web 服务器、中间件（如 Node.js®）、前端和负载均衡器。营销技术团队依赖 Adobe Creative Cloud 和 Salesforce 等 SaaS 产品。网络运营团队则依赖 Kubernetes、应用交付控制器和虚拟网络解决方案（Kubernetes 也提供了许多此类功能）。在云计算和云原生应用的时代，所有团队都依赖某个既能提供核心计算、存储和网络功能，又能提供应用构建和交付工具的平台。

平台运营团队的职责是打造、维护、连接和保护为 DevOps 团队提供完成工作所需一切的平台。随着越来越多的科技公司迁移到云端，平台运营也与核心功能的实施（例如全公司的网络和安全性）关联日益紧密。

为什么需要平台运营？

在过去的十年里，应用环境发生了翻天覆地的变化。单体应用经过一系列重构，演变成由 API 连接的多个服务。分布式应用可能不仅包括多个服务，而且还横跨在多个云环境中。开发人员把控着技术堆栈，可以自由选择他们认为合适的工具。一些企业的 IT 首席技术官和副总裁发现，他们的数十个 DevOps 团队使用成百上千种不同的工具和解决方案来处理计算、数据、消息队列、可观测性、安全性和网络。这一现象在应用层（第 7 层）表现尤为突出。例如，一家大型移动应用公司曾表示，由于应用团队使用了多种互不兼容或者无法统一到单一平台的不同工具和解决方案，他们需要运行多个 Kubernetes 集群和不同类型的服务网格。

过多选择的副作用

面对让企业不堪重负的技术工具激增问题，平台运营解决方案无疑带来了希望。平台运营团队需要企业内所有 IT 和应用用户的配合，从而了解他们的期望和需求，并将他们的请求缩减到少数几个选择。平台运营的核心是在选择和混乱之间取得平衡，让企业在保持强大的安全性、治理和可靠性的同时“向左迁移”。

可以肯定的是，一些公司仍然允许应用或 DevOps 团队自主选择工具，这些工具不一定必须在平台运营团队的支持范围内。Netflix 以“自选、自管”的模式而闻名，除了内部打造的技术工具外，团队还可以选择其他解决方案。但前提是这些团队要自己负责自己的工具，而不能寄望于平台运营、IT 或其他 DevOps 团队的帮助。

需要注意的是，平台运营与 IT 整合不同。IT 整合往往是自上而下的，很多工作都集中在上层机构，平台运营则是自下而上的，更多的是以咨询性质为主。平台运营团队必须成为选定平台的布道者和老师，确保使用该平台的所有用户都了解为什么要做出这样的选择，以及如何最大程度地从平台中获益。

平台运营团队成员通常来自应用开发和 DevOps，因此他们比任何人都更了解这些团队的需求和期望。此外，无论是为了内部工具的开发还是为了进行配置和管理，平台运营团队通常还是会写代码，最终他们使用的平台就是他们构建的平台。这与 IT 团队的情况大不相同——他们只负责确定要使用的解决方案，但不在自己的工作过程中自用。

对于那些努力想要适应令人迷茫的新型云环境、云原生应用、分布式基础架构和“左移”的应用开发和安全性的公司来说，平台运营团队提供了一个信息和评估的重要来源。它可以帮助首席技术官乃至首席财务官、采购和审计团队了解需求和成本。从这个角度来说，平台运营就像是一个中立的经纪人，为信息共享和系统化知识的获取提供了重要渠道。

结论：平台运营对IT 战略成败的影响越来越大

事实上，选择和控制之间的关系一直很紧张。但今天，企业必须要为开发人员创造发挥才能的沃土。过度的限制会让开发人员产生挫败感，迫使他们另谋高就；而过多的选择会造成“各自为政”的分布式技术环境，一堆工具互不兼容、配置和结构混杂无序。久而久之，这种环境将变得既难以管理、又缺乏安全。平台运营团队对这些问题的权衡决定了企业能否成功驾驭数字化转型、为以云原生和广泛分布式为特点的未来做好准备，并在“左移”和传统之间取得完美平衡。