作者介绍马波，平安科技数据库团队运维开发工程师，参与平安领域AIOps落地项目技术数据库，主要包括趋势预测、异常检测、自动化运维平台、日志告警等方面，目前正在平安云上构建智能数据库运维系统。回顾整个运维的发展历程，从最初的系统管理，到基本的脚本运维，再到自动化运维，最后发展到智能运维。经过这些年的发展，运维人员的工作内容发生了翻天覆地的变化：十多年前，我们不知道故障会出现在什么地方，也不知道什么时候会出现，只有在出现问题的时候才能发现。故障发生这是一种非常被动的方法来解决根本原因和解决故障。后来，随着大型脚本的引入，我们处理问题的方式变得更加科学，速度上也不尽如人意，但仍然没有改变这种被动解决问题现象的本质；结合以往的经验，很多公司引入了监控系统，开发了自己的自动化运维平台，目的是在问题发生或即将发生时自动解决问题。这种方式恰恰突破了以往所有“被动运维”的本质，能够防患于未然，将故障扼杀在摇篮中。但随之而来的是大量告警和海量监控数据。如何更高效的解决故障成为我们现在必须解决的难题。人工智能时代的到来恰好解决了我们面临的上述问题，而AIOps希望进一步解决基于现有运维数据（日志、监控信息、应用信息等）的自动化运维问题。通过机器学习。问题的解决方案。我们目前正在积极推动数据库运维从自动化到智能化的转变。众所周知，数据挖掘和机器学习离不开海量数据，而平安科技通过近几年自动化运维的应用积累了海量多维度的数据库性能数据、日志数据、主机数据等。年。利用这些数据，我们可以在时序异常检测、根因分析、邮件告警收敛、容量预测等多个应用场景中，通过机器学习等方法获取我们想要的信息，从而进行自动故障发现，自动诊断并自动解决。1.时序异常检测时序数据是AIOps的基础数据，具有规模大、类型多、需求多样的特点。在自动化运维阶段，我们使用的方法大多是常量阈值。这种方法简单易行，但缺点也很明显：不够灵活，发现故障不够及时，不能满足目前的告警要求。如下图所示，传统的阈值报警会忽略两种波动异常：恒定阈值法和动态阈值法这时候应运而生。该方法解释性强，易于实现，但灵活性较差，受节假日影响较大（如下图，9月24日是中秋节，流量较上周下降明显。在这次环比和同比比较的方法不适用），发现问题不够及时。也有很多公司采用加权移动平均法来做动态阈值。他们认为在同一个维度下，某个点的值一定与其之前的数据相关，如下式所示：9/18-9/25Indicatordatagraph我们目前正在将机器学习应用于时间序列数据异常检测。与上述方法相比，机器学习方法更准确，成本更高。时间序列异常检测本质上也可以看作是一个“正常”和“异常”的二元分类问题。通过对历史监控数据进行标注，然后结合有监督和无监督算法建立模型，判断当前时间序列是否正常。2.根本原因分析大多数情况下，由于监控指标的相关性，如果某个指标出现异常，那么相关的很多指标也会出现异常。如果同时对所有告警指标进行分析处理，会浪费大量的人力。为了解决这个问题，我们需要进行根本原因分析，进行有针对性的治疗。一般我们可以通过以下三种方法对数据进行根因分析：获取关联指标，找到特定时间段内与异常指标相似的指标。在大量的样本中，找到经常一起出现的异常指标（这个问题转化为频繁序列挖掘问题），实现方式包括关联规则、APRIORI、FP_GROTH等。利用决策树的强解释性，对正负样本进行分类，然后通过异常指标的分类树方法找到频繁异常指标集。以Oracle数据库DB_TIME偏高为例：第一种方法是找出当前时间段内与DB_TIME指标有相似曲线的指标，以最相似的指标TOPN作为根本原因；第二种方法是找出历史数据中的指标，其中，当DB_TIME出现异常时，其他异常的指标组成若干个项集，然后利用关联规则从这些项集中找到强相关的组合，然后这些组合中的其他指标被视为根本原因；第三种方法，根据历史数据中DB_TIME是否异常，将历史数据分为正样本和负样本，训练决策树模型，得到最终的rootcause。根因分析法一种根因分析法两种根因分析法三三、告警收敛当监控业务发展到一定规模后，每天收到的告警邮件数量会成倍增长，尤其是一些监控频率高的当监控项出现问题时尤其如此。为了解决这个问题，一开始我们就设置了告警频率，让同一个告警在一段时间内只出现一次。这种方式确实会减少一些告警，但是还是有一些比较明显的告警可以通过制定规则进一步收敛。比如同一个集群的数据库无法ping通，或者同一个网段的所有IP流量突然变大，这些告警可以综合起来发送。在AIOps时代，告警收敛和根因分析往往是一起进行的。与根本原因分析方法2类似，我们可以先获取告警项集数据，提取频繁项。如果在频繁告警项集合中，告警A和告警B经常一起出现，且A出现早于B，在邮件告警中，我们可以忽略B告警，只将A告警推送给运维人员。不同场景的告警收敛有不同的要求。与AIOps相比，传统的告警收敛方式更简单高效，基于规则的方式也具有很强的可扩展性和解释性。以及凭经验无法发现的相关项目并进行告警收敛。4.容量预测容量预测在数据库运维中用到很多地方。不同的应用场景有不同的特点。我们很难找到一个模型来适应所有的数据。在容量预测方面，我们的典型应用是数据库DB_SIZE容量预测，数据库容量具有整体增长、不规律、波动大的特点。合理预测数据库容量，能够及早发现短期内可能出现的故障，主动预防，及早解决，无需在问题发生时被动应对；可以长期进行合理的产能规划和资源配置。一开始我们想到了线性回归加上简单的数据预处理，但是结果并不理想。由于业务规模的不同，不同数据库的容量差异很大，在进行表导入、数据库扩容等操作时，采用线性拟合或非线性拟合的效果并不理想。显然，传统的线性回归方法虽然简单，但预测效果较差，不能满足要求。为了解决这个问题，我们将容量数据分为周期型和骤升骤降型。分类方法可以是统计方法、聚类方法或分类方法。对于周期性数据，我们可以认为它其实是线性拟合的，因为在整体上升趋势中，一个周期内周期性数据的增长值是线性增加的。对于这类数据，我们可以使用线性回归机器学习方法来预测数据库容量。周期性数据和突增突降数据，线性拟合效果较差。此时，我们采用链增量求和的方式，得到历史数据中周一至周日具体日增量的加权平均值；然后将此增量应用于预测。与简单的线性拟合方法相比，该方法的精度大大提高，平均预测数据的均方残差增加了近一倍。以上四种数据暴涨暴跌应用场景的技术开发，致力于通过AI让运维更高效，让更多的故障提前发现和解决。关于AIOps，我们还有很多东西可以尝试和探索，比如智能问答机器人、集中式日志分析平台等，稍后我们会和大家分享相关成果。
