# 一分钟精华速览 #

B 站的业务规模和用户群体不断扩大，对于服务的稳定性和可用性的要求也日益增高。这就需要 B 站的监控告警系统能够及时、准确地发现和定位问题，以便尽快解决，维护好用户的使用体验。

本文是对 B 站在告警监控系统上的一次重要迭代和优化的详细记录。文章详细阐述了 B 站对告警平台设计思路和优化迭代，以及在实现过程中遇到的问题和解决方法。特别是对于告警定位的精准性和定位效率的提升，文章给出了新的设计方案和实践方法。

作者介绍

哔哩哔哩资深开发工程师——王程田 

TakinTalks 稳定性社区专家团成员，哔哩哔哩资深开发工程师。2020 年加入 B 站先后负责事件平台，链路追踪，AIOps 及告警平台方向技术演进 &平台迭代。完成了新一代告警平台落地，达成了 99 分位一分钟内的异常端到端发现，实现了人均告警从每周 1000+条/人到 70+条/人告警治理上的突破。

温馨提醒：本文约 6000 字，预计花费 8 分钟阅读。

后台回复 “交流” 进入读者交流群；回复“1130”获取课件；

背景

在 B 站的多元化业务中，告警平台起着至关重要的作用。无论是视频播放、弹幕发送、用户评论、直播间管理，还是后台的内容审核、数据统计等，都离不开系统的稳定运行。告警平台可以实时监控这些业务系统的运行状态，一旦出现异常，就会及时发出告警示，使运维人员能够迅速定位问题，及时进行处理。

然而，维护这些业务的稳定运行并非易事。从告警发生的前、中、后三个阶段，即生产端、传输端和消费端来看，B 站的告警平台设计都面临着不小的挑战和复杂性。

考虑到这些业务需求和复杂度，我们着手对 B 站新一代告警平台进行了全面升级，结果达成了人均告警减少 90%，根因分析准确率高达 87.9%的突破。在本文中，我将概述新一代告警平台的设计理念，并重点分享该平台在告警降噪和告警智能化分析方面的实施策略。

一、告警平台做了哪些重点设计？

1.1 业务核心诉求

在告警平台的设计和迭代过程中，我们不断收到各类业务需求。总体上，这些需求的核心都集中在“以质量为中心，及时发现并处理异常，确保业务稳定性”。具体来说，需求场景可划分为风险场景和故障场景。在风险场景中，需要提前感知并有效应对潜在问题；而在故障场景中，需要迅速发现线上问题，及时响应，以实现快速恢复。

在满足这些业务需求的过程中，我们提炼出三个核心诉求和目标：

• 有效性：我们期望所有收到的告警都是有效的，即每次接收到告警时，都确实存在异常，而且这条告警对当前的接收者是具有意义的。

• 及时性：对于高优先级的异常，我们希望能在第一时间触达并被用户感知，以便他们能够及时采取行动进行处理。

• 覆盖性与跟进：我们期望实现告警的全面覆盖和跟进。从用户的角度来看，他们希望所有自己负责的业务或应用的场景都能被告警覆盖，同时，他们也希望能了解不同场景的告警覆盖情况。当规则产生异常后，用户需要有一个便捷的方式去快速处理并跟进解决问题。

1.2 告警平台详细设计

1.2.1 闭环模型

在告警平台的详细设计中，我们基于前述的目标和业务需求，构建了一个闭环模型。这个模型旨在保证各关联方的积极参与，从而推动目标的持续改善。特别的，告警定义和告警治理是模型中的两个关键环节，因为它们决定了告警降噪和召回效果的优劣。

接下来将详细介绍 B 站告警定义、检测、通道侧功能的设计。重点是告警处理、根因分析以及告警治理侧的实践内容。

1.2.2 告警接入

在告警接入环节，主要区分了三个场景，这些场景的设计可以覆盖业务对于告警接入的大部分需求。

1）面向平台的场景

我们为平台覆盖的告警场景提供告警规则和模板的开放接口能力，支持多租户规则集成。不同租户可以基于预定义的模板进行配置，可以在业务申请或者注册资源时，快速完成告警的定义和覆盖，整个过程成本低，便捷性高。

2）面向自定义场景

我们为业务直接开放告警规则定义，包括规则的触发条件配置、表达式及通知策略的配置。

3）面向第三方事件

我们开放事件集成能力，用户可以通过注册事件完成准入，主动触发方式发送到告警平台，告警平台完成后续闭环的处理。

