B站崩的那晚，连夜谋划了这场稳定性保障SRE升级之战……

随着B站近几年的快速发展，业务规模越来越大，迭代速度越来越快，系统运行复杂度也越来越高。线上每天都会发生各种各样的故障，且发生的场景越来越刁钻。为了应对这种情况，保障业务在任何时刻都能将稳定性维持在一个高基线之上，B站专门成立了SRE体系团队，在提升业务稳定性领域进行了全方位、体系化的积极探索，从理论性支撑和能力化建设进行着手，从故障应急响应、事件运营、容灾演练、意识形态等多方面进行稳定性运营体系的构筑。

本次分享主题是B站SRE在稳定性方面的运营实践，分享内容分为以下几个部分：

案例剖析从应急响应看稳定性运营核心运营要素有哪些两个运营载体：OnCall与事件运营中心挑战与收益

一、案例剖析

多年来业界同仁针对稳定性这一话题进行了大量的探索和实践，业界不乏针对稳定性保障相关的讨论和研究。在围绕稳定性的实践上，大家也经常听到诸如混沌工程、全链路压测、大促活动保障和智能监控等话题的分享。B站在这些方面也做了很多建设工作，今天我将从应急响应的角度切入，和大家分享B站在稳定性运营方面所做的工作。

我们先来看两个案例，案例以真实事件为依托，相关敏感内容进行了改写。

案例一

1）背景

一个手机厂商的发布会在某天晚上12点举办，B站承接了该品牌的线上发布会直播。公司的运营同学提前就配置好了12点的直播活动页面以及准点的应用内Push消息。在12点到来之后，直播活动页推送生效，大量用户收到应用内推送消息，点击进入直播活动页面。

2）故障始末

12点01分，直播活动页内嵌的播放器无法支持部分用户正常加载播放。

12点03分，研发同学李四收到了异常的报警，开始介入处理。

12点04分，客服同学收到了大量有关发布会无法正常播放的用户反馈，常规处理方法无法解决用户问题。

影响持续到12点15分，研发同学李四还在排查问题的具体原因，没有执行相对应的止损预案（该种问题有对应预案），问题持续在线上造成影响。

直到12点16分，老板朋友找到了老板反馈今晚B站的某品牌手机直播发布会页面视频无法正常播放，此时老板开始从上往下询问，研发leader知道了这件事，开始联系SRE同学介入问题处理，并及时执行了相关的切换预案，直播活动页面播放恢复正常。

3）问题

在这个案例中，暴露了以下一些问题：

故障的相关告警虽然及时，但是并没有通知到足够多对的人。该故障的告警，在短时间没有处理响应后，并未进行有效的结构性升级（管理升级，及时让更高level的人参与进来，知晓故障影响，协调处理资源）和职能性升级（技术升级，让更专业和更对口的人来参与响应处理，如team leader、SRE等）。一线同学往往容易沉迷于查找问题根因，不能及时有效地对故障部位进行预案执行。

案例二

1）背景

一个平淡无奇的周末晚上，23点30分，监控系统触发大量告警，几乎全业务线、各架构层都在触发告警。

2）故障始末

23点40分，企业微信拉了有十几个群，原有的业务沟通群、基础服务OnCall群，都在不停地转发告警，询问情况。整个技术线一片恐慌，起初以为是监控系统炸了。此时相关故障的SRE同学已经被拉到某一个语音会议中。

注意，此时公司的多个BU业务线同学都炸锅了，到处咨询发生了什么，业务怎么突然就不炸了。又过了几分钟，资深的SRE同学又拉了一个大群，把相关业务对接人都拉进群里，开始整体说明故障情况。此时，该同学也比较纠结如何通报和说明这个问题，因为此时没有一个明确故障定位，语言很难拿捏，各个高level的老板也都在问（已上热搜）。并且，负责恢复入口服务的一线同学把故障预案执行了个遍，发现无济于事。后续在GSLB调度层，执行了整个跨机房的流量有损切换才让服务逐渐恢复正常。

