AIOps 助力航信运维百万级交易系统 0 宕机

Posted 2021-04-24 高效运维

分享：罗皓
编辑：白凡

讲师简介

罗皓

中航信运行中心 首席架构师

我们很多时候把合适的算法放入合适场景里使用，有的算法很成熟，关键是要解决问题，我们说实用主义的 AIOps，首先它一定以解决问题为目标的。

其次，AIOps，运维非常广的领域，今天时间有限，我们更多分享在可用性保障，也就是我们 0 宕机运维方面做的工作，我们 AIOps 所涉及不是很深，有什么疑问和错的地方一起探讨。

今天分五个部分：

• 我们业务特点，我们遇到哪些问题

• 非规范化架构

• 故障预测与识别问题

• 故障快速解决问题

• 我们对AIOps的理解

1. 中国航信的业务特点

首先讲一下中航信，中航信大家可能不是特别熟悉，它是什么样公司呢？大家只要坐国内航空公司飞机，无论坐哪个航空公司飞机，最后都是中航信系统为您服务，买票、离港。

比如我们做别的领域易行天下，卖汽车票，买二三十个省的汽车票，国内唯一航空旅行信息提供商，什么规模呢？不太好理解，跟业界沟通比较多，大概的交易量和四大国有银行中一个，四大国有银行同一个量级，稍微小一点，50% 体量规模的系统。

说到行情系统，毕竟国家级系统，民航售票很复杂，跟买轮椅一样，买多个座位，一个人多个座是可以的，航线系统比较复杂。这是我们一个BU的业务系统的片段，大概它的五分之一片段吧。

1. 这里面每一个点一个业务系统，哪一个线它的连接关系我们抓出来的。每一点展开之后一个架构，这里面看到类型比较多，相对来说比较大的集群，也有结构比较复杂，每个集群规模比较小的情况。

2. 可能中航信业务系统和刚才分享互联网化业务系统不太一样，它的结构可能更加复杂，而且它的小集群比较多。

3. 还有一个比较大的问题，中航信历史包袱比较多。其实大家知道全国机票销售是从上个世纪 80 年代电子化，中国全世界做机票电子化最好国家，中国全世界第一个实现机票无纸化国家，我们开放是 18 年以前，我们有很多历史包袱的业务系统。

其实我们欣赏互联网公司这样，我们把很多微服务化掉，我们新的业务系统也是这么做的，我们有很多十年、十五年以上的业务系统，今天做这些业务系统改造不太可能。摆在我们面前更多的，我们分享更多怎么解决这样的业务系统问题，这些点后面会涉及。

我们业务系统最大的问题，它的要求真的比较高。可能别的公司问题是钱的问题，我们出问题不是钱的问题。早上 6点到 9点，大家去首都机场或者上海浦东，大家想下人的状态。如果10分钟不能离港和通过安检什么情况，不是舆情问题，会发生动乱和群体事件。对于我们来说，我们对内是按零评级，这是我们要求，这里面不是经济问题。

我们觉得有这样几个问题需要解决。

• 第一，我们的包袱很重。其中有我们的架构不规范问题，比如我们的集群好用稳定，于是业务都要上集群，甚至其他资源也是集群，应用程序可能写着写着出现很多稀奇古怪的事情。它会出现不合理上下游，比如这个系统依赖不是那么重要业务系统，最后出问题一起完蛋了，这是第一个架构不规范问题。

• 第二个，刚才大家讲很多故障预测识别问题，不能接受中断，尽可能故障没有发生，故障没有业务之前发现故障，这里面故障预测的问题.

• 第三个，还有异常识别问题，做预先监控点，导致监控点非常多，这样可能做事件压缩的问题，最后一旦发生故障快速恢复，我们今天就这三个方面分享工作。

2. AIOps vs 非规范化架构

2.1 架构图现状

大家会画这样一张图，集群的图，一般都是这样。这张图并没有什么作用，通过这张图想说明这样几个问题。

• 第一，这个系统是否存在单点。

• 第二，这个系统是否存在非对称集群，看起来是一个集群，实际上不是。

大家说这个事情怎么可能发生，真有可能发生，不好说哪个业务，比较重要的业务，这业务集群里面很多节点。

一开始是没有问题，但是随着这个业务的迭代，它出现了一个需求，这个需求需要更新一个全局配置，这个全局配置更新需要一致性的保证。

