背景

　　随着业务规模的不断扩张和日常需求的快速迭代，即使是最优秀的业务架构、最完善的生产体系也无法确保系统100%的可用性，参考墨菲定律，会出错的事总会出错，故障在生产环境中不可避免。为了在故障发生时能够快速定界定位，采取有效措施止损，避免同根因故障重复发生，我们需要对故障全生命周期进行统一管理。

　　故障应急体系一般包括以下环节，故障预防、故障发现、故障定位、故障恢复、故障复盘及改进，其中故障预防阶段可以参考B站安全生产专项建设实践，这里不再赘述，本文将围绕故障发生后，对稳定性保障带来的挑战，如何去破局，以及如何沉淀建设平台能力，介绍B站面向故障的应急响应中心建设。　　

　　故障对稳定性保障的挑战

　　回顾我们过去一年比较典型的故障：

　　某非核心服务发版，不合理的调用方式，导致某L0核心服务异常，影响APP UGC播放功能，故障定界定位时间较长

　　某云厂商CDN服务中断，多业务受损

　　某非核心服务OOM，导致上游依赖核心服务hang住，预案失效，导致故障恢复时间较长

　　某业务变更，SLO技术指标正常，业务返回数据异常，导致业务受损，持续n小时

　　总结以往case特征不难发现，存在以下痛点：

　　故障发现场景覆盖不全，过往只聚焦服务饱和度、SLO指标，缺少业务类核心指标，例如广告曝光率、搜索空结果率、机审免审率等

　　故障定界、定位困难，缺乏有效的故障根因分析、链路变更可观测能力

　　预案新鲜度低，认为行之有效的预案突然失灵了

　　...

　　不难发现，在故障发现、处理和恢复这三个阶段有许多问题，接下来，我们将从故障的这三个方面进行深挖和分析痛点。

　　故障发现

　　故障最常见的发现方式就是通过告警，为了尽可能的提高覆盖率，我们按不同纬度添加了一系列的告警规则，包括：

　　系统维度：如CPU、内存、IO等

　　中间件：如MySQL主从同步延迟、慢查询，消息队列积压、消费断流等

　　应用程序：错误日志、错误数、请求耗时等

　　随之而来的问题就是每天SRE会收到大量告警，如何在海量的告警中识别出哪些告警会导致线上故障，并优先处理，对于SRE来说，成本非常高。另一种故障发现的方式来自客服反馈，我们有一个全站的问题反馈群，客服会在群里同步客诉，消息比较多，容易遗漏一些核心功能的客诉。而且在定位问题时，研发需要与客服进行大量沟通，比如了解进线用户是否集中在某个地域、使用的APP版本等，讨论很多细节，协同效率非常低。

　　故障处理中

　　故障通告：故障信息没有公开透明，遇到故障大家没有先通告的习惯，影响业务往往不知道依赖方此时异常了。

　　协同处理：在处理大型故障时，参与人员众多，常常通过在线会议进行协作，但会议过程混乱，分工不明确，缺乏故障指挥官角色来统一决策和任务分配。

　　缺乏信息串联：在定位故障时，需要查看多个平台的监控、追踪、日志和变更信息，但这些信息缺乏有效的串联。

　　预案失效：部分预案在实际故障处理中失效，没有保证预案的有效性，导致故障恢复时间延长。

　　协同过程黑盒：故障发生、发现、响应、进展更新、恢复过程黑盒，不能实时感知故障进展

　　故障结束后

　　避免同类根因的故障再次发生的一个有效措施，就是通过复盘，但通常组织一场有效的复盘对SRE来说挑战很大

　　复盘需要关注哪些内容，没有统一的模板

　　分析过程容易开成批斗大会，尤其是当故障跨部门，更是互相甩锅，复盘效果比较差

　　复盘过程中制定下来的改进项，难以落地，deadline无限延期

　　基于上述的这些痛点，应急响应中心的建设迫在眉睫。

　　平台能力建设

　　发展历程

　　1.0 问题管理

　　从2019年开始，我们逐步建设故障管理平台，以取代传统的文档记录方式，最初的产品能力仅限于简单的问题记录，主要侧重于事后复盘，平台在故障发生过程中的通知和协同能力上有所不足，对故障处置缺乏实质性的帮助。

　　2.0 事件协同

　　新增了事中的通告能力，允许用户自订阅故障通知，故障恢复后，完善了复盘模块以及改进项管理。

　　3.0 应急响应中心

