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站的业务层级组织模式是按照“组织->业务->应用”这三级进行组织的，所有的应用归属到业务，业务归属到具体的组织架构。

职能视角

前端采用树型展示，组成结构为组织->职能->覆盖范围（组织->业务->服务），值班表具体挂载在覆盖范围下，覆盖范围可以只有一级组织也可以精确到组织下面的业务或业务下面的服务。

业务视角

前端采用树型展示，组织结构为组织->业务->职能，值班表具体挂载在职能下面。 在日常工作中，基础架构相关的服务，比如SRE、DBA、微服务、监控、计算平台等强职能型服务会通过职能视角对外提供值班信息。当业务人员有具体问题时，可以通过职能树快速定位到具体的值班人员。而对于业务服务来讲，日常的工作模式是围绕业务开展的，因此会通过业务进行展开，提供该业务下相关职能的对应值班信息。 这两个视角的底层数据是相通的，强职能相关服务提供方只需要维护好职能视角的值班信息，业务视角下的关联会自动生成。

2）功能展示

基于以上设计，我们内部做了一套OnCall排班的系统。 这套系统是管理业务、职能和人的系统。我们基于上文中提到的几个核心概念，在这些概念间建立了关系，分别是两条线，一条是职能-团队和人，另外一条是职能-业务和服务。 系统提供了排班班组的管理，支持基于日历的排班，同时支持班组设置主备oncall角色。在排班的细节上，我们支持基于时段进行自动排班计划生成，也支持在一个职能里多个班组混合排班。另外，也支持对已经排好班的班组，进行覆盖排班和换班，这个主要应对oncall同学突然有事请假的情况。在oncall通知方面，我们支持了企业微信、电话等通知方式，并且支持虚拟号码的方式，保护员工号码不对外泄露。同时也避免了因为熟悉导致的频繁被打扰的情况。 在周边生态方面，这套OnCall系统完全依赖周边系统的接入。我们目前对接了内部的告警系统、流程系统，确保告警和流程能够只通知oncall人，而不形成骚扰。在企业微信的服务号中，也进行了H5的页面嵌入，在用户通过企业微信反馈问题、找人时，知道当下该找谁。在各个接入的平台，也内嵌了OnCall的卡片页面，明确告诉用户本平台当前是谁值班。通过这套OnCall系统的落地，我们明确了人、团队、职能和业务的概念，并将这些概念进行了关系建立和对应。人员通过排班班组统一对外为某个业务提供某项职能的值班响应。通过前端的可视化，提供了日历的值班展示效果，可以直观看到某个业务所需要的某块职能在某个时间点是由哪个班组在服务，周边的各个系统也都对接OnCall系统，实现了人员响应的统一管理，解决了某些人员认人不认事，不通过正规流程处理的问题。

事件运营中心

事件运营中心这套系统是我们基于ITIL、SRE、信息安全应急计划的事件管理体系，为了满足公司对重大事件/故障的数字化管理，实现信息在线、数据在线和协同在线，使组织能够具备体系化提升业务连续性能力所做的产品平台。这个平台的定位是一站式的SRE事件运营中心，数字化运营业务连续性的目标是提升MTBF，降低MTTR，提高SLA。

1）架构设计

上图是我们平台的模块架构图，整体上还是围绕上文提到的事件的事前、事中和事后三个阶段拆分，覆盖了一个事件产生、响应、复盘、改进的全生命周期。

事前

我们对事件进行了4大类型的拆分，分别是告警、变更、客诉和舆情，然后通过设计标准的事件上报协议，以集成的方式将我们内部的各个系统打通，将事件信息统一收集到一起。在收集的过程中，进行二次处理，实现事件的结构化转储。

事中

我们会对接入的4大类型信息进行事件转化，然后通过预定义的规则对事件进行降噪，抑制、报警、召回、分派和升级等相关操作。在这个过程中，如果一个事件被判定影响到业务，我们会将它升级成一个故障，然后触发故障的应急响应流程。这里就进入到对故障响应处理过程中的一个阶段，在这个阶段我们会产生各种角色，例如故障指挥官、故障通讯人员、故障恢复人员等，相关人员明确认领角色，参与故障的止损。止损过程中，通过平台一键拉群创建应急响应指挥部，通过平台的进展同步进行相关群和业务人员的通告，通过记录簿实现故障信息的信息传递和记录。

事后

在故障结束之后，就进入到我们整体的改进环节。平台可以基于故障一键创建复盘报告，自动关联故障处理过程中的专家数据。平台提供预制的故障复盘问答模板，以确认各阶段是否按照预期的目标进行。复盘产生的待办列表，平台会进行定期的状态提醒和处理进度跟进。最终的这些都会以知识的形式，沉淀在我们的知识库。帮助日常On-Call问答和公司内部员工的培训学习。整体这样一套平台流程下来，就实现了将一些日常高频的非结构性事务驱动，通过统一接入、精准触达、事件闭环和持续改进等环节，转化为低频的结构化数据驱动方式。

2）场景覆盖

下面我们介绍平台在各个场景的覆盖。 ① 集约化 对事件产生的上游来源进行集约化管理，通过队列订阅、API和SDK的方式，将内部的监控，Prometheus、监控宝等各个云平台的监控都通过前面的4大类型定义收归到一起，然后统一进行通知触达。 ② 标准事件类型 为了实现各个渠道消息的结构化规约，我们设计了标准的事件模型，通过这个事件模型，我们将周边各个系统/工具/平台进行收集，并且实现了事件的关联操作。模型主要分为4部分：

