在本系列上一篇文章《我在百度对抗报警风暴（一）》中，百度高级研发工程师运小博介绍了报警风暴的成因及简单的报警合并策略。本篇文章中，运小博将介绍关联策略的报警合并策略、基于报警数据挖掘的机房故障分析、报警关注度分析、值班与逐级通告机制和报警回调等技术。

报警合并策略

关联策略的报警合并

某个模块的出现问题的时候，往往会引发上游或者下游模块也一并报警。假设模块A调用了模块B，当模块B出现问题的时候，很显然模块A和模块B都会产生报警。为了解决这个问题，我们尝试从历史报警数据中挖掘关联的报警策略列表，然后就可以使用《我在百度对抗报警风暴（一）》提到的报警合并机制对跨模块的相关报警进行合并。

历史上每次B模块出现同样的问题的时候都会导致A模块有类似的报警，换言之，若历史上A模块的策略rule1和B模块的rule2经常同时报警，那么A模块的策略rule1和B模块的策略rule2就可能存在关联。因此我们可以挖掘历史报警数据中的关联关系，即关联的报警策略列表。

如上图横轴为时间轴，每一个位置都产生报警的时间，比如最开始的报警是A模块的rule1，然后是B模块的rule2等等。然后使用挖掘窗口（上图中的大括号为一个挖掘窗口）进行滑动，把位于同一个窗口内的报警归结为一个事务。

接下来我们就可以使用常见关联分析算法挖掘频繁项集（历史上经常在一起出现的报警策略）和关联规则（报警策略之间存在很强的关系）了。我们先要回答一个问题，怎么样定义报警策略的频繁出现？或者说，两个报警策略是否存在关联？

一个项集的支持度计数被定义为该项集出现的次数，这里没有用传统的支持度是因为历史报警数据产生的数据往往较多，而实际项集数据出现的比较稀疏，意味着支持度的分母巨大，分子却很小。

置信度是针对一条关联规则X:rulem->Y:rulen而言定义的，代表了X:rulem导致Y:rulen发生的可能的概率。

支持度计数S_count(X:rulem)=以 X:rulem开头的transaction的数量

支持度计数S_count(X:rulem->Y:rulen)=以X:rulem开头，并且包含Y:rulen的transaction的数量

置信度c（X→Y）计算公式如下：

支持度和置信度超过一定数值即为所需的关联规则。按照这样的规则，在等待发送队列中当某个报警发送时在报警策略关联表中查找等待队列中是否包含关联策略，如果包含就合并成一条报警信息发送。

机房故障期间的报警合并

机房故障（网络中断、机房断电等）会导致部署在该机房的模块异常，引发大规模的报警风暴。报警风暴不但会对报警的处理造成打扰，而且可能会增大报警系统压力，严重时可能导致后续报警延迟送达。因此，如果能快速准确地感知机房故障，并将相关报警进行合并，将会有利于运维人员快速捕捉故障根因，还能减少报警系统压力。

一个机房往往部署有多个业务系统，而一个业务系统也会把自己的模块部署在多个机房中以提高可用性。当某个业务的运维工程师发现单个机房的多个模块出现故障，就会怀疑是机房故障，但很难直接确认。所以，他们一般都会找其它业务的运维工程师寻求确认。如果多个业务都在这个机房出现问题，就基本能够确定是机房的基础设施出了故障。

通常，我们会想使用每个机房的报警数量来表征这个机房的状态，但百度部分产品的体量庞大，当这些业务故障的时候，会导致报警量突升，从而影响对机房的判断，因此最终我们选择了异常策略比例RuleRatio和异常业务比例ProductRatio两个特征。

为了寻找如何用上面的两个特征确定是否有机房故障，我们抽取了历史一段时间各个机房的特征，并利用散点图来训练。如下图所示，横坐标是RuleRatio，纵坐标是ProductRatio，每个点代表某个时段的某个机房。图中红色为机房有故障的样本，蓝色为无故障的样本。

从上图看，线性分类器就能区分故障和非故障的样本。

对历史数据进行回溯，上图横轴是时间，纵轴是按上述指标计算的异常评分，每一条曲线代表了一个机房，几个异常点分别是某一次机房的故障。

报警关注度

报警关注度是指报警发送后有实际处理的比例，但系统运维一段时间后都会发现部分报警的关注度并非100%，大多数情况下并非是值班工程师不尽责，而是部分报警策略随着系统的演化已经失效而又没有及时删除，因此需要我们有一种方法识别无效报警。

夜间关注度分析

我们观察了一条报警的处理过程。收到一条有效的短信报警后，值班工程师会登录运维系统（包括监控系统、预案系统等）对报警进行定位、处理，这些行为会体现在各种运维系统的访问日志中。通过收集这些日志，就可以对每条报警的处理情况进行分析：如果在收到报警后的一段时间内访问过运维系统，可以认为该报警得到了关注，反之就认为该报警没有得到关注。汇总一段时间后，就能够筛选出关注度较低的报警策略，即为无效报警策略。

报警值班与逐级通告机制

百度监控系统（Argus）报警通路帮助运维团队建立值班机制，支持配置值班表，并设定交接班时间、值班周期等，值班系统会按周期自动轮转，并以短信、邮件等形式在交接班前通知接班值班人。为了保证核心报警得到及时有效的处理，Argus中还建立有逐级通告机制，支持配置多个通报升级时间和通报方式（电话、短信等）。报警发出后，值班人必需及时认领报警，超时未认领会按照配置升级并通告。下图就是一个值班和逐级通告配置的例子。

报警自愈机制

很多报警都有明确的处理预案，报警发生后，值班工程师登录机器或者中控机执行预案（脚本）就可以完成这类故障的处理。比如，清理磁盘这类操作，可能就是一个简单的删除日志和tmp目录的脚本。如果这类报警可以完全自动处理，无需人工干预，就能够大量节省人工成本，同时减少报警量。因此，Argus报警系统提供了报警回调机制，在报警发生时可以回调预案处理脚本。

上面介绍的这类自愈场景比较简单，这类预案往往对于程序没有任何干扰，可以“无脑”执行预案脚本即可。对于更复杂的场景，值班工程师往往需要根据服务的整体情况来调整预案。例如当某个实例异常需要重启的时候，需要综合判断其他实例的状态才能确定是否以及何时可以重启该实例，如果无脑重启可能会给服务造成损失。这种场景的自愈操作可能是有损的，需要对服务整体情况有一个判断才可以执行预案，Argus报警系统为此提供了另外一种回调机制。在发生报警时，报警系统会把相关的报警策略、实例的状态都统一发送给一个中枢决策服务，由中枢决策服务统一做出判断。

作者介绍：
运小博，百度高级研发工程师，从事有关运维数据分析相关的工作，负责异常检测系统和报警收敛等工作，重点关注时序数据分析、故障诊断等相关领域技术。

本文转载自公众号AIOps智能运维（ID：AI_Ops）。

原文链接：

https://mp.weixin.qq.com/s/vODNelOyTwyciI-6sYBUtA

创作场景

我在百度对抗报警风暴（二）