1.2.3 告警计算

我们设计了一个分布式的告警计算引擎，实现了多级的调度。基于线上全量生效的规则，进行全局调度，将告警的场景、可用区调度到不同的可用区和计算集群下。在同一个计算集群下，进行本地调度，将任务调度到不同的计算节点，实现负载均衡。计算节点会周期性地检测数据判断告警是否触发，触发后将投递到告警通道。

1.2.4 告警通道

主要做降噪、渲染、分发，以实现准确的投递和快速的触达。对于引擎侧产生的告警事件，在通道会生成告警消息，然后先经过降噪模块，依次完成通知窗口拦截、通知频率拦截、接警拦截、静默拦截、抑制拦截、告警聚合等。接下来，经过告警渲染分发模块，完成渲染接收人、渲染通知通道、渲染通知模板，最终触达到用户并更新告警的投递状态。

二、告警治理有哪些实践心得？

下面我将主要阐述 B 站在告警治理的实践过程中，如何推行告警治理策略，降低告警噪声，以及提高告警的有效性。

2.1 告警治理背景

过去一段时间里，B 站的告警通知泛滥问题，对技术团队和平台来说，这已经成为一个多年的困扰，也是一个较大的痛点。一方面，随着稳定性问题的出现以及新平台的接入，告警规则和配置不断增加；另一方面，又缺乏有效的告警治理和运营分析机制。这导致告警数量越来越多，很多用户也不会去主动治理告警，反而选择设定免打扰。最后，真实的风险和异常往往被淹没在众多告警中，无法第一时间被感知到。

用一句话来概括，就是“太多的告警就相当于没有告警”。

2.2 问题分析

我们认为，这主要由以下四部分原因导致：

1. 告警定义不合理：很多规则缺乏有效的维护，大量的规则在触发后，并不代表有异常发生，业务也不会去处理。此外，有些告警的粒度太细，导致同一异常触发后产生大量的告警，放大了整个通知的影响。

2. 通知人数放大：由于历史组织架构的变更或临时排查问题，定位权限相耦合，导致服务树长期缺乏治理，造成告警通知人数的大幅度放大，经常发给一些无关的人员。

3. 缺少分析治理工具：虽然大家都知道告警太多了，需要治理，但是却没有头绪，也没有合适的平台能力帮助他们分析告警主要集中的部分，从而进行有针对性的治理。

4. 缺乏有效的运营机制：大家对治理告警的动力不足，同时也缺乏有效的机制和规范约束。在历史上可能经过一些短期治理后，告警又出现反弹，治理效果就不复存在。

2.3 告警治理的三个阶段

在分析了告警泛滥的原因后，我们开始了告警治理，这个过程主要分为三个阶段。

第一阶段：目标设定

经过多轮的会议和讨论，我们确定了告警数的指标，将原先每周超过 1000 条的告警数量降低到每周 80 条。这个目标在初始阶段看起来几乎是不可能完成的。然而，我们认为这 80 条告警是一个业务人员能够逐条响应处理的合理范围。于是，我们坚持以这个目标去执行，并尽力去达成。

第二阶段：数据分析

我们将告警数据集成到数据仓库中，提供了多维度的分析视图，为告警治理提供了数据支持。通过计算公式来确定影响因子，公式基于告警通知数量，即：告警通知数量=告警数*每次触发通知的人数*降噪系数。这个公式帮助我们明确了治理的方向和重点。

第三阶段：治理动作

在这个阶段，我们开始执行一系列治理动作。

首先，优化了告警项，与 SRE 和平台同事一起评估了默认告警项的合理性，对无效的告警项进行了关闭处理。对于一些不合理的告警项，我们评估并优化了其表达式和默认阈值等条件，以降低告警噪声并提高告警的有效性。

其次，为了解决通知人数放大的问题，优化了告警接收人的设置。我们深度参与并推动了服务树研发和负责人角色的校准，并推出了值班，升级等能力，以缩小告警的通知范围，有效地降低了通知人数放大的噪声。

最后，丰富了通道的告警降噪策略，支持了规则组的微调拦截能力，以及多维度下的告警汇总和聚合能力，从而更高效降低了告警噪声。

2.4 告警治理过程经验总结

在进行了一系列的告警治理行动后，我们对治理过程进行了总结和思考。主要从以下三个方面进行分享：

1）异常召回是底线

