![《用智慧（AI）的眼睛观测告警》-以事件追踪为核心的告警智能分析平台]( "《用智慧（AI）的眼睛观测告警》-以事件追踪为核心的告警智能分析平台")
本文来自西骏数据研发总监-徐国忠在 2022 GOPS 全球运维大会深圳站《以事件追踪为核心的智能告警分析平台》的演讲实录
1.以事件为核心的告警中心建设探索
2.告警中心建设的实践案例分析
3.承载告警中心的平台-MC-Stack
![《用智慧（AI）的眼睛观测告警》-以事件追踪为核心的告警智能分析平台]( "《用智慧（AI）的眼睛观测告警》-以事件追踪为核心的告警智能分析平台")
整个IT历史主要集中在最近的50年，运维体系可大致分为四个阶段，从最开始初建期的手工运维模式、成长期的脚本运维模式、成熟期的工具运维模式，以及变革期的数据运维模式。
整个运维当中不可或缺的一环就是整体告警中心的建设，虽然我们不断引入新的技术，特别是在微服务架构体系下，但是我们依然面临很多挑战：大量误告和重复告警、系统多样、告警散落、运维经验无法沉淀、缺乏全局性、多维度视角、信息爆炸，无法聚集等。
整体预警信息是属于爆炸的状态，所有业务一天会有上万个告警推送，多的甚至几十万，这样的情况屡见不鲜，每个业务系统拥有数以千计的体量，即便是具备高专业度的业务人员亦是独木难舟。
在整个告警中心建设过程中，我们也面临各个参与者之间存在的矛盾。作为告警中心的“建设者”的厂家们和客户们更多考虑的是整个系统兼容性、扩展性，这给传统运维也带来了挑战，甚至客户需要更多认知来认识新的系统。有些运维工程师甚至会对新的概念发起挑战，比如说对于AI的算法，是否能把里面AI算法的东西具象化出来？因此，他们认为AI是更多偏向鸡肋的存在。
基于这样的建设问题，也引发了整个运维中心的建设思考，应该以怎样的建设思路来满足新的运维体系，或者说新的运营模式下如何建设？
可能有人会提智能运维是解决所有运维的问题，也有人说带来智能化、便捷性，有人会从效率上考虑这个问题。
我的解析是，运维的第一性原理一定是保障业务稳定和实际的运行，再叠加智能的概念，我觉得它更多考虑的是高效层面，因为我们针对所有运维层面上，我们引入了MTTR、MTBF指标都是在解决运维的高效问题。
同样在我们整个告警中心的建设上面，我们依然在解决高效的问题，我们在考虑什么样的告警中心是最高效的。那么，我们在告警体系里面什么信息才是最重要的呢？我们认为这一定有非常高相关度的告警或者告警的集合才是我们真正关心的点，这就是我们今天要引入的概念——告警事件的概念。
![《用智慧（AI）的眼睛观测告警》-以事件追踪为核心的告警智能分析平台]( "《用智慧（AI）的眼睛观测告警》-以事件追踪为核心的告警智能分析平台")
告警事件是什么样的定义呢？在我们的理解中，它是有一个相同的诱发因素引起的整体告警集合，它是一个集合，不是一个单体，我们理解的CPU它是一个单体，而告警是一个集合。
你可以认为它是一个潜在的或者是一个隐藏的故障，作为一个生产故障，我们结合第一性原理的思考，它一定是有业务偏向性的。在理解告警事件的过程，举个例子，我们肯定做过拼图，我要在杂乱无章的拼图里面去找一些它可以成为图案的可能，这相当于我们在告警中心要解决的问题，我们要在众多的信息中寻找和我们业务故障可能存在关联的集合，这就是我们作为告警中心建设上的一个新思路。
同样作为告警层面的输出，依然具备了告警的整个生命周期，从整体数据介入，当然我们要考虑更多维度，我们会涉及CMDB的接入、指标接入、变更接入，在这样的基础之上，除了传统的聚合、收敛处理以外，我们还要去做类似告警事件的AI识别和涉及事件的分析；甚至我们以事件作为一个维度，沉淀整体的运维，就像我刚才所说的，它是一个识别过程，同时它也是一个处理过程，包括和我们预案整体的结合。
那么在故障事件引入过程，为什么我认为可以用AI层面去解决这个问题呢，是因为我们认为整个事件或者整个生产故障其实是可以被具象化出来的，每一类故障事件都有其特定的一些形态特征。
![《用智慧（AI）的眼睛观测告警》-以事件追踪为核心的告警智能分析平台]( "《用智慧（AI）的眼睛观测告警》-以事件追踪为核心的告警智能分析平台")
第一、是网络故障，我们面临最多的、经常发生的问题就是网络类故障，包含了我们在网关层涉及到的网络中断，甚至集群网络的问题，包括单个业务线。在整个故障分析这个事情的时候，我们发现它们是表现出一定特征的，如果是网关类，它一定表现出来的是多个业务层面的数据受到了影响，甚至我们在日志层面上会有类似超时的错误。
第二，我们在实际应用当中会涉及业务变更，业务升级也可能会引发整个线上故障，升级在这个层面上表现出的这些形态，一方面涉及性能问题，同时它要引发更多新的层次上面的逻辑故障，可以理解成新奇的问题，包括我们在固定的业务行为上的变更，比如某一类接口在行为上有些躁动，这是经常发生的业务变更引起故障的情况。
第三，对程序上面的逻辑问题，在我们测试的时候会做一些边界，会去做各种逻辑的处理，实际上我们在实际生产过程中会因数据原因等会引发交易失败或者业务层面上的问题，它表现出的一定是一个极少数的逻辑问题，但它更多表现出来的是上述提到的新的聚合类型。当然还有比较常见的数据库、内存、CPU等，这些情况是相对比较少的。
第四，生产上会有性能临界，比如说业务增量导致我们在整体业务运行当中遇到了瓶颈点，无论是中间件还是业务系统，包括服务器本身，可能存在的类似IO的性能问题。性能临界出现的时候一定会表现出行为的周期恶化过程，在实际生产过程当中，故障呈现出来的形态，它是有全局的特征，而不是杂乱无章的。
![《用智慧（AI）的眼睛观测告警》-以事件追踪为核心的告警智能分析平台]( "《用智慧（AI）的眼睛观测告警》-以事件追踪为核心的告警智能分析平台")
多因子相关性，基于上述的理论基础，包括对于生产上的总结，我们举例AI上面应用层面的思考，在整个思考上面，我们引入了类似因子的考虑，可以从整体底层建设角度来考虑，涉及到常规的CMDB的相关性，在实际运行当中，CMDB的构建有些是动态的，有些是静态的，甚至有些是精准的，有些是模糊的，在每一个厂家的建设过程中，它存在一定的不确定性，在相关性多因子考量中我们会在维度上去做模糊和精确的提取。
还有指标因果相关性，实际指标当中有些是优化指标，有些是表征指标，还有我们在整个告警过程中，它会表现出来时间跨度的元素，当然我们还希望在更多层面提供反馈因子、告警复杂性、告警数量等，还有级别的复杂度，这些都构成了我们在AI识别考虑因子的整体层面。
我们在底层分类基础上，叠加因子的考量，我们可以设计出来定位决策树，我们分析或者识别的逻辑，其实可以是一个树的概念，也可以是算法多因子相关性的过程，这是两种不同的表达方式。我们通过AI、人工辅助的形态，我们会去把我们真正的告警事件提取出来。
在这个组织过程当中，我们会面临对数据层面的处理，面临降维处置和升维思考，这两个概念放在一起，侧重点不一样，在降维处置层面上，我们更偏向于某一类数据，比如说CMDB，要去做分类提取，在整个告警层面其实我们还有标签化能力，比如说我们会去标注它是性能类，或者是网络类。针对CMDB因子，如果我们用CMDB整体视图，它其实是一个非常复杂的过程，我们怎么去具象化它的传递关系，比如说它的传递深度、传递复杂度以及它影响层面上的数据，我们要去做这样的降维处置；升维的思考，相当于我们在于告警，或者说在于数据的整个维度去做考虑。我们更多考虑比如说我们接入了CMDB的数据考量，接入了指标数据的考量，接入了日志数据的考量等，每一个维度带来更多的是我们在于数据全面性上的思考，AIOps在众多信息基础上我们去做价值信息的提取，我们要的是更多维的数据。
![《用智慧（AI）的眼睛观测告警》-以事件追踪为核心的告警智能分析平台]( "《用智慧（AI）的眼睛观测告警》-以事件追踪为核心的告警智能分析平台")
在整个告警分析基础上，我们以这样的维度去构建整个告警中心分析的时候，我们引入决策树的分析；我们针对故障类，可以有自己决策的分析，还有类似拓扑分析；还有我们在实际运营当中，其实非常重要的一点是我们关注整体影响的分析，我们去关联的类似做变更、持续日志、关联监控、时间序列的分析，我们会以时间维度整体去还原在我们的故障当中，在每时每刻、每个系统、每个时间上发生的问题，我们有一个具象化知道之后，能够更好理解整个分析、整个故障的本质。
在以上基础之上，我们引入了针对整个事件本身还有故障根因的定位，当把事件分类之后，根因定位就具备了较强可靠性。在运维层面，我们也结合整体形态，我们可以把整个历史上发生的事件作为一个故障知识库，与我们整体预案和后面的处置进行关联。
我们在国内头部券商实际的运营中碰到的实际情况，列举如下：
一、针对基础资源类形态，这个形态特征是非常明显的，这个问题本质上是数据库引起的问题，那么它会表征出来一些基础资源的告警属性，同时也会表现出来服务的特点以及性能类的问题，甚至是在日志层面上会有一定程度的表现。
二、网络故障类，在于整个网络故障发生的时候，它表现出来的形态又是非常特殊的形态，在实际网络和集群服务的中断上是有非常大的各种差异，我们通过这样的表征可以去做整体故障归类，这是一个变更，变更显著的特点我们会去接入变更的分析，在整个变更分析的时候，我们会引入变更前后行为变化分析。
三、变更故障类，在告警的表征上，其实变更的故障也是有一定特点的，它涉及业务层次上的东西会更广泛一点，特别是在日志行为上、接口行为上，会表现出大面积的形态，所以这是我们针对故障类型的解析。
同时我们在系统里面也会引入非常多的分析手段，在告警上面会去做原始指标的串联分析，也会做日志层面的串联分析，每个告警里面的信息或者事件来说，它可以有非常多的重要信息，包括时间维度的信息、日志层面的关键字，我们引入这些数据源的关联分析，让我们整个在数据定位、告警定位层面上可以做更多分析。
刚才讲到整个告警中心的建设过程以及思路，我们会引入很多外在条件，我们需要一个平台来承载整体中心的建设。
![《用智慧（AI）的眼睛观测告警》-以事件追踪为核心的告警智能分析平台]( "《用智慧（AI）的眼睛观测告警》-以事件追踪为核心的告警智能分析平台")
我们对这个平台有3个层面的考量，第一层面这个平台必须是具备ITSM的管理引擎能力，在我们整个告警事件的处置、流转等，我们需要一个管理引擎，让我们在权限上面做更多事情；第二层面会考虑到数据存储标准化接入；第三层面会考虑AIOps的算法引擎能力。
在整个平台建设上，我们引入了应用概念，我们在基础的集成里面会涉及CMDB、权限、用户系统等，我们在这个平台里面可以集成非常多不同的应用，包括监控系统、AIOps等都可以在一定层次上做集成。
![《用智慧（AI）的眼睛观测告警》-以事件追踪为核心的告警智能分析平台]( "《用智慧（AI）的眼睛观测告警》-以事件追踪为核心的告警智能分析平台")
这是我们上面提到的数据引擎，在西骏数据中引入的X-HDC，在数据层面特别是运维数据层面，它是非常专业的，主要有3类数据，我们可能更多面向CMDB，包括可能会从NPM、APM产出很多拓扑结构，这是我们关心的数据标准化。另外一个数据是我们常规接触的监控数据，最后还有日志数据的接入，我们通过一个平台，我们把所有东西集成在X-HDC中。
![《用智慧（AI）的眼睛观测告警》-以事件追踪为核心的告警智能分析平台]( "《用智慧（AI）的眼睛观测告警》-以事件追踪为核心的告警智能分析平台")
这是算法的框架，我们提供了任务队列的算法框架，最后我们在算法层面上引入非常多基于不同场景的内置算法，当然我们也允许用户在一定层次上做算法提升。
西骏数据智能告警中心是一款基于事件追踪为核心的告警智能分析的软件，通过对告警信息进行算法聚合－事件追踪－关联定位的3步快速分析模式实现更快速、准确、深入的告警故障定位，让运维人告别传统的工作方式，大幅减少告警骚扰，帮助运维人员提高告警处理和告警分析效率，助力企业业务运营平稳高效发展。西骏数据将持续不断地实现技术创新及产品革新，助力各行业数字化转型。
北京西骏数据科技股份有限公司是一家专注于数字化运维的高科技公司，专业提供基于统一运营管理PaaS平台的运维操作管控、运维数据分析（AIOps)、运维数字协同等相关软件产品与解决方案，是首批通过信通院AIOps能力成熟度认证的公司之一。公司先后申请2项发明专利，30多项软件著作权，具备完全自主研发能力。西骏数据是国家认定的高新技术企业、北京市“专精特新”企业、瞪羚企业、信创会员单位、证监会备案信息技术企业、2022年高科技高成长企业和北京市创新基金支持企业。公司总部位于北京，在天津、南京、广州设有研发中心，在上海、深圳、武汉、西安等省（区、市）设有分支机构，服务于金融、政府、能源、医疗等领域的数百家中高端客户。
原文始发于微信公众号（高效运维）：《用智慧（AI）的眼睛观测告警》-以事件追踪为核心的告警智能分析平台
评论