本文根据谷林涛老师在〖deeplus直播：甩掉技术债包袱，B站的SRE体系建设与转型实践〗线上分享演讲内容整理而成。（文末有回放的方式，不要错过）

1）业务痛点

沟通群里有各种各样的告警，如基础设施的告警、业务接口的告警、中间件的告警，客情舆情的用户反馈。这些信息通过不同的形式方式以及依赖每个告警工具的建设，推送在群中，导致整个群信息杂乱，处理告警无从下手。

2）问题所导致的痛点

3）痛点引发的新问题

研发、老板、SRE三大角色需要处理这些风险，各自的困难如下图：

 

对于传统预警告警的处理，本质上是处理并解答四个问题：有哪些人？采取什么机制？有哪些信息？用了哪些平台工具？然而在实践过程中，可能会遇到各种各样的挑战。

缺乏标准的SOP应急流程，导致SRE、研发、老板三个角色在问题发生出现时，对预警、故障的处理完全依赖个人的经验能力。对于一个具有丰富工作经验的同学来说，不会在处理故障时遇到很大障碍。但对于一些工作时间不长、没有遇到过线上问题的同学来说，处理故障完全依赖个人理解和能力，这可能导致一些“非标”的动作，或遗漏重要的应急步骤。最终，轻则影响恢复市场，重则扩大故障影响面。

在整个操作过程中，由于事态比较紧急，可能会存在操作过程不规范或信息未能及时同步的情况，使得大家双向操作。其本质问题是实时进展无法同步、信息不对称，最终放大故障的影响面。

一个标准预警的发生，SRE团队、中间件团队、业务团队和基础设施团队都可能参与其中，传统告警无法协同不同角色在各自领域内解决问题。

处理方案：

传统告警基本没有事后处理，缺乏对有效占比、原因分类、响应时长、完结时长等一系列标准操作的信息数据度量。数据度量的缺失就意味着难以进行对应数据治理，导致问题处理后，缺乏数据沉淀，也难以避免类似问题再发生。此外，如何判断告警的有效性，如何治理等问题都缺乏对应抓手和处理依据，这是传统告警存在的困局。

基于上文的困局，我们提出了“风险”的概念。什么是风险？它与故障有什么区别？以下将详细介绍。

整个风险的生命周期基本实现了全闭环，先风险发现，然后跟踪和定位风险，最后风险打标。

风险挖掘需要定义风险。风险覆盖人工、客情、舆情、工单系统等方面，也可定义为通过业务监控、中间件监控或基础设施监控发现的风险。风险不等同于故障，故障严重影响业务的可用性，而风险意味着可能对业务产生小部分影响，但还未扩大至较高等级的影响，无需通过标准的故障流程来处理。我们通过告警系统或人工上报打通流程，发现对应风险。

定义和发现风险后，就需要跟踪和相应风险。基于风险响应，我们制定了一套标准的SOP流程。

这个风险如何产生？根因是什么？这些都是大家需要关注的重点。

根因定位一旦完成，就需要采取快速恢复的手段。抖动则无需处理，但它可能是一个action，需要后续优化代码，执行预案，或执行一定的运维操作，比如重启等行为。快恢操作后，若能确定业务完成了闭环的风险处理，就意味着风险完结。如果风险还未完结，基本上可以确定已升级为故障。

风险处理完毕后，最后进行风险打标。有了打标才能更好地实现闭环，回溯到第一步的风险挖掘。

基于风险的定义，我们提出了一个“风险场景”的新概念，它是风险预警环节的核心因素。

针对上图右方的三种异常，不同人员的关注视角不同，研发和SRE一般关注中间件异常和基础设施异常，因为它有可能影响业务，也有可能不影响业务。如果不进行妥善处理，后期有可能导致业务异常。至于业务异常，所映射的是稳定性可能出现问题，业务也可能受损。因此不仅研发和SRE需要关注业务异常，老板和稳定性负责人也需要关注。