　　当前我们致力于构建一个应急响应中心，围绕整个故障生命周期，以”1分钟发现、3分钟响应、5分钟定位、10分钟恢复”为目标。平台的建设涵盖故障发现、故障处置和故障恢复三个阶段。

　　ERC设计思路

　　故障全生命周期　　

　　我们先来看下故障全生命周期，包含：发生、发现、响应、定界、定位、止损、恢复。

　　发生、发现、响应比较容易理解，重点介绍下定界、定位，止损、恢复这几个阶段。

　　定界和定位

　　定界：确定故障所在位置，也即故障点，为了我们能更加准确的应急决策；

　　初因定位：识别和定位导致故障初步原因的过程；

　　根因定位：深入分析和确定导致故障根本原因的过程

　　例如：某核心场景可用率严重下跌

　　定界：核心场景强依赖A服务异常；

　　初因定位：A服务做了一次常规的迭代变更导致接口异常；

　　根因定位：基于报错日志、调试工具找到对应的问题代码

　　故障发生时，往往根因定位相对复杂、耗时会比较长，定界、初因定位相对比较简单，例如有变更先回滚变更，服务过载先扩容等，在实际故障处理过程中，我们也是采取先定界恢复再定位排查问题根因。

　　止损和恢复

　　止损：旨在防止故障扩散，通过采取更快速的措施将业务恢复到用户可接受状态；

　　恢复：意味着将业务完全恢复到故障发生之前的状态。

　　例如：APP上的首页推荐模块异常

　　止损：通过开启精排个性化兜底结果降级，保证业务可用；

　　恢复：底层推荐系统完全恢复正常

　　ERC（Emergency Response Center）的设计思路围绕故障全生命周期，总体目标：

　　能快速恢复不能预防的问题，降低MTTR（平均故障恢复时间）

　　不再重复已发生的问题

　　MTTR进一步拆分为以下四个阶段：

　　MTTI(Mean Time to Identify)：平均故障发现时间，指从故障发生到通过指标异常或用户反馈，发现故障到识别的时间。

　　MTTK(Mean Time to Know)：平均故障认知时间，指从识别故障到定界定位故障的时间。

　　MTTF(Mean Time to Fix)：平均故障恢复时间，指从定界定位到故障的时间到采取措施恢复故障的时间。

　　MTTV(Mean Time to Verify)：平均故障验证时间，指故障恢复后通过监控指标或用户验证服务恢复的时间。

　　通过对这四个阶段的优化，我们可以更加精准地评估和提高整个故障处理过程的效率，降低故障影响。　　

　　业界通常使用1-3-5-10的方式来度量故障处置质量，1分钟发现、3分钟响应、5分钟定界定位、10分钟恢复，这块的计算口径有两种方式：

　　累加统计，总时长：10min

　　优势：统计方便

　　劣势：每个阶段的耗时统计不直观，不利于持续跟进优化

　　分段统计，总时长：19min

　　优劣：清晰明了，利于每个阶段的持续跟进优化

　　劣势：各阶段时长统计复杂

　　我们目前使用的是分段统计的方式，该方式有助于针对性的推动每一段改进工作的开展。

　　故障发现

　　故障定义

　　要更高效地发现和处理故障，首先需要明确故障的定义。参考ITIL中对故障的定义，可以分为以下几种情况：

　　非计划性的IT服务中断：指任何未预期的IT服务停止运行，导致用户无法正常使用服务

　　IT服务性能的下降：指IT服务的性能明显低于预期，虽然服务还在运行，但其表现不达标

　　配置项的失效：即便配置项的失效没有直接影响到服务，也应被视为故障，因为其可能会对未来的服务稳定性产生影响

　　简单来说，就是产品体验受损，无法按照预期提供服务。明确定义故障有助于我们更高效地发现问题，及时采取措施，确保服务质量。

　　客服

　　客服反馈作为故障发现的重要来源之一，如何保证故障类的客诉能第一时间响应是我们优先要考虑的问题。

　　传统流程依赖人工驱动，反馈响应流程如下：

　　客服在保障群反馈问题

　　研发人员进行处理并判断是否升级

　　发出故障通知

　　整个流程高度依赖人的交互，高优的故障往往被低优阻塞，效率较低，为了提升响应效率，我们设计了新的平台驱动流程，将客服系统和应急响应中心直接对接：

　　故障录入：ERC提供故障录入页面，并内嵌到客服平台，当客服人员发现同类客诉达到阈值时，录入故障并附带用户反馈信息。

　　自动化协同：自动拉起应急协同群。通过影响面找到干系人自动进群，发出故障通告。　　

