运维管理平台化：运维体系为什么要基于平台化建设

本文来自腾讯蓝鲸智云社区用户：CanWay

摘要：笔者根据自身的技术和行业理解，解析运维平台化的内涵和实践。

涉及关键词：一体化运维、平台化运维、数智化运维、运维PaaS、运维架构治理、蓝鲸等。

本文作者：嘉为蓝鲸运维产品及解决方案负责人张敏

全文共计5500字，预计阅读时间12min。

运维平台的概念被泛化

近几年行业发展和客户实践，运维体系和运维架构得到蓬勃的发展，各种概念和实践层出不穷，而关于运维平台，主流声音和理解有几种：

平台工程

平台工程是Gartner发布2023年十大战略技术趋势，Gartner预测，到2026年，80%的软件工程组织将建立平台团队，其中75%将包含开发者自助服务门户，其核心强调的是基于云平台的技术和产品力，按照基础设施消费者的角度，把基础设施封装成平台服务，云工具链和服务打通、组成小规模平台化团队。国内的实践更多是在研发侧，业内也有各种声音，包括平台工程取代DevOps等，而较少考虑运维在平台工程的应用和服务化，架构理念较为一致，但是没有设计和定义运维组织如何实践平台工程。当然，这也是运维作为业务最后一环通常都会面临的情况。

运维架构治理

运维架构治理国内也有一些标准和组织做一些定义，因为的确是国内中大企业普遍都面临的情况，因而有拆到iPaaS、aPaaS等概念。但是怎么治理，往往是摸着石头过河，从流程、数据、场景等各个维度的都有，往往走的模式姑且定义为网状烟囱API打通，如：进行可观测性整合，需要打通CMDB完成对象定义，同时打通Trace、Log、Metric实现数据融合等操作。然而，这一过程中仍会面临诸多困境，一是缺乏从运维全局角度出发的视角，二是缺乏有效的治理方法和成功实践可供借鉴。最终可能陷入“工具丰富、建设迷茫”的状态。

SRE体系

SRE是一套旨在通过软件工程的方式提高应用可靠性的体系，用软件工程的管理和技术方法来解决运维问题的体系，其中特别强调主动管理和规避风险，包括如运维工作限制在50%以内、面向不确定性来设计、尽可能的自动化和简单化。为了更好地实践，国内通常会选择基于可支持运维开发的运维平台，以此来迅速构建运维系统的软件工程能力。虽然这与运维的平台化有所重合，但并未深入探讨SRE体系与平台之间的关联。

从个人视角来看，运维的平台化概念定义，要聚焦到事实的起点，就是到底解决什么问题：

企业建设了很多工具，但是包袱却越来越重，工具之间横向打通困难，纵向架构治理困难，如何破局？

业务和需求是变化的，如应用架构逐步从传统走向云原生，已有的运维系统架构能否支撑业务需求？原有的能力能否引用，需要怎样的新的能力和如何建设？

数据与AI、大语言模型、可观测等领域技术发展，运维平台的定义是否还存在？架构上如何支撑新的扩展场景？

……

因而我们把问题聚焦在对平台化的定义上：运维平台是对运维业务在软件架构层面的定义，可扩展、高内聚、低耦合是对运维平台的核心考验与验证。

接下来详细分享个人的看法与实践。

运维平台是整体架构抽象的实践

在拆解运维平台的架构抽象实践前，我们先定义运维管理与运维系统之间的关系：运维管理是基于管理需求来描述一个主题领域的运维业务，而业务的定义则是由角色、活动流程、工具系统、活动对象，以及和业务域关联集成设计组成，因而运维管理抽象成运维业务，是工具体系建设的起点，而工具体系是承接运维业务和运维管理落地的一种能力。

如下图运维业务与工具能力关系图所示。

图1 运维业务与工具能力关系

我们可以把任何一个运维系统的功能设计，都可以划分如下四层：

图2 单工具功能分层

这四层的理解为：

1、从对象层、接入层、逻辑层和界面层进行完整闭环；例如我们构建一个监控系统，无论自研、用开源软件还是商业软件，对象层通过Agent、探针、协议或Kafka等做指标接入；逻辑上最核心的过程就是数据采集、数据检测、告警、分析处置、视图。

2、接入层设计：是基于对象和逻辑上的综合考虑，例如要做主机监控，那接入层第一个考虑是能适配各类主机对象，以及最为关键的是获取指标数据；第二是基于逻辑层在数据检测上的考虑，来设计采集数据对象、采集频率、采集传输等。

3、逻辑层设计：是基于功能领域的模块闭环，如基于业务架构和分层模型设计监控和告警的对象模型，意味着需要在监控工具内有一个小型的CMDB，来维护监控对象以及指标类的数据挂载。