写这个代码的同志，新同志出于代码比较好写角度，没有意识更新配置动作非实时动作，这个机器能更新配置，其他不能更新，不存在一致性问题，正常上线走过的，有一天正好那个机器坏了，我们考虑集群节点非常多，无所谓，把它排在后面，碰巧这个触发导致了问题。

我们是运维人员，很多时候不太能够完全控制代码，测试比较多，分布式里面发生，北京有研发中心，重庆、成都、东北等等都有研发中心，保证代码的质量比较困难，这个东西能够识别出来。

• 第三个，是否存在不合理的依赖。更重要的问题，这个架构是这样的吗，画过架构图，这样的企业一般画这样的架构图，能保证十年之后或者五年之后架构图和文档还是一样吗，这个挺难，我觉得一般不太可能。

  我们当时想到什么，通过自动发现方式想到这个方式，这是第一个版本。这个图看起来很绕，连接关系能够出来，其实并没有什么用，谁和谁一伙，谁和谁集群，谁和谁依赖，不知道。

  我们希望这样一个架构图，这个架构图是这样，谁和谁一个集群，并且这个在集群里面什么角色，每个集群和集群之间，或者他们之间什么依赖关系，这样我可以保证架构变化能够比较清晰地掌握，信息基本上不要丢失，这是我们所追求的目标。

2.2 配置管理

当时我们在想首选解决问题，不是 AIOps，是做好配置管理。第一个动作，我们当时做的云平台，把我们所有的配置资源交付自动化了，我们实现配置变革百分之百自动化，全都自动化。

它不可能记住特别多信息，我们上了配置自动发现工具，去把一般配置里面做不了，G2E集群里面连接池和数据库依赖关系，应用是连接池关系都自动识别出来了，做到这一步发现还有三个问题解决不了。

• 无论自动化配置更新，强调配置的自动发现都只能解决已有IT组件问题。前段时间推新的应用大量使用这个，这个没在我们里面，这个抓瞎看不到了。

• 即使已有IT组件，有些配置也是很难识别。比如C++对数据库依赖，中航信一般用C++系统，可能就比较困难了。

• 这个时候怎么判断依赖关系，做不了。

我们想能否通过AIOps方式解决这个问题，具体做法相对来说比较简单了，大概这么一个过程：

• 我们在服务器里面有各种信息，能干什么信息就干什么信息，每一个进程名称和端口状态，每一个进程和端口对应关系，这个服务器连接哪些服务器信息。

• 数据清洗和格式化

• 肯定做降维和标准化，每一个进程的信息加起来及秒钟以上，这样去做好标准化。

• 后面详细讲怎么做集群分析，大家用了数据分析方法。

• 再往下之后做架构标准，你用数学方法出来东西，这个1是什么东西，这个2是什么东西

• 非规范架构识别。这个机器永远不可能告诉你，这时候要标注，出了什么框不知道不行。

2.3 集群分析

集群分析我们怎么做的，我们一座一个数据建模，把特征都找到，这个根据业务情况来看，我们基本上把所有的端口和连接关系取到，还有其他关系大家自己感觉，这一行是一台服务器。

有这个进程，你标注1，没有这个进程标注0，把进程数量放进来，有3个是3，有1个是1，大家自己去感觉。

很简单的做一个降维标准化，我们分出这么一个东西，第一步是这样，这些就出来的。之后可能还是不够，这些都是静态信息，这个服务器起什么进程，这个服务器起什么端口都是静态。

这是我们一个集群CPU负载变化情况，这里面明显看出分四类。

最上面完全不动是一类，有小幅波动是一类，下面有大幅波动，很容易识别四类分析方法，大家也可以用别的相关系数，大家自己选择不同的算法。

如果用相关分析有一个问题解决不了，这样的，大家去用就知道的，如果没有相关分析，都一样，其实差不多，它如果出现了这种情况的话，它告诉你这两个指标完全一样，因为主要考虑波形，不考虑绝对值，这时候考虑绝对值差异问题，这方面比较简单，我们刚才用了一个变体，自己写了一下，我们通过这些步骤把我们的每个服务器静态和动态信息都用来把它进行分群，分出来之后可能一个多级，1.1这么一个东西。然后开始标注，这时候做CMDB特别重要。

标注如果全靠人肯定没戏，举一个相对比较小规模的BU，服务器不会特别多，1500台服务器，最后放多少群，放100群。大家想一想我们1万服务器BU放多少群，如果靠人来标注就完蛋了。

尽可能自动化标注，我们怎么自动化标注，CMDB就很有用，CMDB做得越精确化，通过这种方式分析出来集群和CMDB接口集群对上就标注上了，这时候处理没有标注的特征，这个东西没有办法，只能靠人，把人的部分标注上，反向把特征注入了集群类别特征库里面，最后很容易计算出依赖关系，大概这么一个过程。