风险场景的实体关联了三个要素，分别是规则表达式、监控指标和告警、预案和快恢。

综上所述，我们提出了一个对应的配置页面，除了场景外，还会引入值班组和预警节点。预警节点即CMDB，用于定义整个业务、部门或应用预警的节点。

通过场景的定义、值班组和预警节点的概念，我们整合出了风险预警的三个核心概念，即哪些值班组在哪个预警节点要处理哪些场景的异常。有了该定义，在事前就能较好梳理风险点的具体位置以及人员职责，避免上文所述的告警混乱和渠道不一致问题。

场景触发异常时，第一个消息就是报警推送。收到告警后，我们会在群里推送一套标准化流程的卡片，标准化的格式是标题内容、告警时间渠道以及最近变更成员，然后进行一定的标准行为操作，比如遇到风险需要接手并响应，加入一个应急的协同群。通过对接不同的监控系统，我们可以清晰定义监控和告警的实体以及用户关心的内容。针对来自MySQL、SLO、Alarm、公司内部前端的告警和普通的告警，会适配不同的模板，由渠道统一推送。

主要贡献：统一流程、整合能力、提供协同、适配渠道、精准触达、

由于我们已经明确“标准SOP体系下的风险处理”定义，所以告警出现后，自然有人接手。之后再进行转交，并在排查过程中机型信息的录入与同步，也可以告知他人自己遇到的问题，这些信息都会在群中同步，如此便实现了事件的闭环。我们还提供了催办升级能力，同步广播进展，进行统一的度量。若整个群做到了以上几点，那么在老板视角就可以及时获知问题，是否有人处理和响应等。研发也能互相协同，因为一个平台由多个研发负责，在这个平台中我们可以了解问题的跟进详情，问题根因来自谁等，可便于在群中做进一步的沟通。

主要贡献：闭环事件、催办升级、广播进展、统一度量、信息透明

除了简短的卡片信息外，还会提供一些对应的技术指标，比如针对SLO的告警，我们提供了一个相关接口错误码的指标时序图，以方便研发在预警详情中通过一个页面查看过往大量平台的信息。表面上是平台整合，但实际上是通过标准的SOP流程明确定义需要关注的平台，并且借助算法和工程能力查出具体的指标错误，同时提供一定的根因分析和预案快恢能力。根因分析和预案快恢的完整行动路线都会通过信息同步的方式在群中进行协同处理，以避免由于信息不一致而导致操作失误。

方便用户在群中快速得知哪些预警仍未完结，通过一个较为标准的处理流程，就能妥当地处理风险。即使一个研发缺乏一定的风险处理能力，但借助这套产品也能极快地处理风险，降低整个业务的风险。

对于整个风险预警产品，我们不仅做了标准的SOP流程，还从变更层面挖掘了信息的拓扑能力。

通过这些覆盖，我们在整个事中可以做到赋予研发更多处理问题的手段和能力，借助变更覆盖和监控覆盖，结合拓扑覆盖，我们就能尝试帮助用户定位风险的诱因。

图右侧展示了风险预警的定位能力以及对应的覆盖能力。通过定位，能将内容快速推送到群中；通过接口的监控，告知指标在同环比增加的比率，最后帮助用户发现问题。

如果上下游出现异常，拓扑覆盖也能定位。若你的应用发现异常，我们会帮你检测有无做过对应的变更，若无变更，则通过拓扑信息侦测周围链路上发生的变更，给出一定的推荐，帮助用户找到对应的人员，从而快速解决问题。

而在快恢层面，我们也会同步所有信息，在整个群中做协同，以避免研发在重复操作或者信息不同步不对称的情况下，导致故障或风险的二次发生。

有了恰当的配置和事中的处理，通过相对简单的方式便能度量事后的数据。

接手时长、接手率、完结时长以及完结率是四个非常核心的技术指标，透过这些指标即能感知每个部门的情况。我们会根据这些情况去沟通，加深对产品的了解，思考产品能够持续优化的各个方向和层面。