凌晨之后，原有机房的问题定位出来了，补丁迅速打上，异常的问题彻底修复了。后续，在对此事件进行复盘时，发现困难重重。因为故障处理过程中，涉及到大量的服务、组件和业务方，并且大家当时拉了一堆群，同样的消息被发送到了很多群。参与处理故障的同学在语音、电话和企微群都有进行过沟通和处理进展发布，整个事件的细节整理起来非常耗费人力和精力，准确性也很难保障。

3）问题在上面这个案例中，我们可以看到整个故障从发生、处置到结束后复盘，都存在以下问题：当一个影响面比较大的故障产生时，大家没有统一的故障进展同步方式，依托原始的人工拉群，人工找相关人员电话联系，导致了故障最新的进展情况只能够在小范围传播扩散，无法统一对外公布，并且在传播过程中，很容易消息失真；在故障处理过程中，缺少主要协调人（故障指挥官）。像这种大型故障，需要有一个人能够去协调各层人员分工、消息收敛、服务业务情况等，这个人需要能够掌控整个故障的所有消息和全貌进展；在故障处理过程中，缺乏故障上下文的信息关联，大家难以知晓故障发生的具体位置，只是感知到自己的业务受损了，自己的服务可能有异常，这导致整个故障的定位时间被拉长；在故障恢复之后，我们对这个故障进行复盘时，发现故障处理过程中的信息太过零散，复盘成本很高。

案例剖析

通过对上述两个案例的分析我们能够发现，在故障发生前、处理中和结束后，各个阶段都会有很多因素导致我们的故障不能被快速解决，业务不能快速恢复。

这里我们从故障的前、中、后三个阶段总结可能存在的一些问题。

1）事前

告警信息量大，信息太过杂乱；平台系统繁多，变更信息无处收敛；客服反馈的信息，需要靠人工去关联，并反馈到技术线；和公司舆情相关的信息，技术线很难感知到。

2）事中

一线同学过于关注技术，沉迷问题解决；当一个故障影响面扩大之后，涉及多个团队的协同非常困难，最新的进展消息无法及时有效地传递到相关人员手中；当参与一个故障处理的人员多了之后，多个人员之间缺乏协调，导致职责不清晰，产生事情漏做、重复做的问题；故障处理过程中，会有一些不请自来，凑热闹的同学。

3）事后

当我们开展复盘时，发现故障处理时又是群、又是电话、又是口头聊，又是操作各种平台和工具，做了很多事情，产生了很多信息，梳理时间线很繁琐，还会遗漏，写好一份完整的复盘报告非常麻烦；拉一大堆人进行复盘的时候，因为缺少结构化的复盘流程，经常是想到什么问什么。当某场复盘会，大家状态好的时候，能挖掘的点很多。如果状态不好或者大家意识上轻视时，复盘的效果就较差；复盘后产出的改进事项，未及时统一地记录跟进，到底有没有完成，什么时间应该完成，完成的情况是否符合预期都不得而知；对于已经修复的问题，是否需要演练验收确保真正修复。

以上三个阶段中可能发生的各种各样的问题，最终只会导致一个结果：服务故障时间增长，服务的SLA降低。

二、从应急响应看稳定性运营

针对上述问题，如何进行有效改善？这是本部分要重点分享的内容，从应急响应看稳定性运营。

应急响应的概念较早来源于《信息安全应急相应计划规范GB/T24363-2009》中提到的安全相关的应急响应，整体定义是“组织为了应对突发/重大信息安全事件的发生所作的准备，以及在事件发生后所采取的措施”。从这个概念我们延伸到稳定性上就产生了新的定义，“一个组织为了应对各种意外事件的发生所作的准备以及在事件发生后所采取的措施和行为”。这些措施和行为，通常用来减小和阻止事件带来的负面影响及不良后果。

三、核心运营要素有哪些

