异常检测目前已经成为AIOPS中最为常见的方法，也是起步较早的一种AIOPS技术。异常检测最早起步于日志分析，不管是OS日志/数据库日志还是应用日志，在日志中，绝大多数信息是系统正常时的信息，以此建模，可以采用一些无监督学习的方法去对日志的正常与否分类，因此减少了监督学习的专家标注成本。如果能够结合一些故障案例与部分专家标注，还可以使用一些弱监督学习的算法获得更好的效果。日志本身就是记录系统异常状态或者正常消息的机构，因此针对日志的异常检测的确很容易取得一定的成果。不过日志中记录的系统状态还是十分有限，因此我们只能从日志中获得极少数的异常预测成果。如果想把异常检测做的更为全面，更能够支撑运维自动化工作，除了做日志的异常检测，还需要通过异常检测发现系统中较为深层次的隐患，这种情况下，我们就需要对系统中各类指标做异常检测。最为传统的指标异常检测方法是通过基线，不过系统的一些关键指标很难设定合理的基线，不同的系统，不同的时间周期，每天的不同负载时段，基线指标的差异十分巨大，为每个系统设置独立的个性化基线并不断的动态调整基线模板对于较为大型的，少量的系统是可行的。目前云平台上大量微应用的出现，让这种方式无以为继。因此通过指标的异常检测来替代指标基线或者结合指标基线和指标异常检测来做更为精准的指标异常分析是一种比较好的方法。如果我们要结合指标基线和异常检测算法来做指标异常分析，采用什么样的方法比较好呢？目前做这项工作的主要方法有两种，一种是完全依靠算法专家的算法，不需要了解指标到底是什么含义，通过机器学习或者深度学习的算法，对指标进行分析。实际上以前在医疗人工智能算法方面就有两个路线，早期做医疗影像分析算法的都是搞IT的，虽然也取得了很好的效果，但是在临床上的应用十分谨慎，因为依靠没有任何医疗知识在里面的纯粹的算力，其准确性仍然很难得到验证。前几年老白因为飞机坐的太多，尾椎出了点问题，于是请一个大医院的影像科主任帮着看看片子，看到这位主任的办公桌上放着一本PYTHON编程的书，于是就和他聊了聊。发现原来他准备自学PYTHON，编写一些影像分析的算法。当时我就和他探究了一下医疗影像大数据分析方面的一些技术。他认为，前期的一些影像大数据项目大多数效果不够好，达不到临床的要求，最主要的原因是缺少理论支持，哪怕取得了一些成果，这些成果也无法获得病理学上的理论支持，甚至很多项目的结果有点儿戏。他认为，医疗影像智能分析，必须由影像方面的专家、临床方面的专家的多方介入才有可能成功。实际上，运维指标的异常检测也是如此，除了算法专家外，必须有运维专家介入才有可能做好。其原因有几点。首先，既然要做指标异常检测，那么指标在哪里？哪些指标是值得去做检测的？这些指标如何被采集回来？你如何确保这些指标都是正确的，能够反映系统运行状态的？同样一套运维自动化系统，网管时代的运维自动化系统的指标大多数都来自于SNMP等标准库，不过不同厂家的产品还是会有一些自己独有的指标。实际上能够对运维自动化发挥作用的指标，大多数都不是简单的标准化的指标，而是运维团队多年来针对所面对的运维场景去采集的指标。目前我们的D-SMART中Oracle数据库有差不多400个指标，MYSQL少一些，大概有160多个指标。这些指标中有将近一半是经过加工后生成的指标，而不是从运维对象中直接采集回来的指标。而对监控运维发挥最大作用的是这些经过加工的指标，而不是原始指标。这些指标加工是运维专家多年积累的经验下完成的。因此这些指标用于各种监控与分析都十分有效。其次，指标的准确性也决定了异常检测的有效性。对于同一个指标，不同的运维自动化系统采集回来的数值可能会有所不同。不同能力的技术团队，对系统指标的认知会有所不同，因此采集和加工方式也会有所不同，这样指标的数值就有可能差异较大了。前阵子我们的一个南方的项目中同时部署了我们的D-SMART和另外一个厂家的运维自动化平台。用户的系统近期总出问题，D-SMART给出了十分明确的分析结果，主要问题是有一些未很好优化的SQL，导致了大量的物理IO。而另外一个平台给出的异常是，系统存在大量的换页，导致了系统性能下降。当时我们就很奇怪，通过我们拿到的数据看，这套系统有1TB的物理内存，SGA使用了不到400G，目前还有300多G的空闲内存，而我们采集到的SWAP使用率都是0，这种情况下，不大可能因为大量换页导致了性能问题。而从另外一套监控系统的监控指标上看，确实存在每秒几十M甚至上百M的换页。最后经过仔细分析才发现，原来那套系统采集的系统换页数据是错误的，把文件系统IO也算进去了。从上面的例子看，要想做好指标的异常检测，指标集的质量以及指标数据的质量，都是十分关键的，因此要做好异常检测，不仅仅需要算法专家的参与，更需要运维专家的支撑，二者缺一不可。
