Home

/

运维体系为什么要基于平台化建设?

Post date:2024-01-12 15:53:48

分享到

01. 运维平台的概念被泛化

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

1)平台工程

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

2)运维架构治理

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

3)SRE体系

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

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

  • 企业建设了很多工具,但是包袱却越来越重,工具之间横向打通困难,纵向架构治理困难,如何破局?
  • 业务和需求是变化的,如应用架构逐步从传统走向云原生,已有的运维系统架构能否支撑业务需求?原有的能力能否引用,需要怎样的新的能力和如何建设?
  • 数据与AI、大语言模型、可观测等领域技术发展,运维平台的定义是否还存在?架构上如何支撑新的扩展场景?
  • 因而我们把问题聚焦在对平台化的定义上:运维平台是对运维业务在软件架构层面的定义,可扩展、高内聚、低耦合是对运维平台的核心考验与验证。

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

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

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

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

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

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

图2 单工具功能分层

这四层的理解为:

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

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

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

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

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

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

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

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

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

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

  1. 例如都共用到对象接入、CMDB、流程编排等模块,资源交付的CMDB需要纳管线上的资源,对象接入用来驱动做自动化交付,流程编排用来做工单审批和自动化交付的过程编排;那是不是意味着做一个资源交付,需要把CMDB、流程引擎、自动化交付等都做起来才能满足呢?
  2. 数据层面,都需要消费一些关键数据,如组织角色、配置数据、负载数据、成本数据、运行数据等。
  3. 那这里不得不去考虑业务域的高内聚、业务域之间的解耦,以及如果未来资源管理要升级到跨云调度,如何保障扩展性?

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

图4 运维平台整体架构


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

1)梳理场景

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

2)场景到业务域的拆解

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

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

3)业务域需要共性能力

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

4)最后抽象技术能力

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

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

① 可扩展

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

② 高内聚

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

③ 低耦合

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


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

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

1)第一步,共性模块能力化

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

2)第二步,能力消费自主化

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

3)第三步,活动场景方案构建

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

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

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

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

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

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

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

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

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


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

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


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

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

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

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


04. 运维平台的变与不变

运维平台在架构层面的定义,短期并不会有太大的变化,包括技术、业务、场景各层的定义,仍然是一体化运维最好的承载和落地架构;但是从内容上,则会如下变化与发展:

  1. 对象层会不断扩展:尤其是在容器、分布式组件、跨云、信创等对象上持续演进。
  2. 能力层会随着技术发展补充新的能力:尤其是数据与AI的能力,使得基于数据融合的运维场景更为丰富,可观测的核心也在统一模型对象和多维数据融合上才有更好的发展。
  3. 场景会跟随业务架构变化而扩展和深化:数据化运营、智能监控模型、分布式云原生应用的运维场景、算力调度等会持续深化,且仍然是基于能力的增强。
  4. 渠道层则会呈现多样和灵活化:大语言模型、消费化体验则会强化与用户的渠道和界面连接。
  5. 架构会随着能力与场景的演进持续治理:架构层面则包括运维平台自身的云原生化、能力解耦的深化等进一步发展。
  6. 嘉为蓝鲸作为业内领先的平台化、一体化、数智化运维解决方案提供商,我们坚定地致力于把成熟的业务实践、领先的技术架构,赋能给我们的客户。

本文谈了“平台化”方向,“一体化”相关内容请点击下方“系列推荐”,下期我们一起来聊聊“数智化”相关内容,敬请期待~

最后,欢迎随时与嘉为蓝鲸共同探讨!

总结:以上为笔者对运维平台的剖析,欢迎探讨交流,谢谢!

免费申请演示

联系我们

服务热线:

020-38847288

QQ咨询:

3593213400

在线沟通:

立即咨询
查看更多联系方式

申请演示

请登录后在查看!