　　如何将客服关注的产品功能和技术干系人绑定，保证故障时拉取到正常的干系人介入处理，为了解决这个问题，我们支持了产品功能和服务树预定义绑定关系的能力(服务树是我们内部各系统的桥梁纽带，承载组织、业务、应用、资源等元信息的管控，以及角色和权限的配置)，具体功能如下：

　　关联映射：建立客服分类和服务树之间的关联映射，确保能够准确的拉取故障干系人

　　支持特殊节点：对于一些特殊节点有固定支持人员，也支持单独配置。　　

　　自动召回

　　客服收到大量用户反馈时，通常影响面已经非常大。例如视频无法播放、弹幕无法发送等严重影响用户体验，用户处于无法容忍状态，此时研发、SRE再介入处理，存在一定的滞后性，也无法达成1分钟发现故障的目标。因此对线上故障的发现，客服来源只能作为辅助，我们需要更高效的方式来自动召回故障。

　　自动召回故障首先需要选择合适的指标，能描述业务稳定性，这些指标异常，一定表示功能有损。我们现在选择的指标如下：

　　SLO是通过技术指标度量业务稳定性，基于错误预算做故障升级，能准确判断故障是否发生。例如：

　　核心应用可用率严重下跌

　　应用核心场景可用率严重下跌

　　SLO类的技术指标只能发现服务不可用问题，一些业务逻辑类的异常，需要业务指标去补位。例如：

　　用户频繁掉登录

　　用户充值失败

　　搜索空结果

　　选择了合适的指标后，接下来就是应急场景的定义，应急场景包含以下信息：

　　应急场景名：应对突发事件预先设定的情景名称，以便研发、SRE能够迅速识别、理解

　　所属业务：和服务树上业务对应，有助于确定故障的影响面、故障处理时的资源协调

　　维护人：应急场景配置管理人员，通常为业务SRE

　　固定应急协同群：业务已有专门的故障处理群，新触发的故障复用此群

　　关联值班组：对接oncall平台，负责线上故障时快速应急响应

　　升级策略：因为我们没有7*24小时的NOC团队，很多时候故障都是发生在非工作时间，为了提高非工作时间的响应效率，制订了如下升级策略：

　　1分钟未响应电话通知值班SRE

　　3分钟未响应直接电话通知SRE leader

　　通过这种应急升级机制来保证3分钟内响应故障。

　　场景规则：指标+触发条件（阈值、持续时间、操作符）　　

　　自动召回在实践过程中的一些思考：

　　一、如何去覆盖，以提高自动召回的准确率和有效率

　　之前我们覆盖了线上全部L0、L1应用的SLO，在运营过程中发现很多底层服务的抖动由于业务网关的重试和降级逻辑对用户无影响，这类问题通过告警处理更合适，没必要升级为故障。

　　合理的覆盖范围：

　　业务网关的SLO，和用户体验强相关

　　基础服务（稿件、账号等会有很多服务强依赖）

　　其他核心应用、核心功能

　　二、故障收敛抑制

　　我们遇到过基础设施或基础组件异常触发大量应急场景，同时拉起大量应急协同群，造成故障风暴。

　　为了解决这个问题，需要采用一些降噪抑制手段：

　　同一业务域，例如社区、直播，xx分钟内发生的指标异常收敛到一个故障

　　同一应急场景，xx分钟内发生的指标异常收敛到一个故障

　　人工合并

　　另外起初我们将限流告警也作为故障召回，发现故障召回频次非常高，这种"高召回"容易引发狼来了，导致业务对故障麻木，这种场景该不该召回？

　　想弄清楚这个答案，我们再来看一下故障的定义：产品体验受损，无法按照预期提供服务。基于故障的定义我们可以看出，首先故障肯定是"非预期"的，限流这种通常是预期内的，预期外的限流也可以通过SLO告警，走告警处置流程处理。

　　三、协同群准确拉人

　　在应急场景中，准确地邀请干系人进群非常重要，起初我们通过服务树角色拉通干系人，这会导致故障拉人过多，极易产生干扰，为了避免不必要的打扰，我们采取了以下优化方式：

　　联动On-Call值班组：通过与On-Call值班组的联动，确保在故障发生时能够及时拉入值班人员，这种方法基于业务每周排班，有效减少了不必要的干扰

　　配置默认处理人员：关注全站业务稳定性的RD或SRE

　　四、协同群复用

　　在运营过程中，我们发现同业务短周期内（例如一个月）复用应急协同群是一个很好的实践方式，优点体现在：

　　成员准确性：应急协同群内成员是最准确的，在处理历史故障时相关干系人已经进群