我们刚刚上这个平台时候效果非常好，不能说识别率百分之作用，我们上完之后确实识别到很多问题，包括集群不对称问题，或者异常依赖问题。

而且更重要的是让我们很快扩展运维边界，中航信这几年慢慢向互联网靠，我们慢慢引入双模式，我们一般这么一个过程，一个业务，特别互联网化业务，上来之后让它走敏捷模式，这个时候运维不管，派人员指导，它会自己迭代。

迭代业务比较稳定时候，把这个业务移交给我们，我们再承接。以前移交特别复杂，对配置和集群是否符合我们要求。

而现在基本上一天把数抓起来，要采它的数据，一开始没有探针，抓一些数据晚上一分析，第二天基本上出结果。我们识别有特征标注集群就过了，剩下时间都是标注没识别出来，大家说不出来怎么回事，大家一个个解答怎么回事。

这是一个比较小的，有一千个节点的东西，基本上三天把这个交付完成，问题限期整改就结束的，这是我们做的具体工作。

3. AIOps vs 故障预测与识别

3.1 故障预测

首先讲一下故障预测，有没有可能提前发现故障这种事情。一开始不太可能，大家知道有一个工具磁盘医生，它磁盘发生问题之前有异常曲线，发生的时候把这个和磁盘故障结合起来，硬盘也是一个设备，有没有可能把这种方式放在我们设备的故障预测里面去，过程不用说了，采集数据等等。

大家知道磁盘故障率很高，很容易凑齐足够多负样本，我们设备负样本不是那么多，希望对称情况。

没有负样本情况下怎么构造负样本，这是一个问题。还有不停地修正模型问题，方法都很成熟，各种方式大家都可以试一试，这个也没什么特别的，我不多说了。

最后，你有了预测，现在怎么整合是一个问题。我们网络设备上面去做了这个工作，我们50%网络设备做了工作，这个预测准确率还可以，85%这种情况，我觉得可以大家一起分享一下，开开脑洞。

这里面主要两个问题，刚才说的负样本过少问题，方法很简单，这种样子是负样本，这个是正样本，这个非常简单，两个负样本中间取一个直线，取一个随机数，随机数这个位置再声称一个值，这也是负样本。

为什么讲得不是特别绝对，一开始非常怀疑人工造负样本很怀疑，不能说这个方式非常好，只能说在这个场景上面用这个方法确实能解决问题，没有过多影响准确率。如果我不这么做这个方法就失败了，有方法之后效果比我预期要强。

第二个方式，考虑设备不一致性，这是我们跟硬盘医生步态一样地方，硬盘本身非常标准化设备，可能批次、供应商、型号对它以后的模型没有什么太高要求。

但是我们发现设备厂商批次、型号，以及它在网络拓扑中位置情况，一开始这个没有收敛，这个时候大家需要一些方法标注设备的异常，大家想方法很多，刚才说的厂商、批次，包括型号来标注，还有一个很重要问题，怎么标注它在网络拓扑中位置，这个大家要想办法，对网络拓扑做一个定义，总是要做一些标注。

标注之后，整个结果非常好，收敛了，这是我们在设备预测的时候和一般的磁盘预测时候区别，在这个地方有一些区别。

3.2 异常识别

我取了一张特别丑的图。中航信做一张图，受限于我们的压力，这个2012年自动基线方式，大家看得出来按小时来切分。我们为什么用这张图呢？回到刚才的问题，我们是否一定做得很好才用AIOps，不是的。我非常认同数据资产一定非常重要，一定数据积累到一定程度时候，我们AIOps才有意思。

但是这个度在这儿，还是在这儿呢？如果在这儿，可能对于很多企业来说都别做了。我们问题是说就在这儿，我们只有这么多数据怎么办，不是说不做了，很多地方还是可以做。

也许做出来比较丑，但是丑陋和有效并不矛盾，关键是解决问题。当时我们的办法非常简单，我的数据量不够，七天数据，还是多少天数据，我们两分钟采一个点，怎么办？我把统计中心拉宽，一小时做一个统计，划边界很简单，我不想多说了。想通过这个例子，这个AIOps真不是高度可攀，有什么材料做什么菜。如果等着材料成熟时候，可能菜凉了或者不需要这个菜了。

如果今天在说的时候有什么经验可以分享，前面的方法周老师讲了很多不赘述了，两个经验可以一起讨论。

