一、传统告警渠道的困局
1.传统告警——事前
1）业务痛点
沟通群里有各种各样的告警，如基础设施的告警、业务接口的告警、中间件的告警，客情舆情的用户反馈。这些信息通过不同的形式方式以及依赖每个告警工具的建设，推送在群中，导致整个群信息杂乱，处理告警无从下手。
日常告警：海量的数据内容复杂琐碎，包括业务和中间件的数据。由于效率不足，很多时候大家会直接静默，错过一些重要告警，最终导致问题没有被及时跟进，变成故障，甚至社会舆情。
网络舆情：不只是个人告警，网络舆情的数量也很庞大。在微博、知乎等一系列的公开场合每天都有大量网络舆情。这些客体的数据分布在每个平台的社交网络上，网络感知更快，但难以迅速触达研发和产品侧，错过最快的抑制时间。
业务客诉：即基于内部的业务客诉。客户通常通过热线、在线提工单的方式反馈问题，在线小二、客服将客户信息转发到相关群，通知大家处理。但实际上用户难以真正阐述问题，如果不做相关定性定量，可能在问题反馈初期无法定位问题根因，导致大面积的业务客诉，然后转化为重大舆情事件。
2）问题所导致的痛点
- 由于告警过多，过于复杂，导致告警疲劳；
- 孤军奋战：在传统告警中，每个人都相当于孤军奋战，因为网络只是舆情的输入端，而非告警。客诉在群中流转，日常告警则不断推送各种各样的渠道告警，但我们最终只是收到告警，不清楚这条告警通知了谁，有无得到处理，一切都是未知数；
- 存在信息偏差：由于组织架构调整，相关研发和运维人员的信息维护未必非常准确。收到告警的人可能无需收到类似告警，而本应收到告警的新成员，却未能收到；
- 数据离散：用户不清楚接收的告警数量，也无法分辨有效告警和无效告警，更无法判断告警的重要性，导致整个数据无法度量，各个视角（研发、测试、运维、老板）都无法感知自身业务的稳定和应急协同的成效。
3）痛点引发的新问题
- 沟通复杂：如果成员们认为收到的告警表明情况严重，则会在群里说一声，但是群消息非常多，因此在收到重要告警时大家可能察觉不到。
- 问题升级：沟通复杂可能导致告警疲劳，造成问题升级。若小问题得不到及时解决，积累后越来越严重，就会导致故障发生。
- 无法度量：由于渠道、产品不统一，无法跟进度量应急时效、有效及后续情况，所以无法评估并提升业务稳定性。
研发、老板、SRE三大角色需要处理这些风险，各自的困难如下图：
2.传统告警——事中
对于传统预警告警的处理，本质上是处理并解答四个问题：有哪些人？采取什么机制？有哪些信息？用了哪些平台工具？然而在实践过程中，可能会遇到各种各样的挑战。
- 缺乏标准SOP，研发处理过于依赖个人能力
缺乏标准的SOP应急流程，导致SRE、研发、老板三个角色在问题发生出现时，对预警、故障的处理完全依赖个人的经验能力。对于一个具有丰富工作经验的同学来说，不会在处理故障时遇到很大障碍。但对于一些工作时间不长、没有遇到过线上问题的同学来说，处理故障完全依赖个人理解和能力，这可能导致一些“非标”的动作，或遗漏重要的应急步骤。最终，轻则影响恢复市场，重则扩大故障影响面。
- 实时进展无同步，信息不对称可能放大故障影响面
在整个操作过程中，由于事态比较紧急，可能会存在操作过程不规范或信息未能及时同步的情况，使得大家双向操作。其本质问题是实时进展无法同步、信息不对称，最终放大故障的影响面。
- 人员职责不清晰
一个标准预警的发生，SRE团队、中间件团队、业务团队和基础设施团队都可能参与其中，传统告警无法协同不同角色在各自领域内解决问题。
- 多团队跨团队合作，缺乏协同能力
- 标准恢复操作涉及拉群、定位、观测、执行运维操作的平台众多，来回横跳影响应急效率。
处理方案：
- 观测定位：在实战过程中，一个事件告警产生后，首先不断地跳转大量平台，进行观测和定位；
- 预案快恢：类似重启、线上应用配置修改、数据库执行DDL、等常规手段，涉及平台极多。平台执行时难以及时通知整个内部团队，例如有人进行业务降级时，其他人可能并不知道；
- 应急协同：一旦出现严重的问题，大家会拉群沟通，如果跨团队，或者涉及多人的跨云协作则可能双方人员都会拉群。但实际工作中已有SRE群、研发群和处理临时问题的各种群，群的数量剧增，信息同步效率却不高。以上情况直接导致整个告警处理过程中出现一个极大的业务痛点——即大家无法做到信息对齐，问题会在处理过程中进一步被放大。
3.传统告警——事后
传统告警基本没有事后处理，缺乏对有效占比、原因分类、响应时长、完结时长等一系列标准操作的信息数据度量。数据度量的缺失就意味着难以进行对应数据治理，导致问题处理后，缺乏数据沉淀，也难以避免类似问题再发生。此外，如何判断告警的有效性，如何治理等问题都缺乏对应抓手和处理依据，这是传统告警存在的困局。
二、风险预警——闭环风险的全生命周期
基于上文的困局，我们提出了“风险”的概念。什么是风险？它与故障有什么区别？以下将详细介绍。
整个风险的生命周期基本实现了全闭环，先风险发现，然后跟踪和定位风险，最后风险打标。
- 风险发现
风险挖掘需要定义风险。风险覆盖人工、客情、舆情、工单系统等方面，也可定义为通过业务监控、中间件监控或基础设施监控发现的风险。风险不等同于故障，故障严重影响业务的可用性，而风险意味着可能对业务产生小部分影响，但还未扩大至较高等级的影响，无需通过标准的故障流程来处理。我们通过告警系统或人工上报打通流程，发现对应风险。
- 风险跟踪
定义和发现风险后，就需要跟踪和相应风险。基于风险响应，我们制定了一套标准的SOP流程。
- 风险定位
这个风险如何产生？根因是什么？这些都是大家需要关注的重点。
根因定位一旦完成，就需要采取快速恢复的手段。抖动则无需处理，但它可能是一个action，需要后续优化代码，执行预案，或执行一定的运维操作，比如重启等行为。快恢操作后，若能确定业务完成了闭环的风险处理，就意味着风险完结。如果风险还未完结，基本上可以确定已升级为故障。
- 风险打标
风险处理完毕后，最后进行风险打标。有了打标才能更好地实现闭环，回溯到第一步的风险挖掘。
基于风险的定义，我们提出了一个“风险场景”的新概念，它是风险预警环节的核心因素。
1.风险告警——事前
针对上图右方的三种异常，不同人员的关注视角不同，研发和SRE一般关注中间件异常和基础设施异常，因为它有可能影响业务，也有可能不影响业务。如果不进行妥善处理，后期有可能导致业务异常。至于业务异常，所映射的是稳定性可能出现问题，业务也可能受损。因此不仅研发和SRE需要关注业务异常，老板和稳定性负责人也需要关注。
风险场景的实体关联了三个要素，分别是规则表达式、监控指标和告警、预案和快恢。
- 规则表达式：作用是向稳定性负责人和老板提出异常定义，类似于物理公式，在计算某个值的时候会先给出一个公式。对于稳定性负责人和老板来说，他们并不关心公式的值，但这个公式能明确表达当成功率低于某个值的时候，就可以进行风险认定。
- 监控指标和告警：基于规则表达式，研发需要补全相关信息。因为规则表达式本身只是一个定义和公式，在具体计算时需要关联对应的指标。监控指标告警与三个概念相关联，一是指标，二是告警，三是监控实体。这个实体涉及变更和定位，能够表达规则表达式当中的异常关联在哪个实体上，也可以确定哪个监控实体或哪个应用实体发生了异常。基于风险场景，规则表达式能表达异常的定义，监控指标告警则关联表达式，实现基础的计算能力。
- 预案和快恢：通过人工预案的快恢绑定，也可以通过自动化预案绑定。当它触发某个场景时，通过整个信息流转，集成到整个快恢平台的能力内，置于风险场景上，就能解决事前的配置化工作，类似于获得一本操作手册，避免运行时标准化层面的不一致。
综上所述，我们提出了一个对应的配置页面，除了场景外，还会引入值班组和预警节点。预警节点即CMDB，用于定义整个业务、部门或应用预警的节点。
- 场景和值班组的关系：值班组包括对应的管理者，处理对应问题的企业微信协同群及对应的升级侧。响应机制是5分钟未接手就升级至负责人，10分钟未接手则升级至leader。一个风险的预警节点可关联多个值班组和多个场景。
- 值班组的职能：处理预警节点所对应的场景信息，比如一个大团队设置了3个值班组，则每个值班组需要处理其中的4个异常场景。通过这些关联的指标配置，可清晰定义这个节点下需要负责的具体值班组和具体的异常场景，关注点有可能重叠，比如老板的视角会关注所有的场景异常。
通过场景的定义、值班组和预警节点的概念，我们整合出了风险预警的三个核心概念，即哪些值班组在哪个预警节点要处理哪些场景的异常。有了该定义，在事前就能较好梳理风险点的具体位置以及人员职责，避免上文所述的告警混乱和渠道不一致问题。
2.风险告警——事中
- 报警推送
场景触发异常时，第一个消息就是报警推送。收到告警后，我们会在群里推送一套标准化流程的卡片，标准化的格式是标题内容、告警时间渠道以及最近变更成员，然后进行一定的标准行为操作，比如遇到风险需要接手并响应，加入一个应急的协同群。通过对接不同的监控系统，我们可以清晰定义监控和告警的实体以及用户关心的内容。针对来自MySQL、SLO、Alarm、公司内部前端的告警和普通的告警，会适配不同的模板，由渠道统一推送。
主要贡献：统一流程、整合能力、提供协同、适配渠道、精准触达、
- 行为同步
由于我们已经明确“标准SOP体系下的风险处理”定义，所以告警出现后，自然有人接手。之后再进行转交，并在排查过程中机型信息的录入与同步，也可以告知他人自己遇到的问题，这些信息都会在群中同步，如此便实现了事件的闭环。我们还提供了催办升级能力，同步广播进展，进行统一的度量。若整个群做到了以上几点，那么在老板视角就可以及时获知问题，是否有人处理和响应等。研发也能互相协同，因为一个平台由多个研发负责，在这个平台中我们可以了解问题的跟进详情，问题根因来自谁等，可便于在群中做进一步的沟通。
主要贡献：闭环事件、催办升级、广播进展、统一度量、信息透明
- 预警详情
除了简短的卡片信息外，还会提供一些对应的技术指标，比如针对SLO的告警，我们提供了一个相关接口错误码的指标时序图，以方便研发在预警详情中通过一个页面查看过往大量平台的信息。表面上是平台整合，但实际上是通过标准的SOP流程明确定义需要关注的平台，并且借助算法和工程能力查出具体的指标错误，同时提供一定的根因分析和预案快恢能力。根因分析和预案快恢的完整行动路线都会通过信息同步的方式在群中进行协同处理，以避免由于信息不一致而导致操作失误。
- 预警列表
方便用户在群中快速得知哪些预警仍未完结，通过一个较为标准的处理流程，就能妥当地处理风险。即使一个研发缺乏一定的风险处理能力，但借助这套产品也能极快地处理风险，降低整个业务的风险。
对于整个风险预警产品，我们不仅做了标准的SOP流程，还从变更层面挖掘了信息的拓扑能力。
- 快恢覆盖
快恢即在整个恢复过程中所执行的手段，回滚最为常见，因为超过73%的故障和风险基本上都由变更引起。此外还有中间件和基础设施的运维操作，以及标准化预案平台的接入。
通过这些覆盖，我们在整个事中可以做到赋予研发更多处理问题的手段和能力，借助变更覆盖和监控覆盖，结合拓扑覆盖，我们就能尝试帮助用户定位风险的诱因。
图右侧展示了风险预警的定位能力以及对应的覆盖能力。通过定位，能将内容快速推送到群中；通过接口的监控，告知指标在同环比增加的比率，最后帮助用户发现问题。
如果上下游出现异常，拓扑覆盖也能定位。若你的应用发现异常，我们会帮你检测有无做过对应的变更，若无变更，则通过拓扑信息侦测周围链路上发生的变更，给出一定的推荐，帮助用户找到对应的人员，从而快速解决问题。
而在快恢层面，我们也会同步所有信息，在整个群中做协同，以避免研发在重复操作或者信息不同步不对称的情况下，导致故障或风险的二次发生。
3.风险告警——事后
有了恰当的配置和事中的处理，通过相对简单的方式便能度量事后的数据。
接手时长、接手率、完结时长以及完结率是四个非常核心的技术指标，透过这些指标即能感知每个部门的情况。我们会根据这些情况去沟通，加深对产品的了解，思考产品能够持续优化的各个方向和层面。
事前涉及基础设施的风险覆盖、中间件的风险覆盖、应用的风险覆盖以及SLO的风险覆盖，事中的核心度量就是接手率、完结率和转故障数。事后则会度量有效率和场景治理。
场景治理包括两方面，一是正召回，二是负向召回。正召回即召回误告的告警，负向召回即需要填充未被发觉的告警。事后的度量完成后，整个风险就能产生一个新的闭环，从而解决风险的遗漏风险、告警的失效，以及人员的治理问题，最终就能解决整个风险。
三、风险预警的产品架构&技术架构
1.风险预警总体架构
2.风险预警技术架构
最底层是人员组织的管理，用于表明公司的人员信息；CMDB即预警节点的节点能力，也会搭建基础服务，以便为上层服务提供权限。场景管理再往上，则会通过一些微服务（如核心的场景管理）实现整个场景的数据配置化能力。
- 监控管理：提供一个标准的监控模型，把不同的监控系统接入到整个平台中；
- 值班管理：Oncall值班组的能力；
- 变更管理：不但承载封网管控能力，还负责变更信息的录入。在最底层的业务设计基础上，分为四部分，分别是配置管理、处理风险、定位恢复和数据度量；
- 配置管理：管理场景、CMDB、人员组织和值班表的相关关系，提供风险挖掘和故障防控的能力；
- 处理风险：除消息推送、应急协同和催办升级外，也能聚焦于快恢能力。我们的产品主要是解耦式的设计，可以支持外部系统做对应的推送。以MySQL为例，这种场景下如果要做定位，有了解耦式的设计，就能通过DBA自行诊断整合到我们风险预警的应急流程处理中去，更好地服务于研发和SRE，帮助他们解决这个问题。
通过整套技术架构以及领域划分的设计，它的横向拓展性相对会更好。针对后续的一些用户诉求，不管是SRE老板、运维稳定性负责人还是一线研发，都会在这个产品中承担不同的角色，并满足不同的诉求。
Q&A
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：首先，我们产品的核心与故障有本质区别，故障更多的是一种管控手段，风险预警则是我们给研发提供自闭环风险的概念，也就是说，理论上研发对风险预警拥有接收自由，我们并没有强制研发一定要接收风险预警。
针对整个风险预警的定义，它是一个产品，用于帮助技术人员或者研发等不同的角色提高风险对应的管理能力。故障相对而言强制性更强，对公司来说可以称为一种政治手段。风险预警是一个产品化的能力，它帮助技术人员去做这个事情。技术人员可能是最底层的一线技术人员，也可能是技术人员的老板，希望通过风险预警提供一个抓手，提高整个团队对风险的管控能力。他也有可能是稳定性负责人，希望更快获知风险。
这个产品提供了一定的技术能力，并且将在后续的迭代中不断丰富，比如更精准的定位能力、更精准的快恢、接入更多的快恢平台，制定恢复预案等，将这些技术能力整合在一起，帮助技术人员更好地解决风险。借助该产品，他们可以迅速获得业务结果，以最小的成本实现稳定性的建设。如果他们意识到以上的好处，他们也会认同并相信风险预警能解决对应的业务痛点。
至于如何避免被过多的预警轰炸到麻木，第一配置成本会调高；第二，我们会进行数据复盘，在整个大盘中告知哪些预警的规则可能存在问题。我们不会让用户简单地打标告警有效或无效，会阐述清楚是抖动还是监控异常，或是规则不合理，还是偶发事件无需处理等等一系列原因，帮助研发通过整个大盘的数据得知自己上周的应急协同数据，即获知每天处理的风险数量以及有效率，哪些风险需要重视等，通过一个闭环清除无效的告警，帮助研发挖掘更多可能需要覆盖的风险点。综上所述，当技术人员认为这个产品对他有帮助，他就会自发使用。
谷林涛
哔哩哔哩
基础架构部 资深开发工程师
B站事件运营中心研发负责人，负责建设Bilibili内部稳定性平台产品，提升线上问题的应急协同效能。同时负责工单、封网管控、拓扑定位产品，总体保障业务系统的安全生产。
