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

涉及关键词：一体化运维、平台化运维、数智化运维、运维PaaS、运维工具系统、蓝鲸等。

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

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

01

运维一体化的概念被泛化

运维一体化是近几年被广泛提起的概念，有各种解读和实践形态，在到具体的技术架构和管理实践前，我们还是要对一体化有几个基本定义，这样才能更为严肃地探讨运维一体化的本质。

1、什么是运维业务

我们采用TOGAF定义的业务架构来定义运维业务，运维业务是价值定位、管理、组织、关键业务流程的组合描述，抽象来讲要回答几个问题：干什么（业务能力）、谁来干（业务角色）、怎么干（业务流程）、所需应用（运维应用架构）、所需数据（运维数据架构）、所需技术（运维的技术变化与发展）；

例如这里就可以用一句很泛的话术来描述运维业务：基于业务安全稳定运行和IT服务满意（业务能力），组织职能线和专业线的IT运维角色（业务角色，如调度室是跨专业的职能线、DBA则是具体的专业线角色），基于服务管理、事件管理、变更管理等流程实践（业务流程，这里就需要拆解角色和岗位的映射），基于运维的监管控等工具（运维应用），管理log、metric、trace、event、工单、配置等数据（运维数据），基于分布式组件、容器化架构，实现运维业务支撑。

更细化一点，运维业务需要定义对应运维主题领域的四要素：角色、活动流程、工具系统、活动对象，来满足对应的运维业务能力。

以一般性IT服务管理主题为例：

图1:（一般性）IT服务管理业务架构

这里涉及多个关键角色：管理层、普通用户、一线坐席、二线专家、运维工程师、流程经理，还可能会包括三线开发专家或供应商角色等；

活动流程：这里可以按经典的服务设计与转换来定义，包括服务定义、服务发布、服务运营、持续改进等关键活动节点，同时还可以进一步把每个二级业务域进行拆解；

工具系统：具备自助服务、服务发布、服务目录管理、sla管理、服务与流程定义、请求管理、事件管理、问题管理、变更管理、发布管理等功能，并与ITOM通过关键业务关系链接，如发布投产调用发布自动化工具等；

活动对象：包括人员、业务、应用、资源和基础设施，均是上述活动和工具系统里关联的对象，这也是运维领域带来复杂度提升的一个重要点：技术对象的更新迭代，规模发展、横纵切面的复杂性。

而业务定义清楚，对应的管理规范就清晰了，再到应用设计，就清晰了技术规范，规范辅助业务的落地。

此处特别推荐工行侯总“一体化和自动化运维体系探索”文章以进一步加深理解（本文也多次借鉴其思想）。

2、业务单元与业务交互逻辑是什么

运维大的体系可被拆解到多个业务子域，ITIL实践帮我们已经做了一定的总结，不过技术性指导不够；一般来讲从业界通用的运维领域来看运维业务设计，我们可以定义运维业务设计大的主题分为两类：服务管理、技术管理。服务管理是数据中心为相关利益方提供真正体现数据中心价值的服务的管理过程；技术管理是从数据中心内部发展角度，为服务提升提供前瞻性、系统性的技术创新研究的管理活动。而展开就有了服务管理包含：配置管理、变更管理、事件管理、投产管理、问题管理、应急灾备管理、监控管理、操作管理等；技术管理则包含架构管理、运维开发管理、数据管理等。

而这些业务子域之间，则往往基于共同满足一个大的运维价值和活动场景，需要做业务域的关联设计，这种交互的逻辑一部分源于场景端到端的驱动，一部分源于技术复用和关联的驱动。例如：我们要做企业信息系统的灾备应急管理，首先要定义这个业务的四要素，角色（应急管理岗、应急实施岗、综合管理岗等），活动（组织管理、预案管理、演练管理、应急处置管理、资源管理），流程（事件应急流程、灾备应急流程），活动对象（资源、事件、预案、人员等）。而信息系统业务域与其他业务域的关联设计时，则例如业务活动里面的应急处置管理，来源是监控管理业务领域的生产事件，这属于场景端到端驱动，而资源基于CMDB构建，则是技术复用和关联。

业务域关联设计示例：灾备应急业务域在场景端到端驱动，尤其是故障生命周期视角，以及技术复用和关联驱动，尤其是统一对象模型和流程上，实现业务关联设计。

图2：灾备应急管理业务域与外部业务交互设计

3、实现业务的应用架构是否一体化

具体是指实现某个运维业务的闭环，最后落到工具系统时，工具系统本身没有好的内聚与耦合设计，没有实现与周边关联系统集成，最后并不能完成整个业务的闭环支撑；

