一、传统告警渠道的困局

　　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老板、运维稳定性负责人还是一线研发，都会在这个产品中承担不同的角色，并满足不同的诉求。