3.2 工具体系的平台化架构

在建设运维工具体系时，必然要面临一个问题：运维工具体系的架构是怎样的？如何从整体架构上支撑运维场景？如何把运维活动和操作转化为工具建设支撑？此外，工具体系建设在架构上还面临着一个很大的挑战：复用性和扩展性。复用性是指如何保护已有投资和避免重复浪费，扩展性是指随着管理诉求和管理对象的变化，能扩展场景来快速满足业务需要。

3.2.1 单工具领域

按业内通用的单工具领域来分，大致划分如图3-3所示。

❑安装部署：解决IT资源和应用的上线和初始化的问题，包括资源交付、发布投产等。

❑运行监控：解决IT运行过程中的监控、分析、定位的问题，包括资源监控、应用监控、业务监控、日志管理、告警事件、故障分析、故障定位等。

❑运行操作：解决IT运行过程中的各类操作处置的问题，包括灾备演练、应急管理、日常作业等。

❑分析评估：解决面向不同对象的分析类场景，包括资源管理、容量管理、健康画像、体验分析、运营展示等。

❑流程协同：针对尤其是与人协同的管理流程的问题，包括服务请求、事件流程、变更流程、问题流程、知识库等。

按单工具的技术架构来设计，运维工具大体可分为4层，如图3-4所示。

单工具领域建设的特点如下：

1）完整闭环。在单工具建设中，需要考虑对象层、接入层、逻辑层和界面层的完整闭环。以监控系统为例，无论是自研还是使用开源软件或商业软件，都需通过Agent、探针等协议对对象层的指标进行监控。逻辑层是数据采集、检测、分析、告警处理和视图展示等核心过程的组装。界面层用于监控数据的展示、用户监控配置行为的操作等。

2）接入层设计。接入层设计需基于接入对象和接入逻辑两方面综合考虑。例如主机监控，那么接入层的第一个考虑是能适配各类主机对象，并获取主机监控的指标数据，第二个考虑是逻辑层在数据检测上的设计，如采集数据对象、采集协议、采集频率、采集传输等。

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

4）界面层设计。本质是服务渠道，面向不同角色的功能台。其中的角色是工具使用角色，而不是企业的组织管理角色。

总体而言，根据运维活动的设计定义，单工具领域的设计具有边界清晰、逻辑合理等优点。然而，存在两个关键问题：第一，工具支撑运维管理落地需要场景化的运维活动闭环，通常需要多个工具的协同配合。例如，投产发布管理涉及投产发布逻辑、CMDB、自动化作业、流程、监控告警的集成设计，单一工具难以完整覆盖一个复杂场景的闭环。第二，单工具模式下容易产生重复建设和技术债的问题。重复建设是因为每个工具都可能独立设计与目标设备交互的接入层，导致Agent在IT对象上增加。技术债则意味着当需要构建第 N +1个场景时，原有的技术架构、功能和数据无法满足新要求，这也是很多企业在构建运维工具体系时发现的问题，实际的运维活动未能得到良好的改进。

3.2.2 组合工具领域

运维活动往往难以在单工具领域形成闭环，原因是：第一，很多运维活动不是由某一个人或某一个团队就可以独立完成的，它会跨越不同的团队和岗位，甚至会跨研发、运维、运营、监管、服务质量等多个部门，单工具无法支持这类跨多部门的运维活动；第二，运维工具软件不可能没有功能边界，因此，它服务的用户相对有限，支撑的运维活动也有限；第三，运维管理这个业务形态是管理活动加技术约束的综合体，单工具本身很难面面俱到，既要考虑管理闭环或诉求，又要考虑运维操作相应活动的实现。

组合工具领域是从运维软件支撑运维场景来分析的，还是以一个较为综合的运维场景为例来做分析。

以企业的投产发布运维业务为例，投产发布系统的功能设计如图3-5所示。

1．假定情境

100多套业务系统，5000多个K8s容器集群主机节点，5万多个主机节点，要求实现高质量、高安全、高效率的统一发布。

2．业务设计

（1）组织角色

以应用系统发布为例，应用运维负责人负责跨部门协同，如协同研发人员、基础设施维护人员；发布经理负责发布的统筹、组织和方案把控，以及外部沟通、业务影响评估和风险回退控制；发布工程师负责发布的任务编排、发布执行、验证、回滚；技术专家负责对软件包的质量管理；基础架构专家负责准备对应的资源及环境。

（2）工作流程

由投产计划、程序验证、投产评审、投产执行、应用验证这几个核心流程组成，每个流程可以进一步展开到里面具体的角色活动。

（3）关键活动

❑发布经理配置发布模板，模板包括对传统及容器化架构环境的3类操作：文件分发或镜像发布、脚本执行、基于接口的容器化调度编排。

❑发布工程师基于发布方案输入参数，参数包括发布对象、对象编排、介质（含二进制包或镜像、配置文件、脚本、SQL等）、时间窗口等。

❑应用运维负责人监视发布大屏以及获取运营分析数据等。

（4）工具设计

1）接入层：与不同环境及不同资源对象进行对接，主要是主机和容器化环境。