第一，先将数据分分类。比如这是我们某一个服务器一周变化曲线，这是网络流入情况变化曲线，基本表现出两个模式。

如果把七天放一张图里面很明显看出来两个曲线，如果我们基于这两个曲线来做动态基线或者异常识别效果很差，可能收敛起来麻烦，要么幅度放得很宽。但是先分类变成两根曲线，这个就很简单了，非常容易得出比较好的结论。

现实生活中这个事很多，这个列举工作日和非工作日，再比如大小长假以后，小长假和小长假以后。这个系统很标准做法，当时和BAT某个公司做交流，他们分出50多个类，我们分不出就分出20个类，他们有618、双十一，在我们这儿没有。

我们想说有时候分类影响因素是多方面，它不是单一方面。因为我们很有可能有这样一个业务，这个东西没什么业务量，它就是长期在百分之百，这也是一类分类方法，大家把它剔除，不一定是一样的，分好类之后看到降低很多。

第二个，看扩展波形的比较范围，我们只有两天数据能否做动态基线？也可以做，这是一个集群，这个集群12台服务器，它一天负载情况，这个几乎就是一模一样的，我们把数据放在一起异常识别，这样很有可能数据量倍增了，变成10倍、20倍，这样可能整个效果好很多。前面的问题，那里的集群里面角色不同，别把一个集群都丢进去，先把集群内部分类，否则效果适得其反，这是异常识别方面。

3.3 事件压缩

首先讲中航信处理模型，下面和大家差不多，有一堆监控点，网络流量监控、用户体验监控等等，这些监控产生很多事件，我们有个事件平台，我们自己开发的，事件平台负责压缩和过滤，丰富压缩和过滤规则绑在一起，它是哪个集群、业务，这些都是绑在一起，这样进来耕作进行压缩和分析，这是我们故障处理模型。

基于这个模型，我们分析的运维场景，什么时候我们特别需要事件压缩，分析完之后两类场景特别需要。

第一类，发生大面积故障时候故障快速定位，可能一个核心网络发生故障，这个时候最多出现服务器IP不通报警，或者服务器丢包报警，一条报警淹没无数服务器不通报警里面了。一般的做法设定报警级别，OK，没问题，可以报警定特别高级别。

但是运维团队分散，我们现在就是运维团队分散，他们可能都有自己识别，我们混在一起，所有BU在一起监控。这时候大家定出最高级别时候，一旦报警，最高级别报警也很多，在这种情况下我们怎么样迅速地找到这种真正的根源，这是一个问题。

第二个，一个月恨不得报两三百次、四五百次要干掉和压缩掉。我们事件压缩时候最多是这两类场景，针对这两类场景不用AIOps。这两类场景事件很小，当然值得花人，投人把这个事情摆平。

如果用特别复杂的规则，可能对规则引擎压力很大，它可能支持非常复杂的规则。

我们做法非常简单，我们事件管理系统旁挂一个事件特殊处理系统，这个系统里面可以任意编写规则，它是程序，任意编写事件压缩处理规则，任何事件这儿过一下。在这里面可以把规则特别复杂，但是数量很少的，人值得识别出来的故障都解决掉。

剩下的呢？事件压缩系统标准规则引擎，市面上有产品解决这个，我们是自己开发来解决。这些规则引擎规则怎么生成，这是一个标准做法，做AIOps这个事比较清楚了，过程简单说一下。

我开始这么一条条实践，把它按照时间的维度进行切片变成像订单一样东西，最后计算出这三个事件老是一起出现，它们存在被压缩可能，得出这样一个东西，这是很标准化做法，没有任何区别，这个不用说。

重要在后面两个做了一些工作，怎么看待这个，以及怎么这个结果发生对我更有用信息。

第一个，大家一定要处理的，频繁项集的子集，这个事件一共出现50次，前面5个时间一起同时出现66次，这两个OK，但是看这条，这个事件也是一直出现，它也频繁一直出现66次，这条事件没有意义。因为这5个事件频繁出现66次，意味着里面任何四个事件组合或者三个时间组合至少频繁出现66次。有了这条之后，后面子集没有意义，这个要剔掉，这个比较简单。

第二个频繁项集有支持度，一万条记录出现五千条，这是50%，没问题，可以认为授信了。大家可以看这条，这个事件出现142次，这个在统计周期里面共同出现142次，第一条事件统计周期里面出现1967次，第二条事件出现1960次，第三条出现1735次，它出现没有太大意义。

