谈到智能化运维，谈智能检测或者智能发现的比较多，谈智能诊断的比较少。智能诊断不好做，因为诊断涉及到复杂的分析与推理。检测与发现可以基于数据的统计学规律，通过训练与建模来不断提升性能，而复杂问题的诊断推理，还是很难通过简单的统计学方法来实现的。
前阵子我写过一篇关于莫拉维克悖论的文章，说的是在几十年前，采用知识推理的方法很容易解决一些比较复杂的问题，而一些类似模拟人类的视觉、行动等较为简单的问题反而很难解决。事实上，最近这些年的基于数据分析与统计学的算法让这些当你困扰莫拉维克们的问题变得十分简单了，深度学习可以很好的解决这些问题了。通过统计学的方法，通过深度学习，识别异常变得更为容易了，这是构建智能运维系统的基础。以前我们往往需要依靠专家来发现真正的“异常”，这里说的“异常”不是通过网管系统，通过基线或者日志采集发现的所谓“不可确定的异常”，而是真正可能威胁系统健康的异常。
通过算法发现异常仅仅完成了智能运维的第一步，而下一步就是要通过一系列的现象去推理出现某种异常的原因。我曾经和一个做智能运维算法的朋友交流过，他认为这是十分简单的事情，把系统中的采集数据都计算一遍，把发现的问题进行归类，不就很容易获得问题的原因吗?
事实上，我的这位朋友并不是做运维出身，而是纯粹的算法工程师，他比较难以理解数据库系统这样的复杂系统，其问题根因归类是十分困难的。另外他也不清楚系统在实际的生产环境，某个数据库系统总是处于亚健康状态。除了引发这个问题的内因外，这个系统可能还存在多种问题，将所有的指标都进行一次异常检测，再通过收敛算法归纳根因，并不能实现真正的根因发现。
这些年，如何做智能运维算法的问题也一直在困扰着我，前阵子和一个客户交流的时候，就提起你如何才能通过算法精确的定位数据库问题的原因，并采取准确的手段去做处置呢?我当时想都没想，就说，对于大多数场景来说，我们做不到。能做到的仅仅是一些十分简单的场景。智能发现和智能诊断目前还只能做到帮助运维人员定位一个大致的方向，从而减少运维人员分析问题的工作量，而无法真正替代人工，最后一公里的发现，依然需要人，甚至有时候需要专家才能够完成，DBAIOPS在目前的阶段依然只是配角。
构建智能分析模型是我这些年一直在探索的，2017年我们开始这个项目的时候是和某高校合作的，他们的算法能力让我们耳目一新，原来数据库的问题分析还能够让一群完全不懂数据库运维的人，通过算法就能做的这么好了。我们一起合作做了Oracle数据库的关键指标筛选，健康模型构建，健康指标预测等项目。其中健康模型构建工作的大部分成果目前还在D-SMART系统中应用，不过其他工作的技术方向走下去似乎都很难走通。健康指标预测虽然在当时获得了比较好的效果，不过在实际应用中被用户认为价值不大。因为一个数据库系统在99.9%的时候是表现良好的，指标预测的准确率再高对运维的实际帮助也不不大，误报的时候才是对运维最为致命的。
2018年，有一次和客户交流的时候，他对我们的方案十分不满意，他说：“老白，别和我谈什么智能化算法，如果你能把你们团队专家们分析数据库问题的方法用自动化的手段实现一部分，能够在我们的运维现场帮助我们解决一些常见问题，那就比你所谓的智能算法要有价值的多了”。他的话让我如梦方醒，我们的专家脑子里拥有最宝贵的智能化分析算法，为什么弃之不用，反而拼命去追求一些混沌的数学方法呢?于是我们开始转向专家知识的梳理，引入知识图谱，通过构建运维知识图谱去解决一些复杂的推理与分析问题。
不过梳理专家知识也不是一件容易的事情，而且本身很多问题就像量子纠缠一样，是比较难以弄清楚的。比如我们来看一个简单的场景，CPU使用率异常。一般来说，一个运维人员分析CPU使用率异常的时候，会从两个角度去看这个问题，一个是触发这个异常的一些主要原因，就是我列在上方的那些，当然这只是运维经验的一部分，而且也仅仅是某个专家或者某个团队理解的一部分，并不能覆盖所有的场景。
另外一部分是CPU使用率异常可能引发的现象，这些现象是我们能够用各种观察的方法观察到的，也是很容易通过监控数据采集与异常检测分析到的。当CPU使用率异常的时候，这些现象中的一个或者多个会出现。这时候我们就很容易总结出一个方法，首先CPU使用率异常可以通过异常检测算法较为准确的算出来，然后我们可以通过现象来验算这个异常发现，同时也为问题分析提供大致的方向，再去源头发现可能存在的问题。
似乎很简单，不过你可能会发现，有些因素既出现在引发现象上，也出现在触发原因上，也就是说在实际的生产环境中因果关系并不是固定的，有可能会倒置。甚至可能发生类似水塘中的涟漪一样，多个波会相互干扰，这是系统的复杂性导致的。不过这些问题难不倒算法专家，通过时序分析，很容易发现多个波动之间的关联关系以及波动的时序先后，从而区分因果;通过统计学的分析也可以发现这些数据之间的复杂关系;通过深度学习还可以找到一些人类专家比较容易忽略的隐性关系。
只要通过知识图谱构建，把一个基本图谱建立起来了，那么一些复杂性的问题就会变得简单与清晰了。以往完全依靠深度学习才能完成的，样本极难覆盖的问题也就迎刃而解了。不过在实际的生产环境应用中也并不是这么简单。这个图谱需要不断地积累与不断地完善。而要完善这个图谱，数据又是极其关键的。只有通过不断地积累数据样本，才能不断地去完善上面的这张图。最近我一直号召社区的朋友能够分享SQL SERVER的监控数据，就是这个道理。我们见识过的运维场景十分有限，必须通过大量的，分布在各行各业的实际生产案例，才能更好地提炼出知识。
而如果我们有了丰富的数据，分析这些数据的工作量又极大，如何解决这个问题呢?算法这时候就能够发挥巨大的作用了，通过强大的算法发现异常，通过专家来分析异常，提炼知识图谱是这个生态体系中十分关键的一环。以往我们做智能化运维系统的时候，往往把运维专家与算法工程师割裂开来了。二者没有很好地融合，从而导致二者的优势无法形成合力。
每次写这个话题的时候，总是觉得写的比较费劲，而且写到最后发现很多问题还是没讲清楚，确实也是的，AIOPS，我们还刚刚上路，很多工作都是尝试性的，虽然有些成果，但是仅仅是起步而已。也希望在这个领域有兴趣的朋友不吝赐教，同时加强交流与合作，为了一个共同的理想做些事情。