事前涉及基础设施的风险覆盖、中间件的风险覆盖、应用的风险覆盖以及SLO的风险覆盖，事中的核心度量就是接手率、完结率和转故障数。事后则会度量有效率和场景治理。

场景治理包括两方面，一是正召回，二是负向召回。正召回即召回误告的告警，负向召回即需要填充未被发觉的告警。事后的度量完成后，整个风险就能产生一个新的闭环，从而解决风险的遗漏风险、告警的失效，以及人员的治理问题，最终就能解决整个风险。

 

 

2.风险预警技术架构

 

最底层是人员组织的管理，用于表明公司的人员信息；CMDB即预警节点的节点能力，也会搭建基础服务，以便为上层服务提供权限。场景管理再往上，则会通过一些微服务（如核心的场景管理）实现整个场景的数据配置化能力。

通过整套技术架构以及领域划分的设计，它的横向拓展性相对会更好。针对后续的一些用户诉求，不管是SRE老板、运维稳定性负责人还是一线研发，都会在这个产品中承担不同的角色，并满足不同的诉求。

Q1: 影响范围、上下文和诊断信息等告警信息是否都会给出？

A1：我们有一定的拓扑能力，会把每一个节点封装成一个对应的实体，这个实体会关联对应的中间件依赖以及上下游的依赖。当我们接入一个告警信息时，它的上下游信息会根据HTTP和RPC的标准指标将红色的异常节点进行定义，在告警信息中给出对应的诊断。

由于它依赖指标的计算所以在技术上使用了异步模式，当它推送告警信息后，如果它在1~2分钟内判断出大概的影响范围和上下文，就会补充诊断信息，将可能导致告警的原因告知用户——自身应用导致还是上游检测出的依赖方的调用出现了环比的突增？最终都会给出诊断。

Q2：如何确认预警告警本身的准确性和有效性？

A2：首先我们会通过风险的挖掘，告知用户具体的风险。在出现风险告警时，研发确实会接收到大量的无效告警，但在我们的处理过程中，会有一个闭环，在风险度量时就能看出哪些是误告率极高的告警，所以这时透过周报就能看到相关信息，从而筛选出准确有效的告警，并通过数据的闭环帮助用户做对应的治理。

你也可以一键优化规则，或者通过屏蔽无效告警、比如代码屏蔽errorCode的方式来确认，比如用户未登录而执行某些结果导致鉴权报错，针对这种情况就可以用上述的方法。

因此，数据闭环的作用是驱使研发自闭环地判断告警本身的准确性和有效性，并据此做对应的治理，这是整个风险预警的重要贡献之一。

Q3：预警对故障的容忍度如何，怎样设置阈值？

A3：首先，中间件异常和基础设施异常也有可能不影响业务故障，比如四台机器挂两台，如果流量不高，则业务上可能无感知，我们会把这方面划分在预警的领域内。至于容忍度，则需要SRE制定一个标准的SLI，因为它可能通过pv/uv、或者一些资损得到一个对应的结果，因此若SLI认为某个指标的成功率低于90%则为故障，那么对预警而言，可能就会将值设置为95%或96%，具体基于研发对自己系统业务上的规则定义。

注意以下两点：容忍度必须比故障更高一些，比如故障的指标是90%，你就可以设置95%时发出一条预警，思考低于95%时是否需要开始介入，以避免发生更进一步的故障；比如宿主机发生异常，或者整个中间的链路上分支环节上出现异常的时候，可能还未对故障的指标产生影响，通过预警就能迅速容忍故障的发生。这就是它能防控故障的原因，因为它做到了对场景业务更为精细化的管理。

Q4：发生雪崩效应大面积告警故障时，能否快速定位故障源，具体如何实现？

A4：无论从内部复盘还是整个行业的经验上看，绝大部分的大面积故障都源于两方面，一方面是变更，另一方面则是运维的操作，运维操作也可以定义为变更，一个是发代码，一个是发配置。