在整个治理过程中，集中处理的主要是无效的噪声告警，然而，绝不能忽视真实且有效的告警。在治理中，我们始终坚守一个原则，即不能牺牲异常的召回率。因此，我们将注意力集中在那些持续触发、重复触发以及异常放大等不合理的规则上，以及 Top 级别的规则上，并对这些问题进行专项治理。

2）运营推进不可少

实际上，治理过程就是一个运营推进的过程。在这个过程中，创建了数十个群组，制定了无数的治理、推进和跟进文档，以确保整个密集且强制性的告警治理工作的落实。同时，也与各个场景平台以及 SRE 进行了紧密合作，共同推动了告警治理工作。

3）分层分级抓重点是方向

我们借鉴了毛剑老师的理念，强调分层分级，抓住重点，尤其是保证业务可用性的核心告警。对于事件类的告警，建议记录并可查询，以避免淹没其他重要的告警通知。对于一些不适合直接通知业务侧的依赖告警，建议通过关联的方式来呈现，这样可以有效地降低告警的噪声。

2.5 告警治理效果

近半年地推式的告警治理，告警数据得到显著改善：

• 中位数告警 1000 次/周减少到 74 次/周，减少到原来的 7.4%；

• 整体告警通知数从治理前 300w+减少到 22w+，减少到原来的 7%；

• 人均告警通知数从 1600+减少到 140，减少到原来的 8.8%；

2.6 建立长效治理机制

为了确保告警治理所取得的成果能够持续稳定，我们构建了一套长效治理机制，具体包含以下三个方面：

1）便捷治理分析工具

包含了一个告警治理分析大盘，它被集成在告警平台上。这个大盘支持从业务、个人和公司等多个视角，通过多个维度对告警的分布和趋势进行分析。此外，我们还利用了一些治理工具，为快速治理提供了必要的能力。

2）数据报表订阅

我们与 SRE 各个组件平台达成了共识，制定了共同的目标，并生成了各类数据报表的订阅。持续跟进这些报表，以防止告警的恶化，并持续进行告警治理。

3）接入管控

针对新接入的规则和平台场景，增加了一些告警数据接入的人工校验，以及平台侧的校验和噪声监控。对于一些不合理的规则，我们会建议对应的接入方进行优化，以保持告警治理成果。

三、告警根因分析是如何设计和应用的？

结合当下业界广泛运用的前沿技术，例如异常检测、智能降噪、智能合并策略以及根因分析等，我将重点分享 B 站在根因分析方面的实践和实战经验。

3.1 根因分析背景

随着 SLO 体系的日益完善，更多的业务被接入到 SLO 体系中。这使得我们有了明确的异常定义和触发对象，能够更精确地实施根因分析。

此外，B 站已经设定了 “1-5-10” 的目标。目前，已经通过优化告警计算采集和通道，实现了 99 分位端到端一分钟内的问题发现。然而，对于 5 分钟的定位，仍存在一些瓶颈。定位过程过于依赖人工经验，存在一定的不确定性。人工专家经验因人而异，同时受场景影响，导致定位效率也不一致。另外，由于平台能力的建设和交互，以及一些极端情况下的响应延时，如凌晨故障或者出差等场景，都会影响定位效率。

最后，用户需求的积累也在不断增加。随着业务和基础设施的增长，人们越来越关注告警定位的效率，并积累了大量定位告警的经验。因此，对于根因分析的需求日益迫切，同时，根因分析的实施条件也逐渐成熟。

3.2 根因分析设计

3.2.1 根因分析设计 1.0 版

首先，我们采用了以 SLO 告警为基础的设计方案，对微服务架构下的黄金指标进行定位能力的设计，这就是 1.0 版根因分析设计。整个设计方案主要包含三个阶段。

首阶段，我们监听 SLO 的告警触发，关联错误的范围和数据，然后基于这些数据分析日志指标，挖掘出异常的维度。例如，错误可能集中在特定集群的某个实例下，或者某个上游请求的某个接口。

第二阶段，我们根据这些错误维度，对应用侧的链路调用进行关联，找出异常期间的异常链路。通过聚合分析，能区分出耗时和错误的场景，通过关键路径分析和剪枝下钻的方式，定位到异常链路下的异常节点。

最后一阶段，将定位到的异常节点映射到知识图谱中，通过数据图谱关联到相关的数据库、缓存、消息队列、容器、机器、交换机、机柜、机房等信息。然后，结合异常、告警、变更等信息，通过关联分析模型进行打分推荐，最终推荐出可能的 Top 根因排序。

