01. 运维一体化的概念被泛化
运维一体化是近几年被广泛提起的概念，有各种解读和实践形态，在到具体的技术架构和管理实践前，我们还是要对一体化有几个基本定义，这样才能更为严肃地探讨运维一体化的本质。
1）什么是运维业务
我们采用TOGAF定义的业务架构来定义运维业务，运维业务是价值定位、管理、组织、关键业务流程的组合描述，抽象来讲要回答几个问题：干什么（业务能力）、谁来干（业务角色）、怎么干（业务流程）、所需应用（运维应用架构）、所需数据（运维数据架构）、所需技术（运维的技术变化与发展）；
例如这里就可以用一句很泛的话术来描述运维业务：基于业务安全稳定运行和IT服务满意（业务能力），组织职能线和专业线的IT运维角色（业务角色，如调度室是跨专业的职能线、DBA则是具体的专业线角色），基于服务管理、事件管理、变更管理等流程实践（业务流程，这里就需要拆解角色和岗位的映射），基于运维的监管控等工具（运维应用），管理log、metric、trace、event、工单、配置等数据（运维数据），基于分布式组件、容器化架构，实现运维业务支撑。
更细化一点，运维业务需要定义对应运维主题领域的四要素：角色、活动流程、工具系统、活动对象，来满足对应的运维业务能力。
以一般性IT服务管理主题为例：
- 这里涉及多个关键角色：管理层、普通用户、一线坐席、二线专家、运维工程师、流程经理，还可能会包括三线开发专家或供应商角色等；
- 活动流程：这里可以按经典的服务设计与转换来定义，包括服务定义、服务发布、服务运营、持续改进等关键活动节点，同时还可以进一步把每个二级业务域进行拆解；
- 工具系统：具备自助服务、服务发布、服务目录管理、sla管理、服务与流程定义、请求管理、事件管理、问题管理、变更管理、发布管理等功能，并与ITOM通过关键业务关系链接，如发布投产调用发布自动化工具等；
- 活动对象：包括人员、业务、应用、资源和基础设施，均是上述活动和工具系统里关联的对象，这也是运维领域带来复杂度提升的一个重要点：技术对象的更新迭代，规模发展、横纵切面的复杂性。
而业务定义清楚，对应的管理规范就清晰了，再到应用设计，就清晰了技术规范，规范辅助业务的落地。
2）业务单元与业务交互逻辑是什么
运维大的体系可被拆解到多个业务子域，ITIL实践帮我们已经做了一定的总结，不过技术性指导不够；一般来讲从业界通用的运维领域来看运维业务设计，我们可以定义运维业务设计大的主题分为两类：服务管理、技术管理；服务管理是数据中心为相关利益方提供真正体现数据中心价值的服务的管理过程；技术管理是从数据中心内部发展角度，为服务提升提供前瞻性、系统性的技术创新研究的管理活动；而展开就有了服务管理包含：配置管理、变更管理、事件管理、投产管理、问题管理、应急灾备管理、监控管理、操作管理等；技术管理则包含架构管理、运维开发管理、数据管理等；
而这些业务子域之间，则往往基于共同满足一个大的运维价值和活动场景，需要做业务域的关联设计，这种交互的逻辑一部分源于场景端到端的驱动，一部分源于技术复用和关联的驱动。例如：我们要做企业信息系统的灾备应急管理，首先要定义这个业务的四要素，角色（应急管理岗、应急实施岗、综合管理岗等），活动（组织管理、预案管理、演练管理、应急处置管理、资源管理），流程（事件应急流程、灾备应急流程），活动对象（资源、事件、预案、人员等）。而信息系统业务域与其他业务域的关联设计时，则例如业务活动里面的应急处置管理，来源是监控管理业务领域的生产事件，这属于场景端到端驱动，而资源基于CMDB构建，则是技术复用和关联。
业务域关联设计示例：灾备应急业务域在场景端到端驱动，尤其是故障生命周期视角，以及技术复用和关联驱动，尤其是统一对象模型和流程上，实现业务关联设计。
3）实现业务的应用架构是否一体化
具体是指实现某个运维业务的闭环，最后落到工具系统时，工具系统本身没有好的内聚与耦合设计，没有实现与周边关联系统集成，最后并不能完成整个业务的闭环支撑；
例如：我们规划发布投产的业务，定义好业务要素后，进行应用架构设计，但是不可能把投产流程独立于ITSM之外再做一遍；且发布对象如果面临传统和容器化架构，对象是否能通过CMDB统一，包含了CMDB如何纳管容器化架构应用等；然后投产发布活动中有一个活动节点：投产实施，此时需要关联关闭告警，避免误报太多；这个时候就会发现，不是一个业务域一个工具，而是一个业务域是跨工具实现的场景，且多个业务域才能满足更高阶的闭环管理。例如业务连续性关联，关联的监控管理、灾备应急、运行操作管理等多个业务域，而到工具系统时，灾备应急则需要关联监控告警、CMDB等工具才能闭环。
所以从工具一体化视角来看，要定义核心所属业务域，以及外部调用与被调用的关系设计，以发布投产一体化工具为例，应用架构如下，除核心业务活动过程与功能外，外部与DevOps，以及与ITOM、ITSM的关联设计都需要考虑：
因而，运维一体化较为严肃的定义是：基于运维业务视角的角色、流程、活动（对象）、工具系统的整合，业务运转顺畅、流程运行高速、工具支撑高效是对运维一体化的核心验证。运维一体化不只是工具全和单一工具技术功能完整，而是要融入业务设计和整个体系中。
接下来管中窥豹探索一体化运维体系落地。
02. 运维业务拆解模型
谈如何建设一体化，必须先对运维业务拆解，回归到对业务架构的定义，有如下三段的拆解模型，其中又有运维这个业务形态所面临的场景复杂和对象复杂的特殊要素。
1）业务架构定义
定义四要素：角色、活动流程、工具系统、活动对象；下面以大家熟知的配置管理业务主题为例，做拆解分析。
角色：配置经理进行配置规划和配置运营，制定配置管理体系和配置运营体系；配置管理员定义模型、权限和数据准入及审核；配置owner则映射各个专业管理员，管理本专业的对象数据实例、属性及关系；
活动流程：核心是5个活动流程，配置规划、模型与数据创建、配置维护、配置消费和持续运营，而活动则可以更细一步拆解的任务和步骤，如配置维护的任务包括：对象新增、对象查询、对象修改、对象删除，而对象修改任务则进一步拆解成步骤，如选择对象实例、修改关系、修改属性等；
工具系统：工具系统则承接活动、任务、步骤的信息化实现，基本都需要有模型管理、数据实例管理、配置审核、自动采集、配置拓扑、配置报表等功能；
活动对象：对于配置管理的对象，则主要是IT系统的实体及逻辑对象，可以大致划分为应用、资源、基础设施；这里关于逻辑对象特别强调下，例如微服务容器化架构，k8s是资源层的模型设计，业务则是一个逻辑概念，可以把多个k8s集群定义为一个业务，也可以把一个业务系统组合定义成一个业务，最后两个维度做逻辑关联。
2）功能架构设计
是对应用结构和交互的描述，这些应用是提供关键业务功能和管理数据资产的功能组，尤其是应用组件及其交互，与业务流程的关系。仍然以配置管理为例，为了支撑持续运营这个活动，功能上需要有报表、运营分析（如配置质量评分等）的功能，而这个要与配置数据实例管理关联；
继续以配置管理为主题拆解：
核心应用组件：一级功能需要包含能支撑主要业务活动的模型管理、数据实例管理、配置发现、配置报表及拓扑、数据运营，以及权限控制、日志等通用功能；
组件交互：这里就较为关键了，以配置发现为例，配置发现支撑了模型与数据创建这个关键业务活动，这个与模型关联的关系支撑了从模型到数据的活动过程，与数据实例管理的管理是支撑了数据实例自动采集的活动；
与周边系统集成：配置管理可以分为两类集成，均是支撑配置消费场景，一个是内部消费，包括台账、多维度报表、拓扑视图等，一个是外部消费，尤其是作为构建其他运维系统的元数据对象模型。
3）与其他业务域关联
业务域的关联设计是由各个业务主体的建设去设计，然后与其他业务域达成一致，原因就是一个业务域设计无法完全贯穿一个完整的运维场景，尤其是高阶的运维场景。类似这种场景就特别多了，例如我们要做监控管理，其中有一个关键业务活动节点是告警处置，就会根据告警级别关联不同的业务域，如事件管理、运行处置（故障自动解决）等。
而这种全量场景，可以基本划分为日常维护类、变更发布类、故障应急类、服务响应类、优化提升类等，每个企业不尽相同，且关注重点不一，可以基于岗位、技术对象、活动来梳理，进而由场景做业务域的关系设计，当然，运维的业务域，在业界还是有一定共识的，一般可以先从请求管理、配置管理、变更管理、事件管理、发布投产管理、问题管理、应急灾备管理、监控管理、操作管理、资源管理这几个着手，后续进而考虑高阶和扩展的业务域。
总结下，运维业务拆解模型利于我们定义几个东西：
① 确定业务领域边界
运维体系最容易出现的情况是建设混乱，工具繁多但是一体化的价值并没有达到，例如：之前遇到一个需求，基于应用和资源拓扑视角的监控与处置一体化，这个需求归属到配置管理，还是监控管理、运行处置，就有很大的争议，从技术视角来看，应用和资源拓扑是CMDB管理维护的，对象监控是监控告警工具提供的，处置则是自动化提供的，较为容易出现建设混乱，但是从业务视角来看，应该归属于监控管理领域的“全景视图”，然后与自动化处置做业务域打通，属于监控管理领域的故障视图活动节点；
② 确定业务域打通的逻辑
业务域打通的逻辑是源自业务之间的关系设计，例如做好事件管理，需要考虑监控告警域、运行处置域、变更管理域、配置管理域等几个域的关系设计，事件来源有巡检、告警等，事件可能需要上升到变更管理才能解决，事件的技术手段解决则需要关联到运行处置域，打通方式则有包括流程的API对接、数据消息传递等；
③ 功能是为业务服务的
没有对业务架构的定义，尤其是业务架构的关键角色、活动节点、活动对象、流程的定义，就无法细化到角色与岗位之间的映射，且无法转换成支撑岗位活动的功能设计，进而变成了人要习惯工具，而不是人与工具遵循规范化活动运转。
03. 业务、应用、数据、技术多维建设来推进一体化
当定义清晰了众多业务域后，建设一体化运维，则可以从如下视角展开：
1）业务层面基于流程端到端的贯穿
核心是运行、管理、处置一体化，有如下展开场景：
① 运行管理一体化
生产运行基于监控管理和监控运行完成，包括关键的数据采集、数据检测、数据告警、数据分析、数据视图等关键活动，运行与处置的一体是指在数据告警活动节点，数据告警根据业务级别、应用、影响面、故障类别、故障信息构成，由此生成事件在事件管理业务域去跟踪管理，如果由事件上升到应急，则调用应急处置预案去完成。
较为典型的就是告警转事件的联动场景：
② 运行处置一体化
运行处置一体是指数据告警、数据分析的活动节点，对于标准化告警，直接调用运行操作完成基于规则的标准化自愈；对于上升到事件应急的，则调用运行操作的应急预案自动化，完成生产回复；同时对于数据分析场景，则基于运行操作进行故障决策树分析、告警快照、多维信息视图获取等操作，来进行故障辅助分析，当然，也有基于AI的故障初因定位、根因定位，从业务活动来讲业务是没变的，实现业务的技术手段在不断蓬勃发展；
③ 管理处置一体化
管理与处置的一体是当前IT服务发展的一个关键趋势和特性：敏捷；应用在如服务自助自动化、标准变更自动化、配置管理自动化、工单自动处理等场景，较为典型的如发布投产管理，基于发布投产的管理活动，执行时输入标准化的技术参数：程序包、sql、脚本、配置文件、对象参数等，再调用发布自动化工具，完成管理流与执行流的编排与一体化，管理流程编排中可嵌入技术编排，从而实现这个打通：
2）应用架构基于统一对象模型
众多业务域构建应用架构时，都需要考虑运维的一个核心定义：对象；如做可观测，我们所有观测的对象都需要有对象元数据的定义，包括了实体对象和逻辑对象；如做发布，发布策略编排则是基于对象在应用架构中的关系来设计的，也需要一个对象元数据。而这里就有一个首要的一体化：统一配置管理体系建设；除了满足配置管理的内部管理功能外，非常核心的一点是能支撑一体化运维的应用系统的对象模型统一设计。
以可观测建设为例，统一的对象模型是起点，没有统一对象模型的定义，无法去构建指标体系、数据关联及融合场景。以可观测的指标体系为例，基于统一对象模型的设计如下，核心是进行对象和数据实例在外部系统与CMDB之间的映射：
3）数据层面则基于数据治理框架支撑场景
运维数据可以划分成5个域：
配置域：IT资产管理系统、配置管理中各类电子信息设备的基本信息、技术参数及关联关系等信息，包括PC机、服务器、存储设备、网络设备、安全设备、辅助设备、机房环境设备、套装软件及应用系统软件等；
状态域：IT监控、自动化运维、安全监测等采集的设备软硬件性能、状态、事件、日志、告警及实用化数据等；
流程域：运维流程管理中执行一个业务流程所产生的相关记录数据；
作业域：自动化作业、故障自愈、编排处置步骤等作业执行流程数据和操作审计数据；
知识域：故障事件处理经验，其他相关知识库，以知识主题、关键字索引、内容等形式存在。
数据治理框架核心要定义几个问题：
- 运维数据之间的逻辑和关联设计如何做？
- 运维大数据平台的定位？
- 数据消费场景如何持续建设？
- 数据与AI如何统一建设？
关键逻辑为：
这里面有几个实践建议：
① 消费场景聚焦在提升性能容量、观测整合、运营分析的高阶运维能力；尤其是在观测整合上，当前可观测主要围绕故障分析和定位展开，基于数据管理框架，则可以完成数据标签统一、数据聚合计算、数据关联信息平面、AI模型应用等，例如其中一个观测场景可以基于告警视角，展开trace、log、metric、场景视图、知识库关联、变更事件关联分析等，来形成初步的观测整合分析场景：
② 技术价值上主要体现在复杂和大规模的数据清洗、开发和存储需求；跨数据源的数据关联计算；联动MLOps实现数据样本和数据源的关联，实现AIOps模型开发和应用；
③ 数据管理采用专业分散，消费驱动的模式管理，专业分散是指如CMDB、metric、trace、log等都在专业管理工具里，消费驱动则是基于场景调用时，再去做数据接入、标签、关联计算等，支撑数据之上的场景应用；
4）技术架构基于统一管控管道和平台架构
统一管控管道指的是适配各类运维应用的运维对象管道，核心包括三个设计：
- 可扩展，可支持监控、配置、自动化等上层应用场景对agent的任务调度，且可支持agent扩展采集插件和适配不同的技术对象，以及适配复杂网络的架构；
- 稳定性，这是最为关键的部分，海量分布式管控的稳定性对于运维系统至关重要，稳定性需要大规模环境的实践，且包含多种如进程守护、安全机制、性能控制等设计；
- 性能，包括如十万级实时并发任务、毫秒级任务日志反馈等，可保障采集任务和执行任务的并发执行。
平台架构核心是做能力和场景的解耦，保持持续的扩展性能力。（下一期将对平台化进行详细介绍，敬请期待~）
04. 一体化运维在投产发布下的设计示例
最后更具象化一点设计一体化运维在具体业务域的设计示例：
1）设定情景
业务系统100+，主机节点5W+，K8S集群主机节点5000+，实现高质量、高安全、高效率的统一发布；
2）业务设计
组织角色：以应用为维度，负责部门为应用运维管理员，协同研发、基础设施维护人员；发布经理负责发布的统筹、组织和方案把控，发布工程师负责发布的任务编排、发布执行、验证、回滚；发布领导负责外部沟通、业务影响评估和风险回退控制；技术专家包括研发对包的质量管理、基础架构专家负责准备对应的资源及环境；
工作流程：通过投产计划、程序验证、投产评审、投产执行、应用验证这几个核心流程组成，每个流程可以进一步展开到里面具体的角色活动；
关键活动：
- 发布管理员配置发布模板，模板包括了对传统及容器化架构环境的三类操作：文件分发或镜像发布、脚本执行、基于接口的容器化调度编排；
- 应用运维人员基于发布方案输入参数，参数包括：发布对象、对象编排、介质（含二进制包或镜像、配置文件、脚本、SQL等）、时间窗口等；
- 领导主管监视发布大屏以及获取运营分析数据……
规范指引：《生产发布运行管理办法》：应用架构与运行环境、发布过程、常规故障处置、紧急回滚；
3）工具设计
接入层：与不同环境及不同资源对象进行对接，主要是主机和容器化环境；
逻辑层：最核心是任务编排、制品管理、应用管理；从而满足一站式发布，支持灰度、蓝绿建设；
界面层：面向不同角色的生命周期活动阶段，如发布经理最为关注影响分析、发布编排、发布验证、发布回滚；管理层最为关注发布计划、影响分析、回退机制及运营数据；
外部集成：与DevOps联动、触发告警时间屏蔽、与ITSM变更流程联动；
落地设计示例：
工具产品界面：
所以至此，简单总结下几个结论：
- 基于运维业务视角的角色、流程、活动（对象）、工具系统的整合，业务运转顺畅、流程运行高速、工具支撑高效是对运维一体化的核心验证；
- 运维业务需要经过业务架构、应用架构、业务关联设计这三个步骤展开，进行企业实例化设计，起步可以先从请求管理、配置管理、变更管理、事件管理、发布投产管理、问题管理、应急灾备管理、监控管理、操作管理、资源管理这几个维度根据紧迫程度着手；
- 一体化的推进要从业务、应用、数据、技术这几个维度的视角来做规划和设计，其中最为关键的是业务场景的一体化，如何把运行、管理、处置联动起来；应用架构的一体化，如何基于统一对象模型构建；数据管理的一体化，核心是专业分散，消费驱动的模式管理，切忌做成数据开发的模式；技术架构的一体化，核心是抓准统一管控和平台架构这两个关键点。
嘉为蓝鲸作为业内领先的平台化、一体化、数智化运维解决方案提供商，我们坚定地致力于把成熟的业务实践、领先的技术架构，赋能给我们的客户。
最后，欢迎随时与嘉为蓝鲸共同探讨！
总结：以上为笔者对一体化运维的剖析，欢迎探讨交流，谢谢！
