一、AIOps建设背景及目标
随着业务数字化转型以及架构分布式转型的加速， IT运维架构处在逐渐转型过程中，这包括敏态、稳态到双态，还有从IT运维到IT运营的转型，这些转型的本质目标主要是希望实现两个方面：
智能运维不仅是针对系统，还会针对运维管理，那么想要完成这种转变，总结农行的现状，存在以下 4 点问题：
-
隐患发现：当前运行的监控手段更多还是针对事中发生的故障，对于事前风险的隐患识别缺少相关手段
-
应急处置：分布式架构云原生技术的变革下，运维对象是呈指数级上涨，业务调用链路也更加复杂，应急定位效率也需要做相应的提升。
-
数据支撑：运维领域缺少规范化的运维指标体系，想做一些运营方面的决策很麻烦，缺少规范化的数据支撑做智能运维或者运营。
-
运维管控：生产运营的管理环节很多还是依赖于流程之后的人工排查、事后的审计。这种管理力度是比较粗放的，规范落实的效果难以评估。
期望通过 AIOps 实现的四个目标
针对以上这四个问题，我们希望通过 AIOps 帮助实现的四个目标。
一、更早地发现风险。我们能够从被动等待问题发生走向主动地挖掘风险的过程，并且希望把风险挖掘的过程实现自动化、智能化、流程化，以提高精准性和可追溯性。
二、更快解决问题。我们站在全局的角度，能够准确地、快捷地、全面地去掌握系统的运行全貌，以帮助运维人员快速地定位故障的根因。
三、更精准的运营决策。从海量的运维数据中能够精准地提取有效的信息，在这个基础上去提炼一些让管理层直接做决策的内容。
四、更智能的运维管控。我们能够将 AI 和机器学习与我们的运维管理、自动执行这些领域去做一些结合，全面地去提高运维管控的质量和效率。
这4个目标背后其实跟 AIOps 的理念是非常相符的，都是以场景为驱动。不同的应用场景以问题为导向，最终要实现这4个目标，都是以数据为基础的。
二、落地思路及平台框架
当具体去推进 AIOps 落地时，想要有效地把运维数据应用起来，还需要解决三方面问题：
第一、如何将分散割裂的运维数据资产化。当前的各类运维数据存在分散问题，我行 19 年做调研的时候，各类运维平台大概有三四十个，这些数据分散在不同的运维监控平台里面，运维数据分散缺乏集中的沉淀，缺少统一的指标体系，不利于做数据的整合分析。
第二、如何将低效、繁琐的分析过程简单化、高效化。有了数据之后做分析，传统的分析获取一般都是人工收集，手段也比较单一，数据价值没办法做到深入挖掘。
第三、如何将复杂、多变的分析应用场景化。怎样将对于数据的分析应用，真正让用户或者领导看到 AIOps 的价值。我觉得场景化落地是一个非常重要的事情，就是智能运维场景怎样去落地？
2.1 解决数据问题-运维数据集市
因此，我们构建了标准化、规范化的运维数据统一视图——运维数据集市。这个集市打通了我行所有底层非业务类的运维与运营平台，将所有跟运维有关的数据归拢到集市中统一存储，我们行的数据做了一个主题的划分，分为 6 类：
-
-
配置类，包括CMDB、应用层接口配置、系统间消费关系和数据文件的传输关系等。
-
监控告警类数据，这些数据包括性能、日志、指标。
-
-
运行日志类，主要是运行中产生的应用日志、系统日志。
-
我们基本上把六大类运营数据模型实现统一的入库管理，汇聚整合进行高效的共享。
在这个基础上我们引用了一些实时的、离线的处理技术，包括我行的大数据平台gbase，非结构化的数据存储引擎 ES 实现了将数据拿过来处理好存起来，拿过来之后还是一个相对比较原始的数据。参考业务大数平台的方式，把它分了三层进行建模。
缓冲层是对原始数据的落盘，这一层其实主要是把数据存下来，在这个基础上针对不同的领域，结合领域的特点构建了一些中间层模型。在这基础上，根据上层的一些场景需要去构建出应用层的模型。这个应用层模型是直接面向上层应用的，是为上层的算法分析、统计分析，提供一个标准化的数据服务。
通过这三层模型的构建，基本上把数据算沉淀下来，就在这个基础上，我们又构建了一个相当于运维领域的指标体系，那我们叫三运指标体系，包括运行指标主要是用来度量系统运行健康度的。像TPS 峰值响应时间，基本上可以跟传统的监控指标是类似的。
第二个运维指标，整体系统，比如变更的成功率，应急预案命中的次数，这也是运维类的一些指标。还有运营指标，平台本身的一些情况，比如监控有效性，操作成功率之类的度量。通过这三层的数据平台建设，后续能够做两个事。
第一，把运维数据的服务标准化了，运维数据的使用和消费流程现在都是线上化的。实现了运维数据的统一扎口。另外一个就是运维数据治理，现在业界可能也有一些标准在去描述它，但是实际上大家之前提到的可能更多的还是一些零散治理，主要是针对监控数据做建模。但对于整个运维数据来讲，它不只包含监控数据，那这些数据以前可能都是黑盒，现在通过运维数据集市，就有了做运维数据治理的抓手。因为数据都进来了，用户肯定是能看到、能用到的。通过以用促治，从需求出发去推动运维数据的治理，提高整体的数据质量。
2.2 提升分析效率-建设分析引擎
数据有了之后如何提高分析效率，我行基本采取两个手段。第一、工具赋能。构建了AI 的算法分析引擎以及 BI 的可视化分析引擎，AI 算法分析引擎主要是我们构建了线上的流程化算法开发框架，支持用户在线编排算法，使用运维集市的数据，包括组件库里内置的算法，也可以自己开发算法，在线的去迭代、管理、训练、发布，通过这个方式来实现算法分析场景快速的上线；
可视化其实就是为了让用户能够更自主、快捷地用到分析的结果，把结果快速地能够让大家自助地去展示出来。通过 AI 和 BI，我认为基本上能涵盖到运维数据的分析需求。
第二是“人”，智能运维的核心理解就是对于数据的应用，怎么将数据做好应用？光靠运维分析团队+开发团队是不够的，真正想让运维数据全流程地发挥价值必须得到用户的力量。要让广大的一二线的运维、开发能够快速、快捷地去用到这些数据做分析。
因此，我们推广分析活动的线上化，引入项目级的管理方式，支持用户在线提出问题。我们共同分析需求，支持用户申请运维分析项目，我们负责项目和数据的审批，他们负责数据的申请和成员的管理，自己来做在线的分析，以迭代运维分析场景。这种方式是一种生态化的运维数据应用建设，成功地实现了覆盖范围较广的个性化场景建设，在行内取得了良好的落地效果。
2.3 促进场景应用-构建场景生态
要发挥 AIOps 落地效果，需要场景应用。因此，在推进场景建设时，大概有三方面内容。
第一、针对运维共性的痛点与难点问题，我们将其分为三类场景：事前的运行风险分析、事中的定位类场景和事后的总结类的场景。这三类场景存在一些共性问题。我们为此打造了简单易用、有效的经典场景，这些场景用户开箱即用，无需像传统监控一样进行接入，因为我们跟监控平台后台打通的，通过经典场景的建设，我们能够有效解决共性问题。
第二、运维数据的分析千人千面，例如乙方到甲方企业，每天都有新需求出现，而且这些需求有可能随时都在变化。为了应对这种情况，我们采取了第二个层次——自助场景。用户可以基于集市及引擎去开展自助式、定制式的个性化分析场景建设。
我们有一个场景中心，用户创建的场景都可以推送至此。他可以在线制作自己的可视化看板并对场景进行算法分析。我们一两年内可能受理全行 300 多个场景，已落地 200 多个，涉及变更分析、监控分析等多个领域，这实际上是一项将数据赋能落在细处的举措。
第三，经典及自助场景能解决 90% 问题，但还有一些核心重要系统的场景比较复杂，面向的应用场景也很敏感，针对这种系统，行内成立了 SRE 的团队，我们会把运维分析的同事派驻到 SRE 团队并做一些定制的服务，针对他们的痛点给他们打造量体裁衣、定制化的场景，通过这种方式定向地去提升一些像分布式核心、手机银行面客系统的智能运维能力。通过这三类场景的推进，整体提升智能运维在全行的落地。
2.4 小结
回顾一下我行的智能化运维框架。首先通过建设智能运维集市、指标体系实现运维数据的沉淀与应用；通过搭建面向用户的 AI 算法引擎与 BI 可视化引擎，实现分析效能的最大化。通过典型场景、个性化场景及定制化场景，实现数据和算法在运维管理全生命周期的有效赋能。
三、实践案例分析
3.1 潜在风险挖掘
针对系统运行、业务波动和性能容量三类常见的生产风险，我们基于一些历史的运行指标对系统运行态势进行持续预测及建模。一旦出现偏离则进行风险提示，如同类告警多次发生和业务波动等。
此外，我们也需关注交易量的突变和响应时间的上升等业务风险，通过分析单交易前后时间指标变化早期发现风险并进行规避处理。对于性能容量类风险也要及时检测，如磁盘数据空间的增长速度大于清理速度等，通过挖掘离群点，及时发掘潜在风险，以从容地进行处置。
总结：针对不同类型风险，我们用不同的算法去构建一个定制的模型去挖掘风险。
我们意识到数据分析类应用在实际使用中存在的问题，我们的分析结果缺乏一个流程驱动其更被有效的应用。因此，我们将风险管理与流程管理平台贯通，实现了以下三个流程优化：
首先是评估优化流程，每个风险识别结果都有受理人负责反馈有效或无效的风险，并帮助算法人员改进识别策略。
其次是风险挖掘结果。对于业务波动等关键风险，我们将其与监控平台对接，输出告警通知并实时处理。
最后是对于一些不需要实时处理，但后续需要系统优化改造的，我们将其与ITIL问题管理流程对接。
通过优化以上三个流程，我们实现了整体风险分析的可追溯性，全流程优化有助于推进系统运行稳定性的提升。这是我们当前重点关注的场景。
3.2 全景智能洞察
全景智能洞察主要解决应急处置过程中的一些问题。处置过程有几个问题，一是信息获取不及时，条线信息割裂。
二是数据量很大，尤其是基础设施上的监控指标比较多，如果全是人工去判断工作量比较大。最后一个就是增益性问题，即能不能把这个根因给推荐出来。主要解决这三方面问题。
通过打造一个全方位立体化的洞察视图，将横向到关联系统、纵向到拓扑结构的信息、性能指标、告警、链路日志包括运维活动信息汇聚在一张图中，通过时间线的形式进行摆布，运维人员对各个指标的健康情况可以一目了然，帮助他们快速地去实现信息获取。
同时，采取相关性算法和指标分类，降低指标数量并提升准确度。这是我们在这方面做的小优化。
根因定位主要通过实时评估系统健康度，自动触发专家诊断的流程和智能的 AI 分析，我们总结了历史上导致生产故障的三大根因：基础资源故障、关联系统故障和运维变更故障，通过这三类根因模型的构建，最终打造一个整体的检测模型，当真正出问题的时候，自启动两个模型，将结果按一定概率给运维人员进行输出推荐。
3.3 系统运营画像
系统运营画像类似于用户画像的概念，属于事后的场景。通过对系统打上各种标签及自动化分析，实现精准锁定运维对象的目的。如对资源利用率的分析，通过建立规则，并将其转化为标签，帮助管理层精准锁定运维对象，推动整体运营的转变。
四、未来方向展望
第一、重视智能运维体系化建设。传统的智能运维如果完全仅依靠单场景定制无法发挥完整作用，因此，我们更加注重智能运维体系化建设，通过运维数据平台和集市提供数据运维和算法服务的能力，进而实现场景化建设和输出。此举不仅服务于用户，也可应用于其他管理类系统和监控系统。
第二、从被动响应式到主动预防发展。我认为这也是我们后续要坚持做的一个方向，就是在关注故障告警、异常检测传统场景的同时，开始关注故障预测、风险发现等事前场景。
第三、多领域的深化赋能。这方面我们也在做变更风险评估，包括安全接口的管控，这也是落地 AIOps 能力实际在做的一些场景，后续除了传统的质量类、效率类场景 AIOPS 为运维管理赋能，为安全管控赋能。
第四、可观测、可解释性需求的加强。如果晚上收到算法产生的预警，他可能会感到困惑，这是因为解释性不够强。为了进一步提高运维人员对 AI 决策的理解，我们需要通过数据的展示或描述上易读来增强可解释性。
我的介绍就到这，谢谢大家。
作者简介：
耿鹏，中国农业银行研发中心资深专员
本文根据演讲者在 GOPS 2023·深圳站演讲整理而成，如有图文不妥，请以视频为准。更多精彩，请关注高效运维公众号。
6月29日，DOIS DevOps 国际峰会 2023 · 北京站，农业银行研发中心副总经理蔡仕志先生将带来重磅演讲，敬请期待~
近期好文：
“高效运维”公众号诚邀广大技术人员投稿
投稿邮箱：jiachen@greatops.net，或添加联系人微信：greatops1118。
发表评论