　　历史故障关联：如果新的故障和历史故障有一定关联性，能够迅速调动已有经验，减少重复沟通和信息传递的时间成本

　　正常情况如果技术指标能召回，一般会早于客服指标，客服如何感知到已经被技术指标召回的case？以及各种召回策略如何收敛群？

　　我们采取了以下优化方式：

　　客服召回故障时，能够清晰看到该模块是否存在处理中的case，如果有可以一键进群

　　客服召回内容以时间线的方式收敛到已有群，同时客服召回能体现区域聚集性、端上真实状态、用户聚集特征等，也能作为技术排障的一种补充

　　平台支持基于技术指标、客服指标、内部反馈群收敛相关能力

　　五、意外收获、情理之中

　　在故障召回的处理中，我们“诧异”的发现，我们除了召回技术类问题以外，我们还召回了运营配置类故障、产品设计类优化等问题，对于这种情况对我们来说是一种意外之喜，用户对B站产品优化类的反馈，也能更好、更快的触达到我们内部，促进快速迭代优化。

　　内部反馈

　　除了客服反馈和自动召回，有些故障确实需要依赖内部反馈。特别是涉及到交换机、网络等基础设施类型的故障，以及基架内部平台功能异常等问题，这些问题无法通过自动召回机制解决，需要通过人工录入的方式补齐信息。　　

　　除了页面进行人工录入外，ERC也提供了openAPI供第三方系统对接，减少信息的割裂。

　　故障处置

　　故障发现后，接下来到了故障处置阶段。故障处理过程中，确保信息同步至关重要，不同的群体关注的内容不同：

　　技术人员：关注故障的具体情况，是否与其负责的业务有关，能否提供协助；

　　一线管理人员：关注当前故障的影响范围，是否已经定位到问题，预计何时恢复；

　　客服人员：故障会影响到哪些用户，如果有新的用户进线，统一的回复话术。

　　一个完整的故障进展通知模板应该包含以下内容：

　　标题：故障的简要描述

　　时间：故障发生时间

　　影响范围：故障影响面，哪些业务受损

　　状态：故障当前状态

　　具体描述：故障的补充描述　　

　　在应急协同群中，第一条推送的文案是故障标准的处理流程，旨在加强团队成员的止损意识。故障的首通通告、进展更新、故障完结都会在协同群中同步。　　

　　应急角色

　　在整个故障的应急协同中，参考Google的故障指挥体系，结合内部实践情况，我们设定了两种角色：故障指挥官和一线处理人员。

　　故障指挥官会组建处理团队，分配任务，故障进展更新同步，同时做一些决策

　　一线处理人员主要负责分析故障原因，判断影响范围，提供止损方案，待故障指挥官确认后进行预案执行

　　触发突发问题后，默认第一个响应的SRE承担故障指挥官的角色。

　　如果整个定位处理过程清晰明确，故障指挥官不需要做转移；

　　如果故障影响面比较广，根因定位困难，或者需要跨多个团队协调时，故障指挥官转移至更高级别负责人。

　　明确角色分工后，在故障处理过程中，大家才能各司其职，更高效的协同处理。

　　移动端

　　上面也提到了我们没有专门的NOC团队，没办法保证24小时在电脑旁，如果是上下班路上，出差时遇到故障，拿电脑，连vpn，很不方便。针对这些痛点，我们丰富了移动端办公的能力，再也不会被时间、地点限制我们的故障处置。

　　移动端优势

　　高效响应：通过移动端办公，SRE可以随时随地对故障初步处理，无需依赖电脑

　　快速决策：移动端提供完整的故障信息和故障分析工具，帮助SRE第一时间做出准确决策

　　定界定位

　　故障处理人员上线后，第一时间就是定界定位问题，这块就依赖可观测能力的建设，在处理故障时，我们通常关注以下数据：

　　错误下钻：异常可用区、path、状态码分布、实例分布；

　　关联变更：上下游、基础设施、组件变更、平台变更；

　　应用指标：系统、运行时、是否限流；

　　应用依赖：下游、中间件、基础组件、外部依赖。

　　关联的错误分析也会第一时间推送到群里，包括当前受影响的可用区，具体的path code及错误数，可观测链接，以帮助SRE和研发快速判断决策。　　

　　aiops通过上述指标以及trace去层级下钻，最终结合大模型给出故障推荐原因。　　

　　故障止损

　　在定界定位到问题后，接下来就是止损恢复。最常见的就是止损三板斧：

　　回滚：70%的故障都来源变更，变更平台需具备快速回滚的能力；