做好应急响应工作的核心目标是提升业务的稳定性。在这个过程中，我们核心关注4大要素。核心点是事件，围绕事件有三块抓手，分别是人、流程和工具/平台。

人作为应急响应过程中参与和执行的主体，对其应急的意识和心态有很高要求。特别是在一些重大的故障处理过程中，不能因为压力大或紧张导致错误判断。

流程将应急响应的流程标准化，期望响应人能够按照既定阶段的既定章程进行有效的推进和处理。

工具/平台支撑人和流程的高效合规运行，并将应急响应的过程、阶段进行度量，进而分析和运营，推进人和流程的改进。

事件

1）生命周期划分

要对故障进行有效运营，就需要先明确故障的生命周期。通过划分故障的生命周期，我们可以针对不同的周期阶段进行精准聚焦，更有目的性地开展稳定性提升工作。

针对故障生命周期的划分有很多种方式，按故障的状态阶段划分，可以分为事前、事中和事后。

按故障的流程顺序划分，可以分为故障防御、故障发生、故障响应、故障定位和故障恢复、复盘改进等阶段。

这里我围绕故障的时间阶段，从故障不同阶段的形态变化做拆分，将故障拆分为四个阶段。

告警/变更/客诉

当故障还未被确认时，它可能是一个告警、变更或客诉。

事件

当这个告警、变更、客诉被上报后，会产生一个事件，我们需要有人去响应这个事件，此时一个真正的事件就形成了。

故障

当事件的影响范围逐渐扩散，这时往往有大量的用户、业务受到影响，我们需要将事件升级成故障，触发故障的应急协同，进行一系列的定位、止损等工作。

改进

故障最终会被恢复，接下来我们要对故障进行复盘，产生相关改进项，在改进项被完成之后，还需要进行相关的验收工作。

2）阶段度量

从更科学的角度看，我们知道在运营工作中，度量是很关键的一点。管理学大师彼得·德鲁克曾经说过：“你如果无法度量它，就无法管理它”。有效的度量指标定义，可以帮助我们更好更快地开展运营工作、评估价值成果。上文中我们提到的3个阶段是比较笼统的阶段，接下来我将介绍更加具体和可执行的量化拆分方法。

如上图所示，从故障预防依次到故障发现，故障定位，故障恢复，最后到故障改进，整体有两个大的阶段：MTBF（平均无故障时间）和MTTR（平均故障恢复时间）。我们进行业务稳定性运营的核心目标就是降低MTTR，增加MTBF。根据Google的定义，我们将MTTR进一步拆分为以下4个阶段：

MTTI：平均故障发现时间，指的是故障发生到我们发现的时间。MTTK：平均故障定位时间，指的是我们发现故障到定位出原因的时间。MTTF：平均故障修复时间，指的是我们采取恢复措施到故障彻底恢复的时间。MTTV：平均故障修复验证时间，指的是故障恢复之后通过监控、用户验证真实恢复的时间。3）关键节点

基于阶段度量的指标，我们能够得到一系列的关键时间节点。在不同的阶段形态，事件和故障会存在一些差异。故障因为形态更丰富，所存在的时间节点更多。上图中定下来的时间，均是围绕MTTR进行计算的。主要是为了通过度量事件、故障的处理过程，发现过程中存在的问题点，并对问题点进行精准优化，避免不知道如何切入去提升MTTR的问题，也方便我们对SRE的工作进行侧面考核。

人

人作为事件的一个主体，负责参与事件的响应、升级、处置和消息传播。

人通过上文中我们讲到的OnCall参与到应急响应中。我们在内部通过一套OnCall排班系统进行这方面的管理。这套系统明确了内部的业务、职能和人员团队，确保人员知道什么时间去值什么业务的班。下面的工具/平台部分会展开介绍。对参与人的要求，主要有以下几点：

具备良好的响应意识和处理心态。具备熟练地响应执行的经验。

