智能运维中的异常检测与故障收敛

智能运维中的异常检测与故障收敛

现在做AIOPS的公司大多数都在异常检测上下足了功夫，其核心的技术平台和算法也大多是以异常检测为主。确实发现系统中存在的异常或者潜在隐患是每个IT运维部门都十分急迫需要的技能，而传统的运维自动化工具在这方面的能力较弱，很难解决相对复杂的问题。AIOPS能够解决传统运维中解决不了的一些问题，这是目前所有做AIOPS的企业所宣称的，也是大多数用户的IT主管领导所认知的事情。事实上也确实如此，其实运维专家在做问题分析的时候，其水平高低也区分于他是否能够综合评估各种数据，是否能够根据其经验来对这些数据进行分析，从中找出疑点，并证明疑点与问题现象之间的关联关系。

AIOPS事实上是在完成人类专家用人脑完成的各种计算与分析，不过其方法与人类的脑力活动不同，AIOPS的推理能力远远不如人类，但是其数学运算能力远远高于人类。因此AIOPS在数据处理上的优势如果能够得到充分的发挥，那么确实可以弥补人类在算力上的不足。

异常检测的目的是在纷繁的数据中发现其中不符合常规的地方，大多数的异常检测算法会认为IT系统在95%以上甚至99%以上的状态是正常的，因此找到那1-5%的与其他不同的时间，并把它筛选出来，那么我们就可以完成异常检测了。这种方法可以把需要逻辑推理的问题巧妙地转换为一个数学计算问题，大大简化了这个工作。对于一些十分严重地故障问题，这种方法是有效地，这种故障出现地概率可能低于1%，这个可以从我们的一些核心系统要求的可用率上可以看出来，大多数企业都会要求自己的核心系统的可用率不低于99.99%，也就是四个九，银行证券等行业甚至要求自己的系统的可用率达到五个九。因此1%的筛选因子不一定对所有的场景有效，确定这个因子也是有学问的，这也是区分目前的AIOPS算法能力的关键之一。

另外一个异常检测的难点是很多做AIOPS算法的公司都遇到过的，那就是异常检测算法如何发现隐性问题，我们默认系统99%的时间是正常运行的，这条基本原则实际上是不够严谨的。因为绝大多数的IT系统在平时并不是没问题的，而是处于亚健康状态的。很多异常实际上已经埋在里面了，一旦被某种外因激化，就会爆发一些问题，导致系统性能下降、系统不可用。这些问题才是IT运维部门最为头痛的问题，而那些异常检测算法能够准确感知的明显问题，实际上大多数都是IT部门所熟知的问题。这也是一些AIOPS算法在测试时效果很好，实际生产应用时效果不如测试的主要原因。

不管怎么说，异常检测算法这些年进步很快，一些头部公司的异常检测算法已经具备了一定的实用性。不过随着异常检测能力的提升，另外一个短板就显现出来了。我们可以发现系统中存在的异常，这些异常可能代表了一个故障、一个隐患或者一个未来即将发生的故障，不过也可能仅仅是一个错误的判断。下一步就需要我们去验证或者确认这个异常是一个故障或者隐患。实际上这个能力是大多数企业的IT运维部门更为缺失的能力，也是IT部门的主管更希望获得的能力。如何实现故障分析，根因定位呢？目前大多数的AIOPS还是依赖于异常检测，通过寻找与发现的异常所相关联的异常来定位异常的根因，这句话似乎有点绕，不过这也是目前大多数做AIOPS的企业主要采用的手段。

采用这种方法的主要原因是因为目前我们的AI依旧存在计算能力强大，推理能力不足的问题。人类的专家是通过自己积累的知识库去做各种推理，裁剪不可能的故障路径，从而一步步逼近问题的根因的。而如果我们的AIOPS系统中不存在这些故障路径的知识，那么就可能出现越计算问题越发散，因此在智能运维中，需要有能力对故障路径进行裁剪，从而让一些系统中存在的一些亚健康状态或者一些此要衍生路径被及时裁剪掉，从而保证故障路径裁剪既可以确保方向正确，又不会过早的裁剪掉关联性很强的路径。