4、界面层设计：是工具使用角色，然后再匹配到企业的组织岗位角色。这也是单个工具的好与坏的地方，好的地方是自我闭环，坏的地方是难以满足运维管理组织岗位职责的角色视角。

如果只是单个工具，架构考虑的只是这个工具本身逻辑合理、边界清晰，但是放在整个运维架构的角度，就会有两个问题：

一是工具支持运维管理落地的运维活动是场景化的，往往需要多个工具联动才能闭环一个运维价值。例如，发布投产管理需要发布投产的逻辑设计，同时还需要CMDB、自动化作业、流程、监控告警的集成设计，难以单个工具实现一个相对大的场景闭环。

二是烟囱架构会带来重复建设和技术债务的问题。重复建设很好理解，例如每个工具都有跟目标设备交互的接入层设计，如果每个工具都做一套，那就意味着Agent或管道在IT对象上会越来越多。而技术债务则是发展性必然出现的问题。当做到第N 1个场景时，会发现原有的技术架构、功能和数据提供无法满足新的建设要求。这也是很多企业发现构建了监管控的基本运维系统体系，但实质的运维活动没有很好的改进和变化的原因。

那这里就有几个很核心的几个思考：

企业需要怎样全景的运维系统能力；
能力之间的关系如何定义；
能力如何组合满足扩展性场景；
如何分阶段分层次演进。例如：我们描述一个较为综合的运维业务场景：资源的生命周期管理，我们大致描述为如下业务逻辑：

图3 资源生命周期管理业务场景

从单场景层面来看这个运维系统如何设计，会发现极其复杂：

例如都共用到对象接入、CMDB、流程编排等模块，资源交付的CMDB需要纳管线上的资源，对象接入用来驱动做自动化交付，流程编排用来做工单审批和自动化交付的过程编排；那是不是意味着做一个资源交付，需要把CMDB、流程引擎、自动化交付等都做起来才能满足呢？

数据层面，都需要消费一些关键数据，如组织角色、配置数据、负载数据、成本数据、运行数据等。

那这里不得不去考虑业务域的高内聚、业务域之间的解耦，以及如果未来资源管理要升级到跨云调度，如何保障扩展性？

如下是一个概要的运维场景和工具设计蓝图示例：

图4 运维平台整体架构

这里有几个核心架构抽象和设计的思考：

1、梳理场景

可大致划分为日常维护、监控保障、变更发布、资源管理、运维流程、服务支持、应急保障、运营分析等运维场景，场景还不完全等于业务域，场景是运维组织视角的，例如我要做监控保障，其实要跨多个业务域的，包括监控管理、事件管理，可能还要关联到应急保障。

2、场景到业务域的拆解

这就需要引用包括ITIL、TOGAF等达成业界共识的概念了。例如容量管理，从容量管理业务角度，则有如下核心价值节点：规划性能容量、监控性能容量、分析评估性能容量、优化性能容量。

从功能层面则至少有：对象管理（资源和业务两个容量维度）、数据采集、数据聚合与计算、指标阈值设置及告警、性能容量报表视图、分析报告、优化建议、容量调度（需要关联自动化能力），然后需要集成CMDB、监控指标数据、自动化执行、运维数据处理等独立系统。

3、业务域需要共性能力

这个能力拆解成5个大的维度，这个点上业内有一定的共识：配置、观测、执行、流程、智能分析；这5个能力的组合，再加上一部分业务域自身逻辑，就可以快速构建业务场景的运维系统。例如做应急管理业务域，则需要CMDB（定义对象）、监控告警（应急触发）、流程（审批与协同）、自动化（预案执行）。所以这一层定义为核心业务能力，且这5个能力是横向需要打通的，如做事件管理，告警就是核心事件来源，流程则执行整个事件管理业务，而执行则自动化解决一些事件。

4、最后抽象技术能力

5个能力都需要一些公共的对象定义、数据与执行管道、底层引擎等，因而就有了统一Agent设计、统一对象模型设计、统一作业与数据管道设计等；这样就有了技术底座的设计。

所以这个时候我们再来看运维平台的定义：运维平台是对运维业务在软件架构层面的定义，可扩展、高内聚、低耦合是对运维平台的核心考验与验证。

可扩展

例如我们构建一个资源管理系统、应急灾备系统，是可以充分利用技术原子和业务原子的，而不是从零写起，如果还能支持运维开发，则平台的可扩展性就能在一个更高的维度上升。

高内聚

运维业务的核心逻辑从业务原子开始就是充分遵循领域边界的，例如配置中心，核心就是做好模型管理、实例管理、自动采集、报表、拓扑和对外消费，不在这个域里面去关联监控指标和告警。

低耦合