满足以上特征，才能做到故障来临时响应不慌乱，有条不紊地开展响应工作。

流程

那么针对人的要求如何实现？人员如何参与到应急响应的环节中去？人员的意识如何培养呢？

首先，我们内部制定了应急响应白皮书，明确了以下内容：

响应流程；基于事件大小，所要参与的角色和角色对应的职责；周边各个子系统SOP制定的标准规范；针对应急过程中的对外通告内容模板；故障过程的升级策略。

之后，我们会周期性地在部门内部、各BU进行应急响应宣讲，确保公司参与OnCall的同学能够学习和掌握。另外，我们也会将其作为一门必修课加入新同学的入职培训中。最后就是故障演练，通过实操，让没有参与过故障处理的新同学能够实际性地参与应急响应的过程，避免手生。

平台

平台作为支撑人与流程进行高效、稳定执行的载体，我将在下一部分进行具体描述。

四、两个运营载体：OnCall与事件运营中心

这部分我将向大家分享B站在应急响应方面落地的两个运营性平台。

OnCall系统

OnCall系统，即值班系统。值班系统在日常运转过程中的作用往往被低估，SRE、工程效率做这部分建设时，很容易基于二维的方式对人和事进行基于日历的值班管理，并通过网页、OpenAPI等方式对外提供数据服务。

下面我们通过几个例子来说明OnCall的必要性。

在日常工作中，当我们使用公司某个平台功能时，可能会习惯性找熟悉的同学，不管他这一天是不是oncall。这可能给那位同学带来困扰，他可能上周才值完班，这周要专心于研发或者项目的推进，你随时找他可能打断他的工作节奏。还有一种情况是新同学不知道该去找谁，我们内部之前经常有这种情况，一个新来的同学接手一套系统之后，有问题不知道该找谁，经常要转好几手，才能找到对的人，这一过程很痛苦。

以上内容总结起来就是总找一个人，总找不到人，除此之外，还会出现平台找不到人的情况。这些问题的根源是什么呢？无非就是who、when、what和how的问题，不能在正确的时间为正确的事找到正确的人。

那么OnCall系统的重要性和必要性都体现在哪些方面呢？

有问题找不到人

随着公司业务规模的扩大和领域的细分，一些新的同学和新业务方往往会出现一个问题。不知道是哪些人负责，需要咨询很多人才能找到具体解决问题的人。这一问题不仅限于故障，更存在于日常琐事中。特别是SRE同学的日常，经常会被研发同学咨询找人拉群，戏称拉群工程师。

下班不下岗

当人们遇到问题时，经常会下意识找熟悉的人。这就导致一些能力强、服务意识好的同学，总是在被人找。不论他今天值不值班，他将无时无刻都要面临被人打扰的问题。除了被人找之外，内部的监控系统、流程系统，也会给不值班的同学发送监控告警和流程审批信息。这也将SRE同学有50%的时间用于工程这一愿景变成泡影。

1）设计

① 明确关联逻辑

针对上述两种情况，我们对公司的业务、服务、职能和组织架构进行了分析建模，明确了人、团队、职能和业务之间的关联关系。

② 建立三维合一模型

我们构建起了一套三维合一的模型。由组织-业务、职能-人员、组织-职能的关联关系，产生交汇点。值班人员会通过值班小队的方式，落在这些交汇点上，并且基于业务和基础架构的异同点，通过业务视角和职能视角分别对外提供服务。

以我们公司内部主站业务为例，我们会有专门的SRE小队进行日常的值班响应，这个小队只负责主站业务的值班响应。通过这样的对应关系，当人或平台有需求的时候，都可以通过业务和职能关联到对应实践的值班小队，最终定位到具体的人，这样也帮助我们将人藏了起来，更有利于后续SRE轮岗机制的推进落地。

③ 双视角提供服务

通过双视角的设计，区分了职能型和业务型的不同值班方式和关注点。原因在于B站的业务层级组织模式是按照“组织-