利用统一的数据平面来阻止运维蔓延

本文转载自 The New Stack。

图片来源：由 Lightspring 在 Shutterstock 上发布。

如果由于 NetOps、SecOps、PlatformOps 和 FinOps 之间的协调问题，应用团队更新某个关键基础设施元件需要耗费数周的时间，那您就遇到了运维蔓延问题。

最早出现的是技术运维团队，后来又出现了网络运维和安全运维团队。此后，由于站点可靠性工程 (SRE) 实践的兴起，以及为了将更多运维决策放到开发环境中，DevOps 应运而生。再后来，这被侧重于安全防护的 DevSecOps 所取代。随着云原生的到来，PlatformOps 开始管理和部署工具链，为的是实现适当的安全防护左移。

现在，又有一种实践将 PlatformOps 与财务运维结合起来，被称为 FinOps，旨在理清混乱的云计算成本。最终，这种无序的运维扩张定然会导致“运维蔓延”，即所有团队各自为营，守着自己的仪表盘和各自领域的知识，给企业运营造出一个又一个瓶颈。

数据平面可帮助解决运维蔓延问题

数据平面就像一条线一样将这一切联系在一起。在四层和七层，数据平面身兼数职。它不仅接收控制平面的指令并移动数据，而且还转发数据包、实施安全规则并执行负载均衡等任务。从生物学上说，数据平面是现代应用和网络的血液和肌肉，控制平面则是神经系统。就像人类大脑一样，控制平面拥有多个模块，各自可执行特定功能。

确保所有运维职能在数据平面上都是“一等公民”，这是打破运维团队之间的孤岛和减轻运维蔓延的危害的关键所在。有何挑战呢？大多数企业尚未部署统一数据平面，对该概念仍一无所知。鉴于大多数应用都由 API 组成，即使是单体应用也需要能够与其他系统进行通信，因此统一数据平面的概念变得日益重要。

数据平面最初源于网络结构，萌生于“关注点分离”理论。这一基本设计原则是将复杂的系统分解成不同的较小部分，每个部分都侧重于程序功能的一个特定方面或“关注点”。在网络方面，运营商希望将功能分成数据平面和“控制平面”，前者负责传递数据并实施数据迁移规则，后者负责管理数据平面及相关策略。

后来，这一理论通过“模型-视图-控制器”等模式应用到软件中。在网络领域，关注点分离原则得到了全面实施，包括大型核心路由器和回程系统以及应用交付控制器和反向代理等小型系统。尽管技术栈中越来越多的元素遵循这一惯例，但不同的职能部门仍倾向于让其数据平面孤立运行，要么是物理分离，要么是使用不兼容或不相关的工具。下面再来谈谈 Kubernetes。

从 Kubernetes Gateway API 中汲取的经验

Kubernetes 采用 API 优先和松散耦合设计，是真正的云原生架构。最近，Kubernetes Gateway API 更彻底地将数据平面和控制平面分离开来。这样一来，不同的团队分工明确（或处理基本基础设施，或管理集群，或开发应用），有助于您更详细地定义网络设置，并轻松添加新功能。

这意味着不同团队能够更好地协同工作，便于您更有效地控制网络流量，同时化繁为简，可更轻松地按需插入专门的网络工具。事实上，全新 Gateway API 可能会成为所有运维团队的数据平面和关键互联结构，不仅可以提升安全防护和可扩展性，而且还能加快部署速度、简化平台迭代并加强成本控制。

利用统一数据平面减轻运维蔓延的五项原则

并非每家企业都会整体转向 Kubernetes，也不该如此，但我们可以借鉴 Gateway API 的架构原则来制定计划，让所有运维团队都在同一数据平面上协同工作，从而消除运维蔓延难题。

原则 1：通过 API 实现标准化

Gateway API 重点关注标准化对象定义，为无缝集成奠定了基础。统一数据平面应采用类似标准，支持不同的工具彼此通信，并最终减少对定制解决方案的依赖，因为这种解决方案会加剧孤岛问题。API 至少应能够进行通信。理想情况下，应设计和部署统一 API 结构来管理运维数据。

原则 2：可视化是统一因素

集中式数据平面必须实现网络流量、应用性能和延迟、资源和容器类型使用情况以及安全防护指标的可视化。要真正解决运维无序蔓延的问题，（基础设施和带宽）成本也应该实现可视化，以帮助团队了解其设计选择的影响。得益于对系统健康状况的实时共享可视性，各个运维团队能够消除部落知识鸿沟，促进积极主动地解决问题。

原则 3：通过抽象赋能

数据平面应为每个运维角色提供适当级别的抽象。网络工程师需要对四层进行细粒度控制，并对七层有所了解，以实现应用交付和安全防护目的。FinOps 团队需要了解每个云提供商的支出情况和预计支出。设计上既要支持所有人按需展开，也要保持合理的抽象。

原则 4：策略驱动型配置

构建统一的数据平面可帮助消除手动和易错配置。企业应采用一种适用于 NetOps、SecOps、PlatformOps、FinOps 及其他团队的基于策略的声明式方法，从而确保一致性并简化变更管理，同时实现例外管理，避免重复管理。

原则 5：可观测性是基础

真正的洞察不仅仅来自于可视化。在设计统一数据平面时，应充分考虑到全面的可观测性 —— 涉及所有运维职能的结构化日志、指标和链路追踪。有了这项功能，运维团队就能迅速查明问题、找出瓶颈并优化整体性能。

运维蔓延会对企业的创新和效率造成负面影响。借鉴 Kubernetes Gateway API 的架构原则而构建的统一数据平面可帮助打破孤岛，促进运维团队无缝协作，最终加快交付速度并改善企业运维状况。