要解决根因分析的问题，故障路径发现和故障路径裁剪是两个矛盾统一体，首先我们能够通过知识推理去尽可能多的发现故障路径，而在一个网状的知识图谱中，绝大多数路径都有衍生路径和关联路径，因此故障路径的发现可能会陷入衍生过量的问题，如果只是沿着衍生路径走，那么很可能入口稍有偏差就与问题根源失之交臂，但是加上关联路径，那么很可能几步之后就可能过于发散了。这时候就要考验算法的能力和知识图谱的准确性了。算法的能力就是根据现场的数据尽可能早地裁剪掉一些可能性极低的诊断路径，从而降低干扰因素的作用，避免问题不可收敛。在诊断路径收敛中，异常检测算法仍然可以发挥巨大的作用。

目前AIOPS应用较为成功的领域是日志分析，通过对业务全流程的各种日志的分析，发现系统存在的异常。在异常发现与日志收敛上，AIOPS的算法发挥了很好的作用。不过在最后一公里上，依然效果不佳。这是什么原因呢？因为日志收敛的高级阶段依然需要“推理能力”。我们可以从各种日志中找到可能的疑点，但是具体到某个运维对象的问题的时候，收敛就不是很简单的事情了。比如下面的Oracle数据库的alert log：

如果我们不理解报错的故障的原因，我们能够确定10:00:13 的告警和10:00:35的告警是否可以合并，是否属于同一个问题的告警呢？恐怕是做不到的，在实际案例中，我们遇到过二者存在关联关系的案例，也遇到过二者没有任何关系的案例。人工来分析这个问题的时候，还需要针对sfoss2_j000_848310.trc进行分析，才能确定二者之间是否存在问题。这种情况，仅仅依靠算法来进行告警收敛，效果不会太好。

这个例子对于人类的DBA来说是一个十分简单的问题，有点运维经验的人都可以很容易的判断出问题在哪里。上面的例子是设备的存储空间满了，才导致这个问题。似乎很简单吧，不过事实上不简单。在同样的数据库版本，同样的操作系统平台上，这个错误有时候hp-ux Error并不会出现，有时候出现了，后面的参数不同，或者说后面可能会没有No space left on device，对于人来说，很容易区分这些不同，或者很快找到其中的相同，而对于异常检测算法来说，要实现精准的问题定位还是有困难的。这时候算法加知识库就可以更好的解决这个问题。

上面的例子是一个更有趣的例子，在同一个时间点上有几个不同的错误信息，这些错误是同一个错误的不同报错，还是两个完全不同的报错呢？这是客户十分关注的问题，以往也是需要依靠专家来解决的问题。一个Oracle数据库的专家可能可以通过4454和17281这两个参数判断出两者属于两个完全不同的领域，一个属于UNDO，一个属于HEAP数据，不过二者是否存在关联关系，则需要进一步的分析才可以确定了。如果我们把二者简单的进行合并，则可能错过了一个重要的错误，而如果不做合并，分别产生告警，则可能产生了错误的故障分类,因为17281单独出现和与4454同时出现，可能代表不同的错误。而想要真正区分出其中的区别，你必须具有这方面的完整的知识库，否则可能产生严重的误判。

IT运维就是如此复杂，所以说我们的AIOPS还是任重而道远的。虽然方法似乎我们都看得见，而且很多人也都在实践，而实际上要想有所突破，需要积累更多的知识与案例，仅仅依靠某一个企业或者某一家厂家来做这件事，都十分困难。建设一个开放的AIOPS知识生态体系十分重要，也希望有一些资金能够投入到开源的知识库生态建设中来，最终整个行业都会因此而受益。