基线和运维经验

我研究基线已经快20年了，在我帮客户解决问题的时候，发现缺乏基线是影响做出正确判断的重要因素。我们想去定位某个问题的根因的时候，往往不知道某个指标以往是什么样的，因此很难判断某个指标在出问题的时间段里是否存在异常。有了基线就不一样了，和基线一比对，有没有问题就一目了然了。

有了基线其实还不够，对于一套你经常看护的系统，基线的作用十分明显，而且也很有效。而对于一套你刚接触的系统，你无法获得历史的基线，除非这套系统拥有很多指标的历史数据。比如我们在使用AWR报告来分析一套系统是否存在问题的时候，往往需要使用历史时期，系统正常时的报告来进行比对。Oracle也提供了将某些特殊情况（比如系统正常，低负载，高负载）的AWR数据设置为baseline，从而用基线来实现更高级的AWR分析功能。

不管怎么样，基线的分析需要专家的经验参与才更有效，不同水平的运维人员面对基线能够分析的深度以及准确性都时差别较大的。正是因为如此，基线虽然应用十分广泛，但是基线的应用效果并不好。

另外一方面，基线有时候过于死板了，一套系统，高负载，低负载，早上业务高峰期，半夜批处理工作期等，系统的负载种类和大小差异很大，基线也各不相同。根据不同的负载类型和时间窗口构建动态基线一直时很多用户梦寐以求的事情，不过这个概念提出十多年了，依然没有很好的产品出现，这是因为动态基线要想获得较好的效果，其成本太高了。

于是在不断提升的运维实践中，有些人提出以异常分析来替代基线管理。我们不用去管某个指标是否处于基线范围内，我们的目标是发现指标的异常。因此我们可以用给系统设置基线，而通过深度学习、机器学习的算法来自动判断出现的异常。这种方式确实比设置僵化的基线要好，通过优化算法，我们也可以获得一种全新的异常检测的方法，不过依然没有解决专家解读的问题。当某个指标出现异常的时候意味着什么？这一点依然需要专家来解读。如果解读这个异常报警的人水平不够，或者这个专家的知识存在局限性，那么很可能发现了某个指标的异常，但是无法定位系统存在的问题。

很多第一次使用D-SMART的人很容易就会对基线与基线告警模板产生兴趣，D-SMART里确实存在很多基线模板，不过我们并不希望用户面对基线去做运维。基线模板是我们这些年对这些运维对象的理解，往往是采用了较为中立的通用场景，基线告警并不意味着系统存在问题。因此D-SMART中的基线告警并不是给普通运维人员使用的，系统做日检、月度巡检的时候，自动化巡检工具会自动对这些数据进行分析。具有一定水平的专家也可以在分析问题的时候参考基线告警来判断系统可能存在的问题。而普通的运维人员，我们建议使用的是“运维经验告警”。

有些工作经验比较丰富的DBA看了我们的运维经验告警后，觉得这不就是一系列的复核规则吗？基线是单一指标异常，而运维经验告警是基于一系列指标的一个计算规则的告警。甚至有些人和“复合基线”这个近些年兴起的概念关联起来了。实际上不是这样的，我们先来看两个D-SMART的“运维经验告警”的例子。

上面是一个PostgreSQL的运维经验的例子，发现了系统中dirty page写入者的比例出现异常，这种异常往往是因为系统负载较高时，shared buffers、检查点、bgwriter等配置不合理，或者WAL性能存在问题导致的。

上面这个是Oracle数据块共享池存在问题时出现的一种故障场景，因为SQL解析引发了一些系统性能问题。

大家可以看出，运维经验告警实际上是由两部分组成的，一个是触发运维经验告警的规则，我们也把这个称为“故障模型”，故障模型是大量的专家在二十年的实践中总结出来的，较为常见，并且已经被分析清楚的故障特种抽样。可能类似的故障并不会触发所有的规则，不过只要符合这个模型规则的故障，基本上都是一类。这是经过专家的抽象和总结出来的经验。

运维经验的第二个部分是诊断知识，当此类问题发生的时候，我们该采取什么样的诊断分析操作。这个诊断来自于两种技术路线，一种是相对固化的，专家固化下来的经验，这些经验已经变成了自动化的工具。另外一种是人工智能，每个运维经验里都有“智能指标分析”这个按钮，它是利用系统中的知识图谱，通过异常检测算法去分析相关的指标，然后通过知识图谱收敛分析结果，获得根因。

这是上面PG那个运维经验告警的智能诊断分析结果。实际上，在某些时候，这个分析能力已经超过了人类专家的能力，高水平的专家在此工具的辅助下也可以更高效的进行分析。在运维经验定义的知识点工具中，有一类是泛路由知识点，此类知识点不仅本身有智能化分析的能力，还可以在知识图谱中改善诊断路径，提高诊断效果。

在问题诊断的部分，我们引入了智能分析的能力，不过在问题发现的地方我们还是使用了传统的规则引擎。可能有些朋友会觉得这种模式科技感不强，而事实上，这是最为有效的方法。采用通用的深度学习的方法来发现问题，实际上效率并不高，因为需要大量的数据采集与标注，而做出的效果不见得比专家总结了十多年的经验好。因此我们在故障模型的发现部分依然采用了传统的方法。当然传统的规则也暴露出了一部分过于僵化的问题。我们的规则引擎目前也已经是第三代了，每一代都会支持更多的指标分析模式与表达式类型。

我想在运维工作中，完全放弃专家积累了二十年的经验，一味强调人工智能，是十分不明智的，不过一味的坚持传统的专家经验而不从人工智能中汲取新的营养也会固步自封。从基线分析到异常检测和运维经验是我们在运维智能化方向上的一些新尝试。也希望更多的朋友加入到我们的行列中来，运维经验的积累和抽象需要有大量的案例、大量的客户、大量的专家参与，才能做的更好。