base是一些事件的基础信息字段； who是指这一事件来自哪里，有哪些相关方； when是指事件发生或产生影响的时间； where是指事件来源于哪个业务、影响了哪些业务； what是指这个事件的具体内容，它的操作对象是什么等等。

③ 降噪聚类 由于我们对事件的上报结构进行了标准化，并且预埋了关联字段，通过这些关联字段，我们就建立起了事件的关联关系，从而可以做事件的降噪聚类。 降噪聚类在执行上，主要分为两部分。

横向抑制

我们支持对单个来源的事件、告警，通过定义的规则进行收敛，比如Prometheus报警出一个服务在某个持续时间内持续报了N条一样的告警信息，平台会收敛到一个事件中去。

纵向抑制

这对上文中提到的底层系统故障十分有效，可以将底层故障导致的上层业务告警都统一收到一个事件中，避免大量告警使大家造成混淆。 ④ 协同在线 在协同在线的场景下，我们通过一个面板将人、业务、组件和系统信息进行了汇总，通过一个事件详情页，将整个事件当下的处理人、关联业务和服务组件、当下的一些信息统一展示在一起。在协同能力上，我们提供了一键创建应急响应群的功能，建群时会自动关联该故障相关oncall同学，对故障感兴趣的同学也可以通过面板加入响应群。在故障页面，清晰看到故障当前的指挥官是谁，当下的处理人是哪些同学。彻底解决了之前靠人工拉语音、打电话、面对面交流的原始协作方式。 平台的各方面能力实现了事件全生命周期的闭环管理。监控告警、故障发现、应急响应、故障定位、故障恢复、故障复盘和故障改进，全阶段都通过平台能力去承载。

故障响应时，支持了故障的全局应急通告，提供了多种通告渠道，信息实时同步不延误，避免人工同步，漏同步、同步内容缺漏等问题； 故障跟踪阶段，平台可以实时展示最新的故障进展；故障影响面、当下处置情况，各阶段时间等等； 故障结束的复盘阶段，通过定义好的结构化、阶段化的复盘过程，确保复盘过程中，该问的问题不遗漏，该确认的点都确认到； 故障改进阶段，通过对改进项的平台化录入，关联相关责任方、验收方，确保改进的有效执行和落实。

上图中是协同相关的一些示例，当一个故障被创建出来时，会自动关联该故障涉及到的业务、组件、基础设施的oncall同学，这些同学可能是SRE、研发等，平台会记录他们是否有响应这些问题，并且当下所负责的角色是什么。因为角色决定了在该事件中所担负的事项和责任；下方一键拉群，可以将相关人员，自动拉入到一个群内，方便大家进行沟通协同，并且事件、故障的相关最新进展也会定期在群内同步；涉及到事件的参与人员，事件运营中心的服务号也会定期推送最新进展，确保不会丢失消息。 上图是我们内部的故障协同的详情页面，提供了记录簿、故障阶段更新、最近变更信息和相似事件，确保每次的响应处理，都能形成一个专家经验的沉淀，帮助后续新来的同学进行故障响应过程的学习。 复盘方面，我们定义了结构化的故障复盘模板，像相关人员、组织、影响情况、处置过程、根因分析(在根因分析里面，我们设置了6问，确保对问题能够有深度地挖掘)，改进措施等。在复盘效率方面，我们关联了相关的变更信息、故障处理时的一些变更操作，以及处理时间线，帮助复盘同学快速生成故障的相关信息，减少人工录入负担。

五、挑战与收益

挑战

在业务稳定性运营体系的建设过程中，团队也踩了很多坑，面临着诸多技术之外的挑战。鉴于业界对于技术相关的分享比较丰富，这里就针对体系逻辑和人员方面的挑战进行分享。

元信息统一

稳定性是个大话题，我们在落地整体体系时会发现，设计的上下游系统太多了。每个系统里面都会有人、业务、职能的使用需求。在初期，我们内部在服务、业务和人的关联这块没有形成统一的数据基准，导致我们在应急协同的诸多特性上难以落地，诸如故障的有效通知、群内的有效传递、故障画像的拓扑关联计算缺少映射关系等等。 在这种情况下，我们重新梳理了服务树和OnCall系统，通过服务树将组织、业务和服务的映射关系维护好，通过OnCall系统将组织、职能、业务和人的映射关系维护好，来确保找人的时候能找到人，找服务的时候能找到服务。

工作模式改变

新的应急响应流程，将故障过往对人的依赖转移到靠系统来自行驱动，这导致现有人员的工作模式产生了很大变化。传统故障处理时，响应人员手动拉群、语音或现场找人，现在变成了优先在系统内升级已有事件或录入故障信息，然后通过系统自动进行人员关联和邀请。群内的随意沟通，变成了在平台进行阶段性进展同步。原有的故障升级逻辑变成了平台定时通知，这给故障处理人员带了一定的压迫感。整体形式上更加严肃和标准，在落地初期给大家带来了一定的不适应感。针对这种情况，我们一方面通过在系统的文案描述上进行改善，交互逻辑上进行优化，尽可能在推行新标准的同时，适应旧的使用习惯。例如，常规应急协同群会先于平台的故障通告建立，这就会与平台创建的故障协同群发生冲突。此时，我们通过增加现有群关联来实现已有故障协同群和故障的关联。另外一方面，我们通过定期持续的宣讲，给大家介绍新的应急响应流程和平台使用方法，帮助大家适应新的应急响应模式。

收益