关于运维场景化的讨论

实际上，所有的运维场景都是需要进行抽象的。同一类的故障，可能在一些细节上会有所不同，而同样的表象，通过溯源会发现产生问题的根因可能大不相同。我们会把这些情况都抽象为同一个运维场景，这样，运维场景的重现率会大大增加，同时虽然经过高度抽象后的运维场景普适性增加了，但是我们还是可以通过其中细微的差别区分出不同的问题根因。这是实现场景化运维中十分重要的。如果经过抽象后的场景我们都无法区分其根因，那么这种抽象中肯定存在一定的错误。

这种抽象实际上是一种十分高成本的工作，需要有相当高水平的领域专家参与才能做好。实际上大家都一直在寻找脱离运维专家就能够实现此类目标的方法，从理论上也确实有一些方法可以达成类似的目的。通过各类异常检测的算法可以从我们的运维监控数据/日志等中间十分准确的发现一些异常。因为我们的信息系统在绝大多数时间里是相对正常的，不正常的时间占比较少。通过一些异常检测算法，我们总能从大部分正常的情况中找到我们所想找的异常点。

不过虽然理论上如此，但是这种异常检测的方法中还是存在两个比较大的问题有待解决。首先，看似正常的信息系统，实际上或多或少的存在一些亚健康的状态，看似风平浪静的大海下面仍然涌动着各种暗流，因此异常检测算法很难得到一个没有任何噪音的正常模板，这样就会导致我们的异常检测算法精度下降。其次，如果我们发现了某些异常点，我们如果无法找到异常点中的异常根因，那么这个异常点也许会被我们认为是误差。如果我们对这个异常点的问题溯源并没有找到真正的故障原因，那么这个异常点的发现也会变得价值不大。异常检测必须结合深度诊断分析的算法或者专家的诊断，才能够真正发挥出其作用。实际上上面两种分析问题的方法是目前我们所能见到的最为常见的两种，第一种是以运维人员的思维方式来开展运维自动化工作的人常用的方法，以传统的专家视角为出发点，结合一些新的人工智能的技术，来降低运维工作中对专家的依赖，从而降低运维成本。第二种方法是从数据与算法为出发点的，这种方法只需要少量的专业技术支持就可以开始开展，对专家的依赖度最低。这两种方法最终都会遇到瓶颈，采用第一种方法会过多的依赖于专家，构建自动化分析能力的成本过高，如果运维业务比较聚焦，成本还可以接受，如果面对的运维对象类别、用户数量都十分巨大的情况，那么专家资源不足可能是一个大问题。采用第二种方法刚刚开始的时候可能会比较顺利，似乎不管针对的是复杂的Oracle数据库还是简单的tomcat中间件，通用的方法似乎是一样有效的，但是随着这项工作深入下去，就会发现，很多东西都无法真正落地。在临门一脚的时候发现，队伍里没有一个会踢球的，更不要说射门了。

我们再回到运维场景化这个话题，实际上运维场景化肯定来自于实际的运维经验，这些实际的运维案例在客户侧是很容易收集的，只要把客户这些年遇到或者处置过的各类运维案例梳理一遍，基本上就能够把覆盖这个客户90%以上的场景梳理出来了，再由相关的专家经过分析与抽象，就可以形成一定梳理的“运维经验”。在这个工作中，如果拥有了异常检测的算法，那么就如虎添翼了。我们可以通过异常检测算法来发现一些异常点，这些异常点有可能不是我们目前的“运维经验”模型所覆盖的，但是不要紧，只需要把异常点找到，然后用我们的运维知识库去进行分析，如果运维知识库把这种异常和我们一个已知的运维场景关联起来，那么我们就找到了一个老运维场景的一种新的分支。如果我们无法和任何已知的运维场景关联起来，那么我们可以通过状态巡检工具把这个异常的相关数据提取出来，交给后台专家去做相关分析，专家可以通过分析对该场景进行标注，打上各种状态标签，甚至将其定义为一种新的运维场景。