AIOPS有两条常见的路线，一条是大数据+高端算法，另外一条是运维知识图谱+简单算法，D-SMART采用的是第二条，因为这条路线可以充分发挥我们团队二十多年的运维经验积累。具体哪条路线更好，也不好说，一切看疗效吧，这和医疗行业沃森医生和医院专家采用的医疗智能化解决方案的思路差异有些类似。其实如果二者相结合肯定会有更好的疗效。另外一方面D-SMART是作为一个通用产品销售的，而不是以项目形式做工程化定制的，因此第二条技术路线是唯一的选择。
D-SMART V2版已经在一些用户的生产环境中试用了快2个月了，而元旦后，V2的第一个稳定版本V2.0.1也即将发布，很多用户试用了V2版本的智能诊断功能后都表示体验不错。
实际上，D-SMART V1的各个版本中，很多用户并没有启用智能分析这个V1.9以后引入的新功能（需要在V1.9上安装一个存储于NEO4J中的知识图谱），智能分析工具目前主要在远程诊疗中心使用的云中心版中发挥作用，用于远程专家诊断。
V1的智能知识图谱是在2018年到2020年期间逐渐积累起来的，并还在不断地迭代升级。主要知识来源于专家梳理的知识和这些年积累的大量的实际案例。
相比V2版本的知识图谱，V1的智能化诊断的结果收敛效果还不够好，根因归纳功能还不够完善。因此诊断结果对于一般水平的运维人员来说可能还是会看不太懂。
另外V1版本中的知识点依然大量依靠传统的专家知识点，专家知识点工具开发时面临两难的境地。如果一个知识点中包含了太多的专家分析能力，其诊断功能就十分强大，不过这个知识点的适用性受到影响，一旦出现了专家未能掌握的场景，这个知识点诊断的效果就有限。而且大量的逻辑包含在一个知识点之中，也无法拆散了使用。但是如果知识点拆散拆小了，一些专家的诊断逻辑就很难加载到知识点中，智能化诊断分析的能力想要达到专家的深度总是存在一些问题。
上图是智能诊断V1的流程图，问题感知之后通过知识图谱发散思维，找到关联指标集，然后进行异常检测，最终通过异常检测的结果推荐诊断工具。这种模式虽然说也能发现异常指标，并进行简单的归纳总结。有经验的运维人员通过发现的异常指标进行辅助判断，也可以选择下面推荐的诊断工具可以进行定位确认。但是这个功能也存在一些问题，推荐的诊断工具可能会比较多，异常指标分析也更多的依赖运维人员的经验，使用该功能的体验还不够好。具有一定运维经验的专家确实可以在智能诊断V1的帮助下，大大节约诊断分析的工作量，但是对于普通的运维人员，用起来还是有一定的难度的。这也是智能诊断V1在用户现场的使用量远不如云中心的主要原因。另外，随着大量的复杂度并不高的运维对象的引入，知识点工具的开发工作量也比较大，知识点高密度覆盖的需求总是很难推广到所有的运维对象上。因此我们这两年一直在重点运维对象，比如Oracle、Mysql、Pg、SQL SERVER、达梦、Redis等数据库上进行大范围的知识覆盖性开发。而对于其他一些运维对象的知识点覆盖只能在客户有需求的时候予以响应。知识库V2的设计从今年年初就开始了，不过真正的开始考虑升级知识图谱是从2020年下半年我和裴丹教授的团队交流AIOPS之后就开始了，那次交流虽然主要是我在介绍我们的运维知识图谱，不过他们的故障衍生路径的思想也让我深受启发。“衍生”两个字是对运维知识图谱很好的概括，只有能够自动衍生的知识，才是最有价值的知识。实际上在今年发布的每个版本中都会有一些V2的功能被封装进去了。包括现在一些用户的V1.9.6版本上，也是支持V2.0的知识库工具的，更新一下图数据库的数据就可以在V 1.9.6上使用V2.0的智能诊断功能了。那么V2.0的智能诊断和V1.0有什么不同呢？上面是智能诊断V2的逻辑流程图，似乎好像两张图很相像。确实从问题感知到图推理生成问题指标集的过程是类似的，只是算法做了一定的优。通过第一步的图计算我们可以获得一个指标集，然后进入ADF引擎去做异常检测，输出一些可能的问题集。这个可能的问题集通过一个智能路径裁剪器，把不可能的路径裁剪掉，就可以产生诊断结论了。这个诊断结论是V1版本中没有的，不过这一点改进对于用户体验来说是十分关键的。诊断结论的内容十分清晰，稍微有点运维经验的人员都可以看懂。
根据这些诊断结论，有经验的运维人员就可以很快定位系统问题了。如果你觉得还不够放心，可以通过下面推荐的诊断工具去做验证。比如上面的例子就推荐了“PG数据库连接失败分析”这个工具来验证这个问题是不是如智能诊断工具发现的那样，是因为网络丢包引起的。至此，V2很好的解决了智能诊断工具的易用性问题，让水平不是很高的运维人员也能感受到智能运维的美好。不过仅仅有这一点是不够的，V2的知识库还需要让智能运维知识点开发的更容易。以前很多复杂的分析逻辑是封装在某个知识点里的，而实际上，当知识图谱构建到了V2阶段的时候，我们已经有了数万个顶点，十多万个关系了，这时候用智能诊断工具就能够实现很多以前只有专家才能写出的分析逻辑了。虽然针对一些特别复杂的诊断逻辑，我们还需要专家编写专业的工具，但是对于大多数的知识点中，已经不需要包含特别复杂的分析逻辑了，分析工作可以完全交给知识推理引擎了。在V2中引入了一种新的知识点-“智能知识点”，这种低代码的知识点只需要定义一定的属性而不需要包含任何诊断逻辑，编写一个这样的知识点可能只需要花费几分钟（当然不包含知识梳理的思考过程）。我们将这个知识点投放到图谱中之后，不需要为这个知识点和其他的图元之间创建任何的关联关系，它会自动和周边的网络建立联系。智能知识点加入之后，不仅仅会自动在智能诊断中发挥作用，它也会像一个三层交换机一样，自动维护一个微网络，并通过自身有限的路由能力，改变整个大网，改变已有的知识体系，在图数据库中形成新的诊断链路，从而改善所有的诊断路径。智能知识点的引入可以大大改善智能化运维生态，以往很多用户想自己定义自己的知识图谱，但是因为开发知识点工具还是存在一定的难度，因此知识点工具的开发一直是由我们的团队来支持的。因为工程排期等原因，知识更新慢的时候周期在一周左右。智能知识点的引入可以大大降低知识点工具开发的门槛，稍微有一定运维经验的客户可以自行开发自己的知识点了。而交给我们来开发知识点，其响应时间也会大大的缩短，快的话上午提交需求，当天下午就可以拿到新的知识点了。当然智能知识点的出现与微网络的出现是在整个运维知识图谱已经发展到一定阶段后的必然产物，如果一个运维知识图谱中没有传统的知识点，大多数都是用于构建微网络的“智能知识点”，那么这个图谱的性能还是有限的。D-SMART的开发马上要进入第五个年头了，对于智能化运维领域来说，我们还是像小学生一样刚刚摸到门径，不过随着知识的积累，这个过程会越来越快。就像最近我在看的科幻小说《星之继承人》中所描述的，一个2500万年前为人类诞生推波助澜的外星文明的眼中，人类最近这100年的发展是令人咋舌的，从这100年可以看出人类早晚可以走出太阳系，走向宇宙星辰。我想AIOPS也是如此，虽然它的出现只有短短数年，但是已经深深的影响了存在30多年的传统运维。作为一个在传统运维领域干了二十多年的老兵，也对AIOPS的未来充满了憧憬。