例如：我们规划发布投产的业务，定义好业务要素后，进行应用架构设计，但是不可能把投产流程独立于ITSM之外再做一遍；且发布对象如果面临传统和容器化架构，对象是否能通过CMDB统一，包含了CMDB如何纳管容器化架构应用等；然后投产发布活动中有一个活动节点：投产实施，此时需要关联关闭告警，避免误报太多；这个时候就会发现，不是一个业务域一个工具，而是一个业务域是跨工具实现的场景，且多个业务域才能满足更高阶的闭环管理。例如业务连续性关联，关联的监控管理、灾备应急、运行操作管理等多个业务域，而到工具系统时，灾备应急则需要关联监控告警、CMDB等工具才能闭环。

所以从工具一体化视角来看，要定义核心所属业务域，以及外部调用与被调用的关系设计，以发布投产一体化工具为例，应用架构如下，除核心业务活动过程与功能外，外部与DevOps，以及与ITOM、ITSM的关联设计都需要考虑：

因而，运维一体化较为严肃的定义是：基于运维业务视角的角色、流程、活动（对象）、工具系统的整合，业务运转顺畅、流程运行高速、工具支撑高效是对运维一体化的核心验证。运维一体化不只是工具全和单一工具技术功能完整，而是要融入业务设计和整个体系中。

接下来管中窥豹探索一体化运维体系落地。

02

运维业务拆解模型

谈如何建设一体化，必须先对运维业务拆解，回归到对业务架构的定义，有如下三段的拆解模型，其中又有运维这个业务形态所面临的场景复杂和对象复杂的特殊要素。

1、业务架构定义

定义四要素：角色、活动流程、工具系统、活动对象；下面以大家熟知的配置管理业务主题为例，做拆解分析。

图3：配置管理业务设计

角色：配置经理进行配置规划和配置运营，制定配置管理体系和配置运营体系；配置管理员定义模型、权限和数据准入及审核；配置owner则映射各个专业管理员，管理本专业的对象数据实例、属性及关系；

活动流程：核心是5个活动流程，配置规划、模型与数据创建、配置维护、配置消费和持续运营，而活动则可以更细一步拆解的任务和步骤，如配置维护的任务包括：对象新增、对象查询、对象修改、对象删除，而对象修改任务则进一步拆解成步骤，如选择对象实例、修改关系、修改属性等；

工具系统：工具系统则承接活动、任务、步骤的信息化实现，基本都需要有模型管理、数据实例管理、配置审核、自动采集、配置拓扑、配置报表等功能；

活动对象：对于配置管理的对象，则主要是IT系统的实体及逻辑对象，可以大致划分为应用、资源、基础设施；这里关于逻辑对象特别强调下，例如微服务容器化架构，k8s是资源层的模型设计，业务则是一个逻辑概念，可以把多个k8s集群定义为一个业务，也可以把一个业务系统组合定义成一个业务，最后两个维度做逻辑关联。

2、功能架构设计

是对应用结构和交互的描述，这些应用是提供关键业务功能和管理数据资产的功能组，尤其是应用组件及其交互，与业务流程的关系。仍然以配置管理为例，为了支撑持续运营这个活动，功能上需要有报表、运营分析（如配置质量评分等）的功能，而这个要与配置数据实例管理关联；

继续以配置管理为主题拆解：

图4：配置管理应用架构设计

核心应用组件：一级功能需要包含能支撑主要业务活动的模型管理、数据实例管理、配置发现、配置报表及拓扑、数据运营，以及权限控制、日志等通用功能；

组件交互：这里就较为关键了，以配置发现为例，配置发现支撑了模型与数据创建这个关键业务活动，这个与模型关联的关系支撑了从模型到数据的活动过程，与数据实例管理的管理是支撑了数据实例自动采集的活动；

与周边系统集成：配置管理可以分为两类集成，均是支撑配置消费场景，一个是内部消费，包括台账、多维度报表、拓扑视图等，一个是外部消费，尤其是作为构建其他运维系统的元数据对象模型。

3、与其他业务域关联

业务域的关联设计是由各个业务主体的建设去设计，然后与其他业务域达成一致，原因就是一个业务域设计无法完全贯穿一个完整的运维场景，尤其是高阶的运维场景。类似这种场景就特别多了，例如我们要做监控管理，其中有一个关键业务活动节点是告警处置，就会根据告警级别关联不同的业务域，如事件管理、运行处置（故障自动解决）等。

而这种全量场景，可以基本划分为日常维护类、变更发布类、故障应急类、服务响应类、优化提升类等，每个企业不尽相同，且

转载请注明:http://www.aideyishus.com/lkgx/8548.html