机器学习在运维自动化中的作用与局限性

最近一直在研究如何才能让运维自动化系统更好的为传统行业复杂的系统运维服务。可能有些网友会说互联网公司的IT系统才叫复杂，传统行业的系统不外乎应用服务器、数据库，总的来说还是相当简单的。确实，在架构上，互联网应用更为复杂，不过由于互联网应用的复杂的架构，已经将系统充分解耦，每个组件的复杂度反而下降了，再加上IT基础设施与应用之间配合十分密切，其运维自动化程度很高，运维难度也下降了。互联网应用在运维上更加注重于组件个体与整个应用系统，一旦某个组件故障，影响了应用系统，只需要针对整个组件进行处置就可以了。而传统应用由于耦合度太高，也缺乏全链路的监控能力，因此一旦出现问题，问题定位与故障溯源都十分困难。

春节前一个银行客户打电话给老白，说是他们的核心账务系统最近一段时间总是出现内存耗尽，系统宕掉的情况，重启数据库后很快内存就又出现报警了，再用一两天，内存就再次耗尽。如此往复了一个多月，负责维保的厂商还是没找到问题的原因，怀疑哪里出现了内存泄露。这套系统是跑在一台IBM小型机上的，操作系统是AIX 6.1，有128G内存，SGA设置了56GB。一开始我就想到是不是MAXPERM%的设置问题，于是让他们检查了一下vmstat -v，发现maxperm%虽然设置了90%，但是numperm%不高，只有5%左右。于是让他们做了个svmon分析，通过svmon一分析就发现问题了，系统配置了60GB的LARGE PAGE，但是因为在ORACLE用户上没有做相应的权限设置，LARGE PAGE并未被使用。于是乎，一台128G内存的服务器，就变成了一台72GB的服务器了。这似乎是一个十分简单的问题，运维厂商的DBA也发现了系统启动后内存逐渐耗尽的问题，但是任由系统每隔一两天宕机一次，也是无法解决这个问题。老白与那位现场的运维人员，差距就是对AIX内存分析的经验的差距而已。

传统行业的系统是高度耦合的复杂系统，简单的自动化平台是无法处置一些复杂的场景的。不过我们传统行业的运维自动化系统反而是以网管思路为基础的，大体分为指标采集、基线告警、操作处置、配置管理几大类。把网管采集的数据通过简单的基线比对进行告警，并通过事件管理、问题管理、配置管理、可用性管理、容量管理等流程与日常运维工作进行贯通。这种模式从管理上是没问题的，不过里面有一个地方比较薄弱，那就是分析诊断与预警能力。

我们建立运维自动化系统的初衷不错，就是通过监控发现疑点，然后对有问题的地方通过ITIL的流程进行管理，做到闭环管理。不过我们遇到的问题是，我们如何能够抓住系统中存在的问题，如何进行精准的报警？如果我们只是判断一个系统是否能够使用或者是否活着，这种管理模式也许能起作用，如果我们想做到故障隐患的发现与提前处置，仅仅采用指标与基线预警的方式就是痴人说梦了。

我和一个企业的数据中心主管做过交流，他们的数据中心里有3000多个数据库实例，上千套系统，几万台服务器。光每天的数据库日志报警就有好几千条，加上基线告警是上万的。而DBA只有十来个人，还要负责日常的新系统建设，扩容，升级等工程类的工作。这些人如何去对这上万条告警信息进行闭环管理呢？恐怕手机接短信用不了半天就把电耗光了。

实际上要想解决这个问题，还需要更为有效的工作方法。处置系统问题最主要的依据还是经验。拿上面那个例子为例，老白是根据经验很快就定位了问题，如果换一个对AIX系统不熟的DBA，哪怕数据库水平很高，也可能无法很快定位问题的。因此，我们今天讨论的话题是机器学习能否对运维自动化有所帮助，重点讨论的是传统行业运维中两个重要的内容：模型与运维知识。运维知识我们接触的很多，目前我们手头的预案、红宝书、METALINK网站等，都是运维知识，模型就接触的比较少了，因此老白今天首先和大家讨论运维中的模型，比如健康模型、性能模型等。模型就是通过一系列的指标和基线数据，为系统建立一个科学的评估体系，用直观的分数来描述模型，描述系统的状态。一旦模型中的分数发生变化，或者分数的某个维度发生变化，就说明系统的状态发生了变化，运维人员就可以从这些变化中得到警示，从而发现问题。

由于系统越来越复杂，系统运行指标数量过于庞大，因此针对指标进行分析的难度越来越大，有时候系统出了问题，我们很难通过某些指标很快的进行定位。而很多指标的分析依靠资深的，经验丰富的运维人员，而这些人往往很少能够在一线运维岗位上配备。另外一方面，不同的系统出现问题的现象各不相同，即使是同一个指标，在不同的系统中，也会有较大的差异，因此一些以往的经验直接搬到现场生产环境中也十分困难。这些年十分热的机器学习给了我们新的启发，它为我们打开了一扇大门，通过机器学习，我们能否建立一种新的专家系统，替代传统的专家系统。于是我们开始了这方面的尝试，通过采集生产系统的数据，进行特征提取，构建训练模型，最终建立分类与预测模型。

