必示科技刘大鹏：AIOps·金融行业智能排障体系建设实践与思考
发布时间：2021-08-05 16:30:41
近日，由金科创新社主办的“2021金融科技创新发展论坛暨第四届金融科技管理人年会”在青海西宁成功召开，会议得到北京软件和信息服务业协会、山东省支付清算协会、江苏省支付清算服务协会的支持。来自银行、保险、证券、支付等领域以及IT企业的100余位相关行业领导、专家共聚一堂，以“数据原生 科技赋能”为主题，探讨数字金融现状、趋势与发展策略，分享金融业数字化转型思考与创新实践，探索中小金融机构数智化发展的未来之路。
在当前国内外形势复杂多变的大背景下，科技创新赋能金融转型既是全球性的挑战，更是中国数字金融领域实践和应用发展的重大机遇。会上，必示科技CEO刘大鹏作为特邀嘉宾，发表《AIOps·金融行业智能排障体系建设实践与思考》主题演讲，深入剖析当下运维排障面临的挑战，阐释必示科技与多家金融行业用户共同探索的智能运维体系建设思路，希望对行业用户有所启发，共同推动AIOps行业高质量发展。
以下为演讲全文：
各位专家好！
今天跟大家分享一下我们团队在过去5年聚焦企业数字化转型中的关键环节——保证系统稳定运转的实践经验。这些经验是我们与多家金融行业头部企业共同探索出来的，希望能对大家有借鉴意义。
IT系统分为“可用”和“不可用”，我们的目的是降低平均故障修复时间（MTTR），延长系统无故障时间（MTBF）。这是IT运维最关键的职责，也是AIOps当前最成熟、最成体系的落地方向。
IT运维工作面临的挑战越来越严重。下图左侧展示了一家大型企业IT系统从底层硬件到上层软件数量变得非常庞大，而且它们之间互相关联，牵一发而动全身。右侧拆成了多个维度：不同运维对象，不同数据类型、不同故障，不同行业、技术架构演进等。可以看到，运维管理的对象一直在发生变化，运维空间在不断扩大，里面任一节点都有可能出现问题，并引发相关联的软件、硬件表现异常。
大量异常信息混杂在一起，故障快速定位和提前发现风险变得越来越困难，这也是我们要引进AIOps去提高排障效率让金融行业稳定运转的原因。
传统排障与智能排障的核心区别是什么？我们用一个简单的示意图（下图）来展现，传统排障和智能排障的输入都是海量异构的运维数据。但是，传统排障一般是在报障或者告警后，由运维专家、管理员去分析数据、排查原因。智能排障是通过软件或者算法的方式，把海量数据中有价值的点提前或实时分析出来，帮助管理员做决策，节省对大量原始信息做排查的时间和人力。
AIOps建设在全球范围内依然是一个较新的命题，我们与多家大型企业探索的AIOps实践之路，大致分为三个阶段：
- 第一阶段——智能排障1.0：黄金排障场景。我们找到运维领域常用的、数据相对普及且适合AI发挥效力的黄金场景，通过人工智能助力运维工作。这里列举了一些案例，围绕“MTTR”和“MTBF”，做到让故障快速被发现、快速被修复，降低无效告警带来的工作开销。比如平均告警有效性提升90%以上，故障定位准确率达到85%以上，平均故障修复时间降低70%。
- 第二阶段——智能排障2.0：排障树。这是一个可以不断扩展的平台，我们正在和若干大型金融机构展开试点工作。
- 第三阶段——智能排障3.0：运行风险管理。我们希望把发现问题和排除故障的工作再做扩展，提前预知风险，避免形成影响业务的故障。
智能排障平台架构中，下面是IT系统建设的物理层，以及各种各样垂直领域的监控工具。我们的核心在于利用这些数据做好故障快速发现和故障分析。最上层是告警通知的可视化呈现。
第一阶段
金融业智能排障黄金场景
围绕金融业最常见的运维问题，我们找到了AIOps可落地、有效果、能发挥力量的四大黄金场景。首先，我们会通过交易监控数据，去检测交易量、响应时间、成功率、响应率等黄金指标的异常，实现提前10分钟至数小时发现问题和隐患。
其次，系统异常之后，如何从庞大的IT架构中精准排查到故障的根因？我们可以从不同系统间的调用关系、交易明细维度以及机器性能指标异常等维度，为管理员排查故障提供更进一步的线索，实现分钟级定位问题。
下面具体展开说明一下：
■ 业务指标异常检测
各种业务指标的波动形态其实是非常个性化的，有存在周期性波动的指标，如交易量；也有平稳波动的指标，如响应率；还有些指标会因为系统变更或市场促销行为而产生突变。而且大型金融机构往往有很多套业务系统，对应的业务指标曲线可能达到成千上万条。在这种情况下，人工逐条指标配置告警规则的方式是成本较高的，那么如何针对不同类型的业务指标实现自动的异常检测发现问题呢？
我们采用无监督机器学习算法，无需人工干预、自动识别指标数据特征，根据各条指标的数据特征不同，选择最合适的算法、基于历史数据进行模型训练，实现对众多关键业务指标的实时异常检测，准确、提前洞察业务风险。
■ 调用链根源系统定位
在金融企业数据中心，众多的业务系统无论是微服务架构，还是传统的集中式架构，每类业务都要经过多个系统间交付调用来共同完成，系统间或服务间的调用关系错综复杂。业务上一旦出现故障，许多系统或服务可能会同时出现告警，如何在大面积故障中快速找到根因？
调用链根源系统定位利用系统间或服务间的调用关系数据，可以从众多系统或服务间准确识别和定位故障的可能根源，解决运维人员需要逐个排查的痛点，提升故障排查效率。
■ 业务明细多维定位
金融领域的交易型指标，背后往往具备多种维度属性，例如交易来源渠道、省份、城市、IP等维度。当某个业务指标出现异常时，例如交易耗时突增，我们需要尽快知道这次耗时突增的根因是哪里，是否属于某个渠道的问题；需要尽快知道这次耗时突增的影响范围，是否集中在某个省份、某个城市。
业务明细多维定位场景可以从交易明细数据的大量业务维度中，迅速准确的定位出哪个交易维度导致了异常，帮助管理员梳理排障线索。
■ 机器指标定位
当业务发生故障的时候，如何快速判断本次异常是否源于基础架构层面的问题？如何从大量的IT基础设施中定位异常根因？例如是否由于某几台主机的磁盘I/O问题导致了这次业务指标的异常波动？
机器指标定位场景能够针对基础架构层面的指标数据进行快速扫描，识别在业务异常时段内，基础设施的指标是否存在异常波动。例如是哪个机器实例的哪些指标有问题，是某几台主机的磁盘I/O还是某些数据库实例的连接数有问题。通过这种快速的大面积基础设施指标分析，可以有效帮助管理员缩小排障范围，缩短故障排查时间。
目前这四大黄金场景，已经在我们与金融企业的合作项目中产生了巨大的生产价值，这里介绍一个具体案例。
某家金融企业上线智能运维场景之后，运维能力得以提升。系统覆盖从100+提升到240+，可以深入到内部查看更细粒度的系统；监控点数量从600+提升到5500+；实现18个多维度的分析，直观显示有问题的维度组合，而非故障发生后进行人工筛查；同时可以不依赖全局流水号做检测。
大家都知道，全局流水号是很有价值的，但是因为金融企业的应用系统建设来源多样，自研与外采，很难要求所有系统统一打上流水号。针对此现状，我们设计了可以在没有全局流水号的情况下，做全局交易链路的分析的算法，做好跨系统间调用链的定位。
在上述方案下，我们的AIOps系统在该金融企业带来的价值：上线2个月的时间共发现隐患57个、提前预警2次重要故障、告警准确度达到95%、分钟级定位异常、单次分析交易明细数据达到360000+、单次分析访问关系数据量达到3000+。其中，很多隐患是开发在写程序或者设计架构带来的问题，通过我们的检测方法做到提前发现、提前整改。
第二阶段
试点和逐渐完善的排障树场景
运维排障的空间非常大，且在不断变化和演进，涉及到很多的领域知识、数据类型和检测算法。比如随着“上云”成为趋势，很多金融企业也在考虑“上云”，技术变化会随之带来新的运维挑战。比如管理节点突增、大量引入新组件、微服务拆分之后，业务调用关系变得更加复杂。原来可能1条交易链路是6个系统，现在可能是26个服务，排障变得更为困难。我们希望用一种更成体系的方法把整个排障系统构建起来。
首先，智能运维不是狭义的只有机器学习算法，还有很重要的部分是专家知识。我们会用专家知识构建排障树主体，里面的每一类算法就是在检测专家所需要的信号。这类似于医院里专门的检测科室，CT和验血相当于算法，目的是检测“病症”是不是发生了。但是，治疗还是要依赖于医生的经验，包括对人体结构的了解和以往的治疗经验。
排障树按照这样的体系不断去扩展、覆盖、串联多个AIOps场景，我们就可以沉淀很多企业运维专家的排障经验，之后其他企业可以自动化应用专家排障经验，不用再自己去摸索。
以Oracle数据库排障为例，图中右上角绿色区域里面有很多小方块，每一个小方块是针对Oracle的运维对象要检测的问题和需要的数据、算法。当某些信号出现的时候可能是网络导致，也可能是存储导致，或者是Oracle所在的体系导致，就继续排查。如果每一个节点需要算法，我们就用算法；如果不需要算法，规则也能搞定，就用规则。我们把运维专家运维经验集中起来，而不是分散在不同专家的头脑中，解放专家的精力做更有意义的事情、更有价值的事，这些运维经验可以行业内共享，发挥更大价值。
我们积累了很多组件的排障经验，它们都会按照排行树的框架和标准积累沉淀。这个表格列了一些针对不同组件需要什么样的数据，需要怎么去分析数据，检测出什么样的问题，以及这些问题之间的关系。当然，实际组件会比这个要多，相关经验未来也都会积累出来。这样我们相当于拥有了一个具备80%排障能力的机器人，可以帮助我们去做排障的工作，提高效率。
AIOps建设的经验教训总结
最后分享一下我们实践中踩过的“坑”、得到的经验教训，希望帮助大家避免这些问题。
总体规划，分步建设。
智能运维是个新的方向和趋势，并且已经在先行者的探索下积累了不少实践经验和路线，特别是排障场景的智能化改造已经比较成体系，所以是可以做总体规划的。同时，因为各家企业条件各异，建设过程要分步往前走，不能一蹴而就，就像上面提到的“三个阶段”，也给运维团队转型留够时间。
有的放矢，以智能排障平台建设为试金石，按需完善上下游系统和数据。
不管是运维数据还是运维周边工具，它们的优化和完善都是无止境的。以智能排障具体场景作为改善周边系统和工具的试金石是事半功倍的做法。比如，每次排障过程中看智能排障平台是否真的有帮助，如果没有帮助，我们就能知道是哪些数据和系统不完善导致这次没有分析结果，而不是泛泛地做数据改造、上下游的完善，因为这样做的投入产出比例比很低。
找准场景，是落地效果的关键。
当前AI技术不是万能的，本身有能力限制，最主要的就是AI善于解决的是确定性问题，而不是开放性问题，所以必须找准场景。比如比较成熟的人脸识别就是一个很具体的场景。
找准场景就是帮助AI技术去框定边界，用算法和数据分析的能力解决边界内的问题。同时需要注意的是，我们要找到运维常用的场景，而不是天马行空地想象“有什么数据就做什么分析”，这样可能分析出来的结果对工作没有帮助。
团队转型AIOps需要时间，接触他人实践经验是加速器。
对于运维团队来说，要不断去接受AIOps新理念，转变思维模式，在接触数据的过程中思考“如何固化经验”、“如何从繁琐重复的排查工作中释放精力”、“如何利用运维经验和知识做更有意义的事情”等。这个过程需要时间。
缩短排障时间最好的方式是跟有经验的实践者多交流，去交换经验，从过往踩过的“坑”中探讨经验教训，来建立对AIOps的实际认知。
以上就是我今天分享的有关排障体系建设方面的实践，谢谢大家！
