从 DevOps 到 AIOps，一文聊聊面向终态的监控平台建设

作者简介

顾黄亮，十年研发运维经验，涵盖基础架构、应用架构、数据库、DevOps，有互联网，电商，金融从业经历。专注于 DevOps 在企业中的应用和落地，致力于企业智慧运维体系的打造。

参加多个行业、国家标准的编写，《开源许可证使用指南（2018）》作者之一，国标《研发运营一体化（DevOps）能力成熟度模型》作者之一，《企业IT运维发展白皮书》作者之一，曾供职于航天晨光、上汽集团云计算中心，现任苏宁消费金融安全运维部负责人。

前言：在运维数据的系列文章中，系统的阐述了有关数据运营的一些阶段和过程，众所周知，运维技术栈是没有边界的，因此通过这种属性进行运维能力输出的延伸存在很大的主观判断性。

随着运维能力的不断增强，主观判断的不确定性随之放大，给运维能力输出的稳定性保障带来了极大的挑战，同时也让我们认识到，面向过程与操作的运维能力输出模型将难以为续，这一特性在 DevOps 和 AIOps 的建设上表现的尤为突出。在本篇中，我们将通过监控平台来系统的阐述“面向终态”，来解决运维数据运营中的一系列问题。

一、什么是面向终态

需要明确的是，面向终态是一种设计方法，在运维领域，有核心的四个能力域，分别是安全、稳定、高效、低成本。这四个能力域也匹配着运维能力输出的四个阶段，分别是手工运维、自动化运维、DevOps、AIOps。在这四个阶段中，运维的对象始终贯穿了系统、用户、业务、业态，因此面向终态重点在于终态的对象和范围。

以系统为例，面向终态描述了系统的最终形态，用户只需要描述自己需要什么，不需要详细规划执行路径，系统会根据线上的实时状况以及运维知识库来动态调整，来达到系统安全稳定的目的。举个通俗易懂的例子，在灰度过程中，会根据灰度的需求来自动执行灰度策略来动态分配流量。

以用户为例，面向终态描述了用户的最终需求，重点在于系统内部的控制逻辑，主要核心在于声明式API，用户只需要描述最终需求，不需要提供详细的逻辑设计，系统会根据需求通过声明后提交给系统，最终完成用户期望的结果，和面向系统的终态不同的是，面向用户的终态主要是暴露给用户的使用方式。

二、监控平台的意义

随着科技的不断发展，线上业务占比不断攀升，信息科技越来越成为核心生产力，因此一些非功能性的需求逐步上升到一个比较高的程度，可用性、可靠性、业务连续性的兜底都需要监控来完成。另一个方面，数据存储成本、数据价值输出、数据衍生能力也需要将核心业务数据扩展到一个较宽泛的范围，这也是面向终态的监控平台。

在运维领域来说，业务保障域是监控平台的核心功能，具备全方位无死角的监控覆盖范围，以业务为顶层视角，系统为主体数据输出模式，对故障进行检测、诊断、恢复、预测，其中故障预测是基于运维经验沉淀和积累的结果，对数据的分析来总结出故障的模式，从而进行预测。在IT数字化方面，监控数据是重要的数据资产，因此监控平台需要承担核心数据集散地的作用，为业务数据提供补全，为技术数据提供支撑。在成本预测方面，容量管理和采购管理需要相应的资源利用率提供数据支撑，还包括投入产出比来进行优化建议。

因此，基于系统的面向终态，监控平台应该包括以下几种特性。①基于业务的实时链路监控；②基于平台的应用异常实时监控；③基于用户的子域数据汇聚；④基于数据交换的实时输出；⑤基于预警的统一集中收敛。

基于用户的面向终态，用户的最终需求涵盖了故障处理的事前、事中、事后的全流程，在事前阶段，用户关心有没有做监控，在事中阶段，用户关心监控是否及时，相关指标的准确率高不高，事后阶段，用户关心故障复盘是否能够达到既定的目的。因此监控平台应该应该包括以下几种特性。①以服务目录的方式对监控对象进行解读；②能够以自动化的方式对监控对象进行全覆盖；③能够智能的对报警阈值和等级进行定义；④对故障处理流程进行学习，并形成知识库。

从输出能力来罗列，面向终态的监控平台应该对监控数据进行全生命周期管理，以达到运行态监控、安全审计、业务分析和数据输出的功能，并以数据集散地的形态来提供第三方数据的接入和接出。

从监控平台的目标来看，需要发挥的作用主要有以下，①能够实时的采集数据；②能够实时的反馈业务的运行态状态；③能够智能的预知故障和告警；④能够支撑能力子域进行辅助故障定位；⑤能够支撑研发人员对系统进行针对性的优化；⑥能够对容量规划进行辅助分析。

从监控平台的数据覆盖度来看，横向需要进行数据宽度的延展，从网络、服务器存储、系统、应用到最终的业务层进行数据的采集和汇聚。纵向需要进行打通用户终端、流量出入口、系统集群、产品运营进行端对端的数据多维度关联。