在这里，我们给大家分享一个研究案例的成果，通过在50套生产系统中进行数据采样，我们收集了8个月的系统运行数据，通过特种抽取，最终采用了15维负载数据与26维性能数据作为训练模型的基础。

由于训练模型需要监督学习，而监督学习需要专家标引数据，工作量十分巨大，要想采集到足够的因此我们使用我们自己的D-SMART大师问诊系统对这些数据进行打分。D-SMART里有基于专家模型的性能与负载打分功能，同时将D-SMART发现的系统隐患也根据时间戳与基础数据做拟合。通过专家模型直接打分来替代专家人工标注数据，可以节约大量的数据预处理的时间。我们的目标是输入采集的数据，以及D-SMART的打分数据，进行监督学习，用80%的采样数据作为训练集，最终训练出可以自动打分的AI模型。然后用这个模型对20%的的数据进行验证，对比AI模型的打分准确率，选择最好的分析算法。

我们采样的数据f1-fn和D-SMART的打分结果y作为模型的输入，进行训练，最终输出模型：

上面是实验的结果，方差最小的，拟合优度可决系数越接近1的，就是最好的方法，可以看出多层感知机在这三种算法中具有最好的效果。在预测得分时，通过20%的采样进行校验时，发现打分误差在正负4分之间。通过分析，我们发现MLP具有最好的性能。

而针对数据库得分的A/B/C/D四类预测中，回看23个样本预测未来一小时的数据库运行状态，经过500轮训练后，模型预测的准确率达到87.2%。

通过前面的实验案例，让我们眼前一亮，通过训练模型，可以较为准确的给系统打分，通过打分，我们可以预测一个小时后，甚至多个小时后的系统状态，一旦这样的模型建立起来，可以大大提高我们的运维水平。随着后来模型的继续优化，预测准确率的数字也在提高，最终提高到接近95%的水平。这是一个十分令人兴奋的数据。有了这么好的实验基础，未来就一定是这么美好吗？在2018年到2019年这段时间，我们把这个研究成果在我们的客户那里进行了广泛的测试，令人失望的。令人兴奋的是，在分类等简单的领域内，机器学习表现出了十分好的性能，帮助我们解决了一些以往无法解决的问题。但是在健康预测领域，我们遇到了无法逾越的困难。虽然预测模型真的能够在某些场景中成功预测数据库系统未来的风险。但是有一个致命的问题也暴露了出来，如果我们的训练集中从来都没有出现过某个故障，那么这个故障被机器模型预测出来的可能性极低，甚至我们在一年多的时间里没有发现一例成功案例。这个结果也是可以理解的，深度学习只是通过数学的方法去进行计算，当某个变量从来都没有出现在我们的运算集里的时候，指望这个变量去发挥作用就不太现实了。

这个问题虽然令人沮丧，但是我们利用专家模型训练机器模型的方法依然被证明是有效的。随着系统运行时间的增加，当某个故障第一次出现时虽然不能被预测，但是随着我们把这些数据标注后加入到训练集中，那么今后这个维妮塔再次重现的时候就可以被发现了。同样，如果我们在某些地方建立的训练集，在一些类似的系统中，仍然是可以发挥作用的。因此这个方向虽然我们遇到了暂时的失败，但是后续的工作仍在进行，目前INTEL的一个技术团队正在和我们进行联合攻关，希望在这方面能有所突破。除了状态预测，机器学习和深度学习中的一些分类算法对于发现系统中的一些共性问题作用十分明显。比如我们用分类模型对使用同一台存储的50多个数据库的IO性能指标进行了分类，发现了几个十分有趣的时段，在这个时段里，大多数的数据库系统的写IO指标都是异常的。于是我们分析了这些时段的存储的监控指标，发现这些时段存储系统的写CACHE的水位都十分高，而且存储的风扇转速也都处于中高档位。最后经过分析，发现这个存储上的数据库的备份作业都是复制过来的，做全备份和归档日志的备份的时间完全相同。后来通过修改备份作业的时间，把备份时间错开，这个困扰了多年的IO性能问题终于得到了彻底的解决。

另外我们通过ADF算法也成功的帮助我们定位了一个一个存储虚拟化环境中的IO性能不稳定的问题。当虚拟化机头的写CACHE回写到下端存储中的时候，存储的写IO性能会急剧下降。此时对一些IO敏感的应用影响较大。有了这个发现后，我们就让用户把写IO敏感的数据迁移到其他的存储上以避免存储虚拟化的副作用对系统造成严重影响。

现在大家都在谈AIOPS，但是实际上AIOPS的时代远没有到来，专家智能的水平还远远高于深度学习的能力。
不过在一些轻量级的领域，机器学习和深度学习确实能够带来一些我们的专家能力无法覆盖的领域的突破。
基于广泛数据的关联性分析方面，机器学习的效率要比专家高得多，如果我们能够把信息系统各个环节
的数据有效的采集起来进行分析，并把分析中发现的疑点推送给专家，由专家最终判断结果，这样可以大大的提高运维自动化分析的能力。
目前我们在IT健康管理中所说的智能分析机器人就是这类东西。