技术原子和业务原子均是低耦合可插拔的，可基于API Gateway、数据管道等方式与外部交互，且不限对方的技术架构，如要构建一个业务全景管理的应用，则模块化的去调用CMDB、关联指标和告警等即可，没有控制耦合和内容耦合。

如何设计可扩展的运维平台架构

按上述技术原子 5个核心业务能力 n个业务域场景 m个客户化界面场景的模式，就形成了真正的运维平台，但是这的确是一个复杂工程，需要持续往这个方向分阶段来建设。具体如何做呢，核心要做好这样几点：

第一步，共性模块能力化

共性模块抽象本质是一个积累的过程，遇到工具需求，拆解出接入层和逻辑层的共性能力，然后单独来设计，这样逐步积累、裁剪，就能设计出合理边界的能力项，然后注册到iPaaS（integration platform as a service）中，以组件的方式对工具提供模块和数据消费；以CMDB为例，CMDB有两个定义，一个是技术原子，作为所有运维系统的对象模型，一个是业务原子，满足企业的具体配置管理和消费场景。

第二步，能力消费自主化

根据不同规模的企业，要建设的运维系统从最小化“1个监控软件”，到最大化面向不同角色、场景提供不同的工具，工具领域建设非常重要的架构要求就是可自主和扩展，这也是平台架构抽象的第二个关键点。如果没有这一层的支撑，会使得平台化建设做的都是后台，而没有场景活动的功能支撑；这时候aPaaS（application platform as a service）就会显得非常关键，并且可以借助这个架构实现企业运维开发或自主可控转型。

第三步，活动场景方案构建

PaaS是以能力化的软件集成架构，来解决变化的需求的能力，因而我们如果从下往上看，iPaaS做了技术能力抽象，基于aPaaS做了单个工具领域集成和一体化，则再往上就是组合工具，而这里的整个能力、数据和服务集合，就支撑了运维活动的展开。

举个例子：为了有效地实现应急保障活动场景，我们需要有应急协同、预案管理、应急处置等组合工具，而这些工具的构建，都需要基于CMDB获取对象、基于可观测获取指标和运行状态、基于流程来做协同和工作推进等，所以这时候越面向一线用户的运维软件需求，越是可组装和轻逻辑的。

按这种架构设计模式，规划一体化、平台化的建设蓝图和阶段如下示例，包含了能力与场景层的解耦，工具之间有效联动，数据与智能的持续发展：

图5 运维建设蓝图及阶段示例

因而平台架构抽象要做好，要有一定的“克制”与“坚定”，克制在要充分尊重打基础的重要性，不能堆砌式陷入工具的浪潮；坚定是持续做架构治理，尤其是保障对象模型、流程贯穿和数据运营的统一。

这个时候我们再来看没有平台化之前的问题如何破局：

1、企业建设了很多工具，但是包袱却越来越重，工具之间横向打通困难，纵向架构治理困难，如何破局？

答：能力与场景解耦，能力分层，核心5个能力：配置、观测、执行、流程、智能分析打通，打通的逻辑来源于场景和业务设计，可以参考三条线来做打通：CMDB作为所有系统建设的对象模型，ITSM作为各个业务域落地的流程过程，以数据模型为中心构建运营体系。

例如：有一个较为高阶的场景，故障分析，要实现故障分析，需要前后连接观测、告警、事件、处置，那故障分析就需要以CMDB作为业务和资源的对象元数据，告警、处置以ITSM的核心事件流程打通，最后利用数据和AI融合Trace、Log、Metric、Alter、工单等，来做如故障影响面、告警快照、故障决策树、故障组件定位等场景，这是单用工具的API集成很难完成的。

2、业务和需求是变化的，如应用架构逐步从传统走向云原生，已有的运维系统架构能否支撑业务需求？原有的能力能否引用，需要怎样的新的能力和如何建设？

答：以云原生运维场景为例，已有的运维平台可以充分利用，然后做如下变化：接入层能适配容器、云原生组件、微服务对象；逻辑层做好云原生运维更为关键的可观测、应急管理、混沌工程、容量管理和智能化应用；渠道层则在原有的能力上追加多维度视图或强化移动端等即可。

3、数据与AI、大语言模型、可观测等领域技术发展，运维平台的定义是否还存在？架构上如何支撑新的扩展场景？

答：架构层面仍然是平台化架构，我们来看每个技术变化在架构层面的定位，数据与AI是一种能力，用来支撑场景，如做故障分析与定位，则调用数据分析和模型的能力；

大语言模型服务于界面层，解决人与系统之间更优的交互体验，如智能问答、交互式反馈运维数据和信息等；

可观测则是基于CMDB的对象统一、多维数据融合，来扩展更多的场景，如Trace与Log的关联、告警的多维信息平面、拓扑化的状态下钻等。

……