通过一张图进行简单的理解。

三、现有监控方案的一些问题

现实中，企业已经采取各种各样的监控软件来达到业务域保障的目的，比较典型的是以为Zabbix、ELK为代表的开源软件，在实际使用中都取得了很好的效果。但从面向终态的方法来看，还存在一些需要改进的点。主要有以下，

1. 对于企业来说，监控能力的全局性较弱，现有的监控系统只针对某个领域或者某个能力聚焦，无法对全局有全面的掌控。

2. 无法将业务层往下的子域的链路关系、数据关系形成逻辑汇聚，因此造成排错时间长，业务恢复缓慢。

3. 监控告警多且杂。正因为有很多领域级的监控软件，这些不同的监控软件造成了各种独立的告警，导致告警风暴。

4. 不支持对其他能力子域的系统接入，尤其涉及到业务链路级、接口级、方法级的数据自动获取，导致监控漏配、错配引起的准确率和召回率不达标。

5. 作为数据的接入接出的集散地，对数据的聚合和二次计算支撑不够，导致数据的资产能力大打折扣。

6. 对大规模的时间序列分析和根因定位存在功能缺失。

四、面向终态的监控设计

在面向终态的监控设计过程中，需要更加友好的面对监控对象和监控使用者，因此和普通监控所不一样的，第三方的数据接入需要在服务目录的范畴。在面向终态的服务目录设计中，包括如下特性。

1. 提供可视化的服务内容，使用更为便捷，降低使用成本，提升用户人群的覆盖度，把监控视角提升至业务优先。

2. 将第三方数据统一以服务中介的方式进行进行接入，服务中介在于端到端的数据开箱即用方式，如外接接口管理平台，接口的新增、废除能够自动的进行统计、计算和分析。

3. 由服务中介指定相应的服务提供给监控平台用户，通过对数据标签的方式自动的进行关联，根据实时、近线、离线不同方式的处理，最终呈现给特定的标签用户。

4. 监控平台用户可自定义的接入可用的服务对象。

在数据的处理方面，更偏重于清洗和指标分层计算，在此之前，需要数据源的多样化匹配，支持kafka、clickhouse或victoriaMetrics等多数据源的接入，最终需实现实时消息、文件的接入和数据的实时聚合。在数据聚合的需求梳理中，需达到多个维度和指标对数据进行聚合。数据衍生是面向终态的最直接表现，需支持根据不同的指标进行运算，得到用户想要的多维复合数据。

其中，在清洗阶段，需要实时的接收数据，进行数据的处理、转换、清洗，任务一般基于storm或flink实现，经过清洗任务处理后的结构化数据通过消息队列进行数据流转或回流。在指标计算阶段，对结构化数据进行相关指标的计算，需达到高吞吐量，标准SQL等特性，还需要加强时间窗口、去重等能力的匹配。根据标签数据和标签用户的不同特性，动态的对数据进行实时处理和离线更新。

在数据的回流输出方面，面向终态的监控平台，需要根据监控的目标不断的去回检当前系统状态，从而为面向终态执行决策的时候，提供部分的依据，因此模型管道的构建必不可少，这也是我们常说的异常检测的功能，下图为数据反馈图。

在异常检测方面，可以从告警分析和根因分析来落地。在告警分析方面，基于系统的面向终态需要实现，①对告警的时间顺序进行趋势分析；②对指标对比进行分析，降低指标预警的召回率；③对已知的告警进行标记，辅助优化模型，间接提升指标预警的准确率。在根因分析方面，通过数据的下钻和关联数据的收敛，根据最终的影响因素来对算法分析出的主因进行判断标记，通过主因判断的结果符合度指标来进行算法调优。

在基于面向终态的监控平台设计中，平台应有如下分层。①用户体验层；②服务能力层；③数据分析层；④数据加工层；⑤后台管理层。

五、写在最后

面向终态继承了AIOps的理念，通过运用大量的声明式api来提高“无条件”的极致用户体验，同时运用机器学习来加强了数据的输出和变现能力，这种设计方式将技术进行反向解耦，在服务能力的范围之内，将数据纳入到用户体验中，提升数据的反馈能力，拓展了监控平台的用户范围，更安全、稳定、高效、低成本的践行高效运维理念，也解决了运维数据运营中的一系列问题。

在本篇中，主要描述了面向终态的设计方法，此为本系列的开篇，后续会对基于面向终态的监控平台进行详细的阐述。

顾黄亮老师数据运营系列文章：

运维数据建设和管理方法，看这一篇就够了

交付全链路数据，苏宁消费金融在 DevOps 度量设计的思考

建立数据指标体系，推动 DevOps 全链路度量闭环

10年技术老兵的总结：运维数据场景的 5 个高阶落地方式

“高效运维”公众号诚邀广大技术人员投稿，

投稿邮箱：[email protected]，或添加联系人微信：greatops1118.