2）逻辑层：核心是任务编排、制品管理、应用管理，从而满足一站式发布，支持灰度、蓝绿建设。

3）界面层：面向不同角色的生命周期活动阶段，如发布经理最关注影响分析、发布编排、发布验证、发布回滚；应用运维负责人最关注发布计划、影响分析、回退机制及运营数据。

4）外部集成：与DevOps联动、触发告警时间屏蔽、与ITSM变更流程联动。

那按什么样的逻辑来组织这种跨工具场景的运维活动呢？这就是我们所强调的一体化运维领域最为核心的一个点—业务活动一体，组合工具场景示例如表3-1至表3-5所示。

当我们组合工具以满足运维场景设计时，将面临一个非常关键的问题：如何避免工具之间的孤立，实现业务活动的一体化？这需要建立一个技术平台，以支持整个运维工具体系，而平台架构抽象是其中最核心的要素之一。

3.2.3 平台架构抽象

如果把所有关键运维场景做成一个一个独立的软件，运维活动基本上是很难运转的，这时就需要从整体工具体系架构的视角来做审视。

以典型的资源交付管理场景为例，如图3-6所示。

资源交付管理是企业的基础设施运维人员的日常重要运维场景之一，主要内容是将资源以服务的方式提供给消费方，并交付完成，最后进行运营管理。

❑资源管理方纳管企业的各个环节的IaaS、PaaS甚至是SaaS资源。

❑以服务发布的方式提供给用户。

❑授权用户可见和可用的服务。

❑服务申请，提出规格要求，进行请求。

❑服务审批通过，并有资源容量等决策依据。

❑资源管理方进行人工或自动交付，尤其是大规模云环境，自动交付已成必然。

❑纳入运行管理环节。

❑进行监控、告警和自动化操作接入。

❑纳入CMDB配置库进行管理。

❑纳入负载和运营分析。

❑扩缩容、回收的闭环动作。

❑计量计费进行成本统计。

❑结算进行财务运营。

企业类似的运维场景还有很多，其共性体现在如下3个要素上。

❑模块：例如，都共用到对象接入、CMDB、流程编排等模块，资源交付的CMDB需要纳管上线的资源，对象接入用来驱动做自动化交付，流程编排用来做工单审批和自动化交付的过程编排。

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

❑服务：以服务的方式对外进行统一提供，所有运维活动的最终传递价值都是以服务方式提供的。受众并不关心服务背后的运作机制，关心的是服务、SLA和体验。

因而，我们需要进行整体的平台架构抽象。

1）共性模块能力化。共性模块抽象本质是一个积累的过程，遇到工具需求，拆解出接入层和逻辑层的共性能力，然后单独来设计，这样逐步积累、裁剪，就能设计出合理边界的能力项，然后注册到iPaaS（integration Platform as a Service）中，以组件的方式对工具提供模块和数据消费，如图3-7所示。

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

3）活动场景方案构建。PaaS的本质是以能力化的软件集成架构，来解决变化的需求的能力，因而我们如果从下往上看，iPaaS做了技术能力抽象，基于aPaaS做了单工具领域集成和一体化，则再往上就是组合工具，而这里的整个能力、数据和服务集合，就支撑了运维活动的展开，如图3-9所示。例如：为了有效地实现应急保障活动场景，我们需要有应急协同、预案管理、应急处置等组合工具，而这些工具的构建都需要基于CMDB获取对象、基于可观测获取指标和运行状态、基于流程来做协同和工作推进等，所以这时越面向一线用户的运维软件需求，越应该是可组装和轻逻辑的架构。

总之，平台架构抽象是一个在运维工具建设领域必定要建设的事情，好的规划和设计可以规避掉目前在工具体系建设上的很多关键问题：

❑工具之间无法联动，没有有效的功能和数据集成。

❑工具能力无法复用，不断重复投资。

❑没有有效的扩展性，烟囱集成的模式使得技术债越来越重。

❑组织被工具绑死，而不是基于工具激活组织来持续供给到业务。

3.2.4 数据与AI加持

随着业内方法论和实践的变化，IT运维管理逐步诞生出以下两种工具体系的建设流派。

1）基于数据驱动的工具体系建设方法。其本质与业务架构治理的思路类似，基于运维大数据的能力，把传统工具定位为采集端，在数据平台中实现数据的清洗、关联、逻辑计算、分析，然后得出运维相关的结果。例如进行故障影响面分析，传统的针对业务关联对象的监控通常由不同的监控系统承载，数据散落在各个监控数据库中，而业务拓扑关联的集群、主机、服务、进程、硬件等关系数据存放在CMDB中，基于大数据平台的统一数据采集分析能力，可以基于故障场景快速定位业务受影响的范围，为后续的应急管理预案的有效启动和故障根因分析提供决策依据。

2）基于AIOps的工具体系建设方法。AIOps是Gartner在2016年首先提出，又在2017年重新定义过的概念，即人工智能与运维的结合，旨在基于运维数据，运用大数据、AI和算法等相关技术，进一步提升运维效率，包括运维决策、故障预测和问题分析等，直接或间接地提升目前传统IT运维（监控、自动化、服务台）的能力。

