本文根据谷林涛老师在〖deeplus直播：甩掉技术债包袱，B站的SRE体系建设与转型实践〗线上分享演讲内容整理而成。
分享概要
一、传统告警渠道的困局
二、风险预警——闭环风险的全生命周期
三、风险预警的产品架构技术架构分享
一、传统告警渠道的困局
1.传统告警——事前1）业务痛点
沟通群里有各种各样的告警，如基础设施的告警、业务接口的告警、中间件的告警，客情舆情的用户反馈。这些信息通过不同的形式方式以及依赖每个告警工具的建设，推送在群中，导致整个群信息杂乱，处理告警无从下手。
日常告警：海量的数据内容复杂琐碎，包括业务和中间件的数据。由于效率不足，很多时候大家会直接静默，错过一些重要告警，最终导致问题没有被及时跟进，变成故障，甚至社会舆情。
网络舆情：不只是个人告警，网络舆情的数量也很庞大。在微博、知乎等一系列的公开场合每天都有大量网络舆情。这些客体的数据分布在每个平台的社交网络上，网络感知更快，但难以迅速触达研发和产品侧，错过最快的抑制时间。
业务客诉：即基于内部的业务客诉。客户通常通过热线、在线提工单的方式反馈问题，在线小二、客服将客户信息转发到相关群，通知大家处理。但实际上用户难以真正阐述问题，如果不做相关定性定量，可能在问题反馈初期无法定位问题根因，导致大面积的业务客诉，然后转化为重大舆情事件。
2）问题所导致的痛点
由于告警过多，过于复杂，导致告警疲劳；
孤军奋战：在传统告警中，每个人都相当于孤军奋战，因为网络只是舆情的输入端，而非告警。客诉在群中流转，日常告警则不断推送各种各样的渠道告警，但我们最终只是收到告警，不清楚这条告警通知了谁，有无得到处理，一切都是未知数；
存在信息偏差：由于组织架构调整，相关研发和运维人员的信息维护未必非常准确。收到告警的人可能无需收到类似告警，而本应收到告警的新成员，却未能收到；
数据离散：用户不清楚接收的告警数量，也无法分辨有效告警和无效告警，更无法判断告警的重要性，导致整个数据无法度量，各个视角（研发、测试、运维、老板）都无法感知自身业务的稳定和应急协同的成效。
3）痛点引发的新问题
沟通复杂：如果成员们认为收到的告警表明情况严重，则会在群里说一声，但是群消息非常多，因此在收到重要告警时大家可能察觉不到。
问题升级：沟通复杂可能导致告警疲劳，造成问题升级。若小问题得不到及时解决，积累后越来越严重，就会导致故障发生。
无法度量：由于渠道、产品不统一，无法跟进度量应急时效、有效及后续情况，所以无法评估并提升业务稳定性。
研发、老板、SRE三大角色需要处理这些风险，各自的困难如下图：
2.传统告警——事中对于传统预警告警的处理，本质上是处理并解答四个问题：有哪些人？采取什么机制？有哪些信息？用了哪些平台工具？然而在实践过程中，可能会遇到各种各样的挑战。
缺乏标准SOP，研发处理过于依赖个人能力
缺乏标准的SOP应急流程，导致SRE、研发、老板三个角色在问题发生出现时，对预警、故障的处理完全依赖个人的经验能力。对于一个具有丰富工作经验的同学来说，不会在处理故障时遇到很大障碍。但对于一些工作时间不长、没有遇到过线上问题的同学来说，处理故障完全依赖个人理解和能力，这可能导致一些“非标”的动作，或遗漏重要的应急步骤。最终，轻则影响恢复市场，重则扩大故障影响面。
实时进展无同步，信息不对称可能放大故障影响面
在整个操作过程中，由于事态比较紧急，可能会存在操作过程不规范或信息未能及时同步的情况，使得大家双向操作。其本质问题是实时进展无法同步、信息不对称，最终放大故障的影响面。
人员职责不清晰
一个标准预警的发生，SRE团队、中间件团队、业务团队和基础设施团队都可能参与其中，传统告警无法协同不同角色在各自领域内解决问题。
多团队跨团队合作，缺乏协同能力
标准恢复操作涉及拉群、定位、观测、执行运维操作的平台众多，来回横跳影响应急效率。
处理方案：
观测定位：在实战过程中，一个事件告警产生后，首先不断地跳转大量平台，进行观测和定位；
预案快恢：类似重启、线上应用配置修改、数据库执行DDL、等常规手段，涉及平台极多。平台执行时难以及时通知整个内部团队，例如有人进行业务降级时，其他人可能并不知道；
应急协同：一旦出现严重的问题，大家会拉群沟通，如果跨团队，或者涉及多人的跨云协作则可能双方人员都会拉群。但实际工作中已有SRE群、研发群和处理临时问题的各种群，群的数量剧增，信息同步效率却不高。以上情况直接导致整个告警处理过程中出现一个极大的业务痛点——即大家无法做到信息对齐，问题会在处理过程中进一步被放大。
3.传统告警——事后传统告警基本没有事后处理，缺乏对有效占比、原因分类、响应时长、完结时长等一系列标准操作的信息数据度量。数据度量的缺失就意味着难以进行对应数据治理，导致问题处理后，缺乏数据沉淀，也难以避免类似问题再发生。此外，如何判断告警的有效性，如何治理等问题都缺乏对应抓手和处理依据，这是传统告警存在的困局。
二、风险预警——闭环风险的全生命周期
基于上文的困局，我们提出了“风险”的概念。什么是风险？它与故障有什么区别？以下将详细介绍。
整个风险的生命周期基本实现了全闭环，先风险发现，然后跟踪和定位风险，最后风险打标。
风险发现
风险挖掘需要定义风险。风险覆盖人工、客情、舆情、工单系统等方面，也可定义为通过业务监控、中间件监控或基础设施监控发现的风险。风险不等同于故障，故障严重影响业务的可用性，而风险意味着可能对业务产生小部分影响，但还未扩大至较高等级的影响，无需通过标准的故障流程来处理。我们通过告警系统或人工上报打通流程，发现对应风险。
风险跟踪
定义和发现风险后，就需要跟踪和相应风险。基于风险响应，我们制定了一套标准的SOP流程。
风险定位
这个风险如何产生？根因是什么？这些都是大家需要