基于这两点，我们接入了变更的整个拓扑数据，还接入了CMDB。CMDB是配置时的拓扑信息，运行时则是通过分析 Discovery数据拓扑—一个链路的实时动态和调用关系，将它们结合分析，基本上就能基于告警的爆炸中心找到对应上下游的变更情况，以及对应的核心指标。以应用为例，我们定义了HTTP和RPC，就能快速定位可能存在的故障源，不过这只是一种可能。整个底层模型是一个拓扑的树形结构，当它发现最顶层的异常时，通过分析依赖关系可以通过快速找到对应的故障点，因为我们认为往下都是果，最顶层才是因。

Q5：为什么要有风险的概念？用这套流程来做故障处理不是同样可以吗？

A5：风险和故障之间有比较明确的界定，不影响业务的异常（如中间件的异常）更需要研发关注。比如我有六个下游做同一件事情，每个下游是六分之一的分流，且有两个下游异常，这时业务并不感知，但是它可以通过风险来处理，因为六个业务中有两个供应商可能异常，这需要我们定义。

风险有可能影响业务，但不足以启动整个故障的流程处理。所以我们提出风险自闭环能力，它并不是一个管控手段，而故障更多的是一种行政管控手段，可以将它理解为一个奖惩机制。你触发了故障，就要按照标准的流程处理，必须第一时间解决问题，必须要复盘，最后计入稳定性分析，可能还会有各种各样的挂钩，但风险始终是自闭环。

故障确实有部分协同与风险一致，但在数据度量以及对应的手段上，故障本身不需要接入一些中间件、基础设施或者指标自定义的告警，它接入更多的是强势的业务管理，比如交易成功率低于多少，下单成功率或者弹幕的发送成功率低于多少等，这是与风险的最大区别。

Q6：事件变更如何要求所有业务的变更都去变更平台录入变更信息？若不录入，他们就无法进行变更吗？

A6：我们不会找所有的业务，而是对接整个公司，比如应用的发布平台、编译平台以及配置的发布平台，以及数据库的DDL变更，把整个变更平台的信息视作标准化的结构录入。

Q7：故障的影响范围如何快速评估？

A7：故障影响范围的快速评估主要通过四种方式，第一是监控指标，整个业务会不断地在应急协同群中反馈哪些业务受影响。第二种，比如我做了网络变更，导致网络异常，但我知道网络有可能会影响哪些业务，所以故障的影响方本身也可以做到影响范围的快速评估。第三即拓扑能力，它可以快速拉出整个链路的影响范围。但在实战过程中，如果遇到了大故障，我们的定位系统压力极大，基本算不过来，这种情况就无需再定位，因为影响面太广，大家基本已全部得知。第四种即客情，一旦出现大故障，在微博上必定会出现客情，产生一定的社会影响面，所以可以借助整个社会的反馈来做评估。

Q8：风险预警的定义门槛比故障更低，如何让技术人员对风险预警足够重视，又不至于被过多的预警轰炸到麻木？

A8：首先，我们产品的核心与故障有本质区别，故障更多的是一种管控手段，风险预警则是我们给研发提供自闭环风险的概念，也就是说，理论上研发对风险预警拥有接收自由，我们并没有强制研发一定要接收风险预警。

针对整个风险预警的定义，它是一个产品，用于帮助技术人员或者研发等不同的角色提高风险对应的管理能力。故障相对而言强制性更强，对公司来说可以称为一种政治手段。风险预警是一个产品化的能力，它帮助技术人员去做这个事情。技术人员可能是最底层的一线技术人员，也可能是技术人员的老板，希望通过风险预警提供一个抓手，提高整个团队对风险的管控能力。他也有可能是稳定性负责人，希望更快获知风险。

获取本期PPT，请添加群秘微信号：dbachen

↓点这里可回看本期直播