从技术发展的成熟度和运维业务的本质来看，技术的发展可能会带来业务的裂变，但是运维领域更为复杂，基于数据或AI驱动的工具体系往往面临如下挑战：

1）运维的复杂度。它来源于3个维度：业务变化和技术架构的迭代（对象）、运维管理的模式（管理）、运维的自身成熟度建设（治理）。也可以说，运维是一个较为“长坡厚雪”的建设模式，即可能随业务变化而变化，例如银行走向分布式核心和云原生架构，对运维的能力和工具要求会与传统的完全不一样，更为关注业务、面向异构化架构和高可靠场景。

2）运维数据的复杂度和质量。运维数据包含各类数据类型和存储格式，包括：如CMDB半结构化的，可能用到半结构化、图等数据库类型；如监控时序类的，可能用到时序数据库；如日志类的，主流的仍然是ES。此外，数据质量的治理难度很高，尤其是当需要对数据进行实时、离线、聚合、关联等复杂处理时。

3）AI模型训练的成本和准确率。AIOps领域的模型训练需要有好的样本数据、有监督和无监督的训练模式、持续的调参和优化，以及配套的MLOps平台来完成模型供给。对于企业投资而言，要发挥比较高的价值，人才、模型、应用等要素缺一不可。因此，AIOps全面化应用的最大挑战仍然是成本收益的性价比，期待这个生态的持续发展可以逐步优化这个关键矛盾。

综上，从工具体系建设的角度来讲，我们认为基于运维业务的大逻辑，运维数据要重视治理和消费，AI要能够赋能工具。

1）运维数据的治理和消费：主要包含元数据管理、主数据管理、数据标准管理、数据质量管理、数据模型管理、数据安全管理和数据生命周期管理几个部分。例如：通过对日志、性能、容量、安全、可用性、业务感知、客户反馈等数据分析，快速发现影响业务系统的潜在问题，在异常问题爆发前优化应用，提升系统健壮性；同时，基于日志的异常检测可以帮助故障问题的排查和快速根因分析定位，提升业务连续性保障能力。

2）AI赋能工具；模型要在数据中持续成长，因此运维领域比较典型的几个AIOps场景，如异常检测、告警降噪、智能派单、智能问答、基于条件的根因定位等，应归属到工具域中去建设，而不是单独采用MLOps的做法，使得AI场景脱离的工具支撑运维业务的逻辑。监控系统AI工具加持的建设逻辑如图3-10所示。

例如，我们可以在告警事件中心，通过基于时间序列的算法以及CMDB中的信息，智能地进行告警降噪，提升告警信噪比；还可以在监控中心中，通过时间序列算法对指标进行实时检测，动态发现指标异常点等。此外，在数据化、智能化持续建设的过程中，逐步扩展更多的应用场景和运维软件能力。我们坚信AIOps是未来，AI赋能运维是已确定性的未来，AI替代运维还需要整个生态持续建设。

3.2.5 实践案例

下面以某银行客户为例来进行一体化、平台化、服务化、数智化的运维平台建设剖析。

客户的业务建设：银行业的业务体系分别经历了电子化、银行信息化、信息化银行、智慧化与生态化银行的业务战略，对应大机时代、数据集中、两地三中心、分布式架构建设等业务和技术架构阶段。

运维管理体系面临如下普遍的痛点：

❑业务增长带来IT对象和架构异构化剧增。

❑新技术发展对运维的要求高，尤其是分布式、云原生架构。

❑国产化、自主可控要求，以及监管匹配要求。

❑工具烟囱管理成本高。

❑工具体系难以支撑运维组织的设计。

在运维体系建设的过程中，运维平台经历了如下3个阶段，逐步走向了一体化、平台化、服务化、数智化的模式：

1）构建运维API生态，以平台化的架构实现运维对象的数字化和状态数字化，CMDB工具体系和监控告警体系先行。

2）IT服务化，数据中心作为生产管理者，以流程的方式对外服务，整合各运维服务化工具，提升服务能力和用户体验，这个阶段ITSM、自动化、门户工作台持续建设。

3）数智化与持续发展，当面对更为海量的分布式组件和微服务时，运维的对象覆盖能力和场景能力进一步发展，并引入数据和AI来解决分布式架构中的运维问题，这时面向分布式架构的应急、容量、故障预防、故障分析、故障定位、故障处置，以及数据与AI的能力持续建设。

运维的技术蓝图经过持续的实践，逐步形成了一体化、平台化、服务化、数智化的模式：从技术视角来看，即基于PaaS架构，能力与场景解耦，持续构建运维工具体系，以及支撑组织运维开发转型；从业务视角来看，即生产运行、服务管理、技术管理的一体化平台。其中，一体化强调场景支撑，业务活动一体；平台化强调架构整合，实现复用与扩展；服务化强调服务交付，优化对外服务和体验；数智化强调发展方向，数据和AI的能力融入运维工具体系建设。运维工具体系蓝图如图3-11所示，充分体现了一体化、平台化、服务化、数智能的运维平台架构。