尽管这个 1.0 版的根因分析设计在某些场景下的准确率可以接受，但是它仍然存在一些瓶颈。

3.2.2 根因分析设计 2.0 版

在设计 2.0 版的根因分析时，我们进行了全面的调研，深入了解了业界资深的 SRE 和业务同事们在定位问题时的过程。

总结下来，这个过程主要是：在告警触发后，根据专家的经验，关联到具体的异常事件；然后再根据这些经验，分析这个异常可能由哪些原因导致，并找出这些原因的相关指标和日志等观测数据；最后，通过观察这些数据，判断出导致异常的根源。

在设计 2.0 版的过程中，我们力求将这个过程普遍化，并构建一个异常知识图谱，将专家的经验沉淀下来。同时，也开放了根因分析的集成和知识目录的功能，提供通用的根因分析能力。

根因分析的实现主要围绕知识的定义。这里的知识主要是基于异常节点定义。每个异常都会定义在具体的某个实体节点下，例如某个应用或某个数据库的集群实例。每个异常都会关联到具体的数据节点，比如日志、指标、告警等，通过这些数据我们可以检测和判断异常的发生。同时，异常之间也存在传导关系，一个异常可能由哪些异常导致，这些异常之间的传导链路和关联关系是怎样的。这就是我们在知识工程中定义的整个知识结构。

这种基于知识图谱的根因分析方式，很好地解决了 1.0 版中遇到的问题。使我们能够更深入地理解异常发生的原因，更准确地定位到问题的根源。通过将专家的经验进行系统化的沉淀，不仅提高了问题定位的效率，也使得知识的传承和积累成为可能。

3.2.3  AIOps 算法支持

根因分析的能力建设，离不开 AIOps 算法的支撑。目前，我们已经构建了一个全面的算法体系，设计了指标、日志、事件、链路等多个场景。同时，也根据不同类型的数据，支持了时序预测、异常检测、指标分类以及日志聚类、多维下钻，和事件聚类、链路分析等多个场景的算法能力。

3.2.4 关联分析模型升级

在关联分析的过程中，我们将异常图通过特征构建、模型加载，基于模型推理预测并打分，最终推荐出异常的根因和传导路径。特征设计包括：时间依赖特征、图关系/距离特征、因果特征、路径相似特征、事件类别特征。

模型构建方面，在初期主要是基于冷启动的方式，预定义了一些异常之间的传播系数。随着样本标注数据的增多，开始进行模型的训练，并基于模型进行推理和推荐。此外，我们也支持 GBDT 模型，以进一步提升关联分析能力。

3.3 难点和重点

在根因分析的过程中，我们面临着一些难点和重点。难点主要在于，如何有效评价推荐的根因，以及如何获取用户的准确率和评价数据。这对于评估不同版本，以及根因分析的准确率和有效性，以及帮助模型进行迭代至关重要。为了解决这个难题，我们进行了以下四部分工作：

在整个过程中，一个重点是围绕专家经验的收集和构建。我们会与不同业务和 SRE 同学深度沟通，梳理相关的异常知识和专家经验，完成这部分知识的定义。

对于组件方面，我们会与相关同学持续完善这部分知识的定义和构建能力。针对一些特殊场景，也会提供外部专家经验的集成方案，提供根因分析的集成能力和接口，让外部的根因也可以通过分析能力完成，实现人工告警的推荐、展示和评价。

3.4 案例分析

3.4.1  上游流量突增导致服务限流，可用率下降

在这种情况下，可以基于告警关联到具体服务的 SLO 异常，并且下钻得到具体的异常接口和错误。同时，通过异常关联分析可以检测到上游的流量突增，明确具体哪一个入口的流量突增。有了这些信息，业务侧可以对上游的服务进行一些限流的配置并进行修复。

3.4.2 下游变更导致服务异常影响网关接口可用率

可以通过根因分析关联到具体的链路，并关联到具体下游的异常和变更。最终，可以推荐出 AI 服务的变更是影响网关接口的主要原因。业务同学可以快速找到对应的变更人，然后进行排查和回滚等止损操作。

3.4.3 下游 Redis 请求异常影响服务接口

可以通过内部分析以及异常关联到具体的服务，并构建起异常的传导路径。同时，可以推荐出具体的异常请求耗时和日志。此外，业务侧也可以与相关组件的同学一起进行更深入的定位。