第二条一起出现52，有50次是一样，这个方向可能不一样。第三个，更明显了，它一共两个事件出现168次，他们总共只出现172次，要么没出现，一出现就是同时出现，这种方式又不一样，所以不同的结果导致我们最后写压缩规则不一样。

这个没什么好说的，第一个算法很差，不用。第二个算法、第三个算法，第三个算法处理性能好一点。

这两个算法在处理支持度很低的场景时候都不太行，它结果特别多。一个报警整个周期出现50%或者60%，这个报警本身就有问题。

我们真正挖掘出有用规则时候，这个几乎都在1%以下，我们当时用这个频繁项集处理事件，第一条是3%，大量出现有意义时候，1%以下的时候真正开始大量出现规则。

这时候怎么样尽可能降低这个支持度，当时我们想了一些办法，可能先出来的结果集，那些比较明显的数据从里面剔掉，再来进行一次分析，这样把支持度从千分之七降到千分之六点五，就是这万分之五可以多出一倍规则，我认为这个很有意义和价值。没有更新算法本身，理解算法细节，我们自己工作就可以了。

4. AIOps vs 故障快速解决

我们很多故障要处理，很多应用导致，不是基础架构导致，我躲不了，不能赶工期，也赶不出来。

我们没有深奥方法，就是做一个故障处理系统，人按照比例看一看前80%报警哪些故障产生，把这些故障自动化掉，做了一个处理系统，这个细节不用说了，效果非常好。

上的这个系统之后，76%的故障，我们逐步的，现在76故障这样处理，没有什么，二八原则，很多东西人可以识别出来，所以这样就能够把规则总结出来，就能起到机器代替人的作用。

这个根因分析大家讲了很多，不多说了。可以简单说一下，我们在做，不知道能否成功，我们把根因分析下面这个东西，把根因分析和这个结合起来，根因分析容易拿到负样本，通过这个可以造出很多负样本帮助我分析，这个在实验，下次跟大家一起分享。

5. 我们对AIOps的理解

其实我们非常认同，今天在运维角度是第一步，我们还是加强管理，今天上午讲百分之七八十故障是这个。

第二，确实很多故障应用导致，应用持续优化，这些都非常重要。

第三个，这是应用改造，我们没有招时候，这些招没有效时候，这时候AIOps非常好选择。它现在虽然不成熟，但是潜力很大，确实一些点上取得很好效果，我们觉得大家一起关注，但是目前处于辅助的地位。不要因为AIOps可以包打天下，目前至少不太可能的。

架构方面，相对来说我们标准化的做法，这个不用多说什么，周老师讲很多，我们用这张图，它差不多，上面一堆数据，通过数据采集东西换过来，这边数据仓库。上面有些分析模型、分析平台，这边分析的框架，这个地方讲两个点，大家刚才没有提到的，我认为比较重要。

我们的AIOps之道。第一，大家关注数据虚拟化，移动数据很费劲，它是很难。我们很多时候在做AIOps需要探索性统计分析，这个时候不太好这么做，我们数据分散各种地方，可能再做这个事半年以后见了。

这个东西并不复杂，很多产品可以做。我们第一版本是这个，它有一个特别网关，把所有这种数据库在一起做。

它的问题，性能比较差，没问题，我主要做探索型统计分析，我可以做方法探索，取得半天、一天数据看好不好，简单跑一跑，这样可以极大的降低AIOps成本。

第二，我们觉得AIOps不是单独团队做的事情，如果做得比较大是有专门的团队，运维团队、运维开发团队。

我们遇到了一个问题，数据科学家不太能够理解运维的场景，或者不能够理解业务的场景，而理解业务场景的人，觉得要去学习AI这个东西太难了，我们形成自助或者全员研究AIOps的机制。

我们做法尽可能让大家信息安全可以保证的情况下都能够拿到尽可能多的数据，因为数据绝对不是一加一等于二的概念，是一加一等于十或者大于十的概念，相信做数据都很明白。

这种情况下我们尽可能想到数据不同团队里面分享起来，谁都可以用这些数据，谁都可以基于这些数据提自己AI想法，这样我们可以比较快形成一些比较简单，但是很有用的解决方案。

最后我想说 AIOps 并不是高不可攀，这些方法没有一个是2005年以后出来，我们也用了很多新方法，没有举例，都是成熟的方法，基本上受过训练的人都是没有问题，我们先把它用起来，确实不要给予它过高期望，早点慢慢来。

说明：以上为中航信运行中心首席架构师罗皓在 GOPS 2018 · 上海站的演讲。