　　降级：优先保证应用核心功能，定期组织演练，验证有效性;

　　切流：多活能力建设，任务编排，快速执行;

　　还是其他的手段例如：

　　限流：在容量有限的情况下，丢弃部分超出自身服务能力的请求;

　　扩容：系统处理能力不足时，通过hpa等手段快速扩容;

　　重启：对于内存泄漏、连接数打满等问题，重启服务往往是简单粗暴但有效的解决方案。

　　这些都是故障发生时止损恢复的利器，能够帮助我们在故障发生后快速止损恢复，通过不断优化和演练，我们可以提高故障应对能力。

　　故障恢复后

　　简单重复10000次，不如有效复盘1次，有效的复盘能避免同类故障再次发生。

　　有效的复盘需要包含以下内容：

　　对故障处理过程做回溯

　　ERC根据故障生命周期的核心阶段：发生、发现、响应、定界定位、恢复，生成默认时间线，并在复盘过程中支持修改新增　　

　　对整个故障的影响分析

　　本次故障影响了哪些，有一个摘要描述，影响面，影响了线上服务多长时间。

　　解决方案

　　解决该问题的方案，基于该数据可以不断沉淀故障方案知识库，后续同类型问题，可以联动大模型给出推荐方案，赋能快恢。

　　反思总结

　　架构编码层是否暴露出问题，70%的故障都是变更导致的，如果是变更导致的，能否在灰度过程中发现，发布时能否有指标进行阻断拦截。同时整个处理过程中的1-3-5-10是否有优化的空间。

　　集思广益

　　记录、收集大家对故障的所有疑问，并在复盘时进行逐一解答。

　　定级定责

　　本次故障的损失统计（客诉、舆情、资损、pv等），明确责任方，同时对故障进行定级。

　　改进措施

　　改进项的描述，明确deadline，待办负责人，完成验收人，以及对应的优先级。

　　ERC将这些内容模版化，让填写复盘报告和后续的数据运营统计变得更加容易。

　　之前我们的复盘在实际运营过程中暴露了很多问题：

　　复盘独立模块，缺少和故障的强关联

　　时间线对1-3-5-10各阶段统计缺失，无法度量

　　为了解决这些问题，我们对复盘进行了优化：

　　复盘与故障关联：复盘变为故障的一个状态，很多信息就能联动起来，减少手工输入的工作量。

　　用户输入优化：支持富文本格式，提供更丰富的文本编辑功能。同时，支持报告模式，提高整体可读性。

　　在线文档托管：针对一些大型故障，某些业务习惯用在线文档进行复盘，平台上也支持在线文档的托管，方便业务团队统一管理和分享复盘文档。　　

　　数据运营

　　数据运营在应急响应体系演进中起至关重要的作用，通过细致的指标分析，可以有效指导未来的工作方向，我们从风险治理、故障召回、故障处置、安全生产逃逸等几个维度来重点做数据运营，量化故障数据，具体如下：

　　如何评估故障前的风险预防效果、故障恢复后的改进成果，需要关注以下指标：

　　故障数趋势

　　各业务故障分趋势

　　上面也提到了故障自动召回，那么故障召回的效果，可以通过以下指标进行度量：

　　自动召回的有效率及准确率

　　各渠道召回趋势，常态来看需要持续提升技术指标召回比重

　　从故障的整体处置质量来看，我们需要关注以下几个方面：

　　1-3-5-10整体达成率，不同发现渠道、不同业务达成率

　　MTTR均值、分位值、趋势

　　为了更好地识别和改进安全生产的薄弱环节，验证变更管控的覆盖度和拦截效果，以下指标同样需要重点关注：

　　故障原因分布

　　变更类故障趋势

　　通过这些指标的持续分析运营，能帮助我们有效提升应急响应体系的质量和效率。

　　成果与展望

　　主要成果

　　应急响应中心（ERC）上线后，应急场景已经覆盖大部分故障场景，效果显著，具体如下：

　　自动召回有效率，准确率均达到了80%以上

　　在“1分钟发现、3分钟响应、5分钟定位、10分钟恢复”的目标中，整体达成率超过了60%

　　有效降低了线上故障的平均修复时间（MTTR），提高系统稳定性和用户体验

　　...

　　道阻且长，我们在路上

　　目前故障平台还在不断完善和优化，后续我们还会陆续支持以下能力：

　　预案平台建设，基于根因分析自动推荐、联动应急预案

　　量化平台SLO，平台故障ERC自动召回

　　基础设施故障ERC召回，网络专线故障、入口网络故障等纳入故障召回体系

　　故障分运营