3.5 效果评估

根因分析已经落地，并取得了一些成效——

根因分析次数：20652/天

准确率：87.9%

召回率：77.5%

分析耗时 95 分位：10s

平均分析耗时：4s 内（这意味着，在告警发出后，平均仅需 4 秒钟就可以推荐出根因，业务人员打开告警卡片就可以直接看到对应的异常根因。）

四、总结与展望

设计告警平台时，需要考虑到多种多样的业务需求和不同的应用场景。理解这些需求的本质，然后基于这个本质来构建平台的能力以及关键功能模型，并设计出闭环逻辑，以此来设计出更贴近业务需求的告警平台。其次，告警治理过程是必不可少的。无论告警的数量多少，只有通过完善的告警治理机制，才能使整个系统的闭环优化规则的定义，持续提升告警的有效性，发挥告警的价值。最后，告警与人工智能的结合是未来的发展趋势。通过深度结合的一些能力，可以提升故障发现的准确率，减少定位和恢复止损的时间，为质量管理和系统稳定性提供保障。（全文完）

Q&A：

1、这个告警治理是否主要靠人力筛选减少规则？

2、业务侧的告警关联降噪可以举个例子吗？是在监控侧关联还是在告警侧关联？业务告警可以和基础告警关联吗？

3、告警后有进一步的自动分析场景吗？

4、监控告警通知的发送状态和效果怎么管理？怎么处理通知失败或异常的情况？

5、在告警合并方面，高优告警怎么不被淹没？同时保证低优告警的质量巡检？

6、怎么优化根因分析的效率和准确性，来支持实时分析和批量处理呢？根因分析过程中，大量的数据和日志信息怎么管理和存储？有哪些最佳实践和经验可以分享？

以上问题答案，欢迎点击“阅读全文”，观看完整版解答！

TakinTalks 稳定性社区，12 月 14 日 19:30 直播

已结束

面对告警风暴，如何实现超过 98.5%的有效降噪比？一起学习：转转一体化监控系统落地实践

视频号

TakinTalks 稳定性社区，将在 12 月 21 日 19:30 直播

预约

如何有效降低成本 20%，实现秒级监控覆盖超过 10 个业务场景？一起学习：适配多云环境，货拉拉智能监控平台的设计与实践

视频号

！！重要通知！！

TakinTalks 社区第二本印刷物《SRE 可靠性体系建设实战笔记》已正式启动，现公开征集共创作者，一起布道 SRE！

招募对象：运维负责人、SRE 负责人、架构师等稳定性相关职位，团队负责人/总监级以上

第一期参考：10万字干货：《数字业务连续性提升最佳实践》免费领取｜TakinTalks社区

若您有意成为本书作者之一，请您与我们联系，获取本书目录。

添加助理小姐姐，凭截图免费领取以上所有资料

并免费加入「TakinTalks 读者交流群」    

声明：本文由公众号「TakinTalks 稳定性社区」联合社区专家共同原创撰写，如需转载，请后台回复“转载”获得授权。

更多故障治理内容

「好文推荐」

👉美图是如何搭建压测监控一体化平台的？

👉故障复盘后的告警如何加出效果？

👉去哪儿是如何做到大规模故障演练的？

👉美图SRE:一次线上大事故，我悟出了故障治理的3步9招

👉破坏系统是为了更稳定？混沌工程在去哪儿的4个阶段实践

👉监控告警怎么搭建比较合理？

📢点击【阅读原文】直达 TakinTalks 稳定性社区，获取更多实战资料！

可观测 10

SRE 实践 19

可观测 · 目录

上一篇去哪儿如何实现故障率降低 65%？技术+管理的数字化度量体系实践

阅读原文

​

喜欢此内容的人还喜欢

去哪儿如何实现故障率降低 65%？技术+管理的数字化度量体系实践

TakinTalks 稳定性社区

不喜欢

不看的原因

确定

• 内容质量低

• 不看此公众号

去哪儿“技术债”偿还实践：如何高效、低风险砍掉 50%无用代码?

TakinTalks 稳定性社区

不喜欢

不看的原因

确定

• 内容质量低

• 不看此公众号

七年 4 个阶段：滴滴可观测架构演进与实践

TakinTalks 稳定性社区

不喜欢

不看的原因

确定

• 内容质量低

• 不看此公众号

微信扫一扫关注该公众号

人划线