隐性事件驱动的溯源分析

隐性事件驱动的溯源分析

信息系统故障分析，根因溯源一般基于两种模式，一种是基于事件驱动，一种是基于数据驱动。传统的数据库运维中的溯源分析都是基于事件驱动的，因为我们的数据库运维都是被动运维，只有数据库出现故障，已经影响了业务，才会进行故障分析溯源。随着核心数据库在企业中的重要性越来越强，被动运维的模式已经无法满足业务部门对SLA的要求了，于是主动运维的呼声越来越强烈。主动式感知，防患于未然成为每个企业对数据库运维的基本要求。不过要实现这种基本要求，其难度并不低。实现这种主动式运维最早被采用的就是数据驱动的分析溯源。当某些基线数据出现问题的时候，我们就主动发起分析，找到问题的根因，消除隐患，避免数据库系统出现更为严重的问题。在2015年的《大型企业IT运维峰会》上，我分享了一个话题《基线与容量在企业IT运维中的作用》。在主动式运维中，基线分析与容量分析确实发挥了很大的作用，对于防范一些常见故障效果明显。

不过随着业务部门对信息系统SLA的要求的不断提升，我们发现基于普通的基线能够提前预知的问题还是十分有限的，有很多隐藏地很深的系统隐患并不能简单的从某个指标的状态变化被发现，而大量的基线指标报警也让运维人员的响应成本急剧增加，一个运维人员每天处置10-20个基线告警，并进行溯源，就会占用他几乎一整天的时间，而面对数百上千个基线、日志告警，唯一的做法就是置之不理，久而久之，基线告警就成为一个摆设了。

实际上在绝大多数企业里，DBA们都在同时采用基于事件驱动和基于数据驱动两种运维模式，基于事件驱动是针对一些显性的事件，比如业务部门、开发商的投诉。这种响应往往是效率比较高的，而基于事件驱动是根据各种监控系统的报警进行，这种工作有可能会徒劳无功。我们该如何更好的做好主动式运维呢？引入基于隐性事件驱动的自动化分析方法是解决这个问题的一种比较好的方法。

基于隐性事件驱动的自动化分析方法的本质分为两个部分，第一个部分是隐性事件驱动。和普通的事件驱动不同的是，隐性事件发生的时候，系统往往还没有出现大的问题，业务系统也没有出现特别明显的不可用或者极为缓慢的情况。但是系统已经出现了某种亚健康的状态，有些亚健康状态有可能是临时的，经过一段时间波动后，系统会恢复正常，但是同样的亚健康状态，如果系统一直处于并发量比较大的情况，持续出现一段时间后，就有可能出现系统健康进一步恶化，出现较为严重的系统问题。因此我们如果对这种隐性事件进行分析，那么就有可能会徒劳无功，如果我们放弃分析，就有可能错过了一个防患于未然的机会。因此在处置隐性事件的时候，一定要有自动化的分析手段，如果完全依靠人去分析，那么再多的人力资源也是不够用的。

隐性事件的发现手段有很多，不同的行业可以采用不同的手段。比如对于金融、证券行业，针对核心交易延时的端到端监控是其中的一种发现隐性事件的比较有效的手段。银行要求核心交易低于100毫秒，这是一个以人力很难去识别的指标。如果某个银行核心交易系统的核心交易平均延时为70毫秒，那么如果这个指标变为80毫秒的时候，还未触发银行的风险报警，如果这个指标持续很长时间都是超过80毫秒甚至90的，那么就完全可以确定为一个隐性事件了。这时候触发一个自动化问题溯源很可能会有所发现，不过很可能十次出现类似情况，有七八次是虚惊一场。通过类似的方法发现隐性事件实现起来比较简单，不过有一个不太好的地方有几个方面。第一方面，这种隐性事件被发现后自动化分析工作比较麻烦，因为核心交易响应时间的影响因素十分复杂，故障排查的路径特别发散。第二方面是，某些隐性事件发生时，有可能业务交易延时并没有受到影响，此时我们就无法发现了。第三方面就是一些非交易类的系统，业务响应时间差异很大，很难像银行证券那样确立核心交易响应时间这样的指标。

通过故障模型、健康模型、性能模型等数据模型构建隐性事件发现体系是另外一种方法，比如一个存储系统，如果IO负载不高的情况下，存在高档位运行的风扇或者出现大量的超温磁盘，那么这个存储系统可能存在某种隐患；磁盘不存在超温，机箱温度正常的情况下，出现高档位运行风扇，则存储存在隐患。上面就是几个针对集中式存储的故障模型实例。通过这样一些故障模型实例构建出来的系统的故障模型，可以较为准确的发现系统存在的隐患。而且这些模型中都具有一定的专家经验，一旦触发模型，诊断方向相对明确，更便于进行自动化的分析溯源。

最后我们来看一个基于隐性事件驱动的分析案例，这是一个来自于制造业的案例。

数据库的健康状态突然下降，数据库并发、数据库RAC集群、数据库负载三方面的健康度下降较为严重。

通过智能指标分析，进行自动分析。发现与该异常指标相关的指标

有点经验的DBA看到这两个划红线的指标马上就能想到这个问题很可能与写操作相关的sql有关。

通过TOP SQL分析工具，很快就发现了几条INSERT/UPDATE语句执行的十分频繁，通过这几条SQL，客户很快就定位了出现异常问题的应用模块，从而消除了以个隐患。

上面的过程是半自动化的，依然需要有DBA参与。虽然说工具已经大幅度减低了分析的难度，减轻了DBA的工作负担，但是这还是不够的，面对数百个数据库系统，要对隐性事件做闭环管理，运维人员和专家很快就会不够用的，基线预警曾经出现过的问题很快就会重演。自动化诊断的引入才能更好的解决这个问题。

这是D-SMART 2.0的一个新功能：“自动化诊断在线与离线诊断”，可以实现针对故障模型报警的自动化分析，能够利用“运维知识图谱”自动化发现诊断路径并进行自动化扫描，并将扫描中发现的问题进行归并汇总。采用自动化诊断功能后，可以将部分没有发现严重问题的告警彻底过滤掉，只有发现了严重问题的事件才会推送给运维人员。这种告警收敛的手段比传统的通过各种算法的告警收敛要有效的多。