本文根据洪鹏老师在〖deeplus直播：B站面向故障的应急响应体系建设〗线上分享演讲内容整理而成。

分享概要

一、稳定性保障困局

二、应急响应中心建设思路

三、ERC平台化能力

随着业务规模的不断扩大和日常需求的快速迭代，即使是最优秀的业务架构也无法确保系统100%的可用性，故障在生产环境中是不可避免的。本次围绕故障分享下我们做的一些稳定性保障工作，具体内容如下：

• 稳定性保障困局
• 应急响应中心建设思路
• ERC平台化能力

一、稳定性保障困局

1.过去一年发生的故障

回顾我们过去一年发生的各种大小故障，可以将其分为以下几类：

• 变更类：代码变更、基础组件变更、配置变更、数据变更；
• 操作规范类：由于流程不规范导致的故障；
• 第三方：涉及硬件、运营商和云服务的问题。

通过对历史故障处理过程的分析总结，我们在故障发现、故障处理和故障恢复这三个阶段发现了许多问题。这些问题导致故障无法快速恢复，且重复根因的故障多次发生。

接下来，我们将从故障发现、故障处理、故障恢复这三方面进行深度挖掘和分析。

2.稳定性保障困局之故障发现

1）监控告警

故障最有效的发现方式是通过告警。为了尽可能提高告警的覆盖率，大家会添加许多不同类型的告警规则，包括：

• 系统维度：如CPU、内存、IO等指标；
• 中间件：如MySQL慢查询、同步延迟，Redis大key、热key等问题；
• 业务错误日志：监控业务系统中的错误日志。

这带来了一个问题：每天会有大量告警，SRE需要在海量告警中人工识别出哪些告警可能导致故障，并优先处理。这使得工作效率极低，日常on call的同事几乎全都在处理告警，无法顾及其他稳定性相关的问题。

2）客服反馈

另一种故障发现的渠道是客服反馈。我们有一个全站的问题反馈群，客服会在群里同步客诉。由于消息非常多，容易遗漏一些核心功能的客诉。在定位问题时，研发需要与客服进行大量沟通，比如了解进线用户是否集中在某个地域、使用的APP版本等，需要讨论很多细节，协同效率非常低。

3）网络舆情

最后一种是在监控缺失的情况下通过网络舆情发现问题。这部分问题占比非常小。通过网络舆情发现故障后，研发和SRE会介入处理，但此时影响面已经非常大了。

3.稳定性保障困局之故障处理中

• 故障处理：故障信息没有公开透明，遇到故障大家没有先通告的习惯，影响业务往往不知道依赖方此时异常了。
• 协同处理：在处理大型故障时，参与人员众多，常常通过在线会议进行协作，但会议过程混乱，分工不明确，缺乏故障指挥官角色来统一决策和任务分配。
• 缺乏信息串联：在定位故障时，需要查看多个平台的监控、追踪、日志和变更信息，但这些信息缺乏有效的串联。
• 预案失效：部分预案在实际故障处理中失效，没有保证预案的有效性，导致故障恢复时间延长。

4.稳定性保障困局之故障结束后

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

• 复盘需要关注哪些内容，没有统一的模板；
• 分析过程容易开成批斗大会，尤其是当故障跨部门，更是互相甩锅，复盘效果比较差；
• 复盘过程中制定下来的改进项，难以落地，deadline无限延期。

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

二、应急响应中心建设思路

1.故障生命周期

我们先来看下整个故障的生命周期包括：发生、发现、响应、定界、定位、止损、恢复。

我们内部对整个故障的处理，希望做到1分钟发现问题，3分钟响应，5分钟定界定位，10分钟恢复。

故障处理过程中，发生、发现和响应比较容易理解，我重点介绍下定界、定位，止损、恢复这几个阶段。

1）定界和定位

• 定界：通常是指确定了故障原因的大概范围，为了我们能更加准确的应急决策；
• 定位：找到故障的具体原因，问题根源。

这里有个例子：某应用做了一次常规的迭代变更，导致可用率下跌。

• 定界：通过告警发现应用coredump；
• 定位：开发人员通过调试工具找到具体的代码行。

很明显这个case我们通过快速回滚能迅速恢复，而不用等研发改代码、提mr、重新构建发版。

2）止损和恢复

• 止损：旨在防止故障扩散，通过采取更快速的措施将业务恢复到用户可接受状态；
• 恢复：意味着将业务完全恢复到故障发生之前的状态。

这里也有个例子帮助大家更好的理解：app上的首页推荐模块异常。

• 止损：通过网关侧的开启热门结果降级，虽然这样会导致一些个性化推荐失效，但总体上保证了可用；
• 恢复：只有底层推荐系统完全恢复正常。

2.ERC

ERC（Emergency Response Center）主要围绕整个故障生命周期，从故障发现、故障处置、故障恢复来设计，目标就是能快速恢复不能预防的问题，降低MTTR（平均故障恢复时间），不再重复已发生的问题。MTTR进一步拆分为以下四个阶段：

• MTTI：平均故障发现时间，指从故障发生到通过指标异常或用户反馈，发现故障到识别的时间。
• MTTK：平均故障认知时间，指从识别故障到定界定位故障的时间。
• MTTF：平均故障恢复时间，指从定界定位到故障的时间到采取措施恢复故障的时间。
• MTTV：平均故障验证时间，指故障恢复后通过监控指标或用户验证服务恢复的时间。

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

3.故障发现

围绕这个目标，首先要考虑更高效的故障发现方式。

我们先来看下什么是故障，这样才能帮助我们更高效的发现。简单来说，故障就是产品体验受损，无法按照预期提供服务。

那么之前加的那些原因类指标是不是就没这么重要了？

原因类指标是无穷无尽的，并且某些指标对整个分布式系统的影响微乎其微，例如一台机器的异常宕机，cpu打满，也不一定对整个系统产生明显影响，除非所有实例全部异常。这种情况最终会反映到我们的结果指标上。因此，我们应该更多地关注结果类指标，结果类指标是可枚举的。

那么什么是结果类指标呢？我们可以分为技术指标和业务指标：

• 技术指标：例如L0、L1服务可用率，核心场景的可用率；
• 业务指标：例如分钟发弹幕数，分钟直播在线人数，分钟稿件审核数等。

这类结果类指标异常，一定表示线上发生了故障。

故障发现后，接下来就是对故障的处置阶段。

4.故障处置

在故障处理过程中，确保信息同步至关重要，不同的群体关注的内容不同：

• 技术人员：关注故障的具体情况，是否与其负责的业务有关，能否提供协助；
• 管理人员：关注当前故障的影响范围，是否已经定位到问题，预计何时能够恢复；
• 客服人员：故障会影响到哪些用户，如果有新的用户进线，统一的回复话术。

所以通告信息要包含大家关注的内容，在一些大群只做故障首通和故障完结通知，故障协同群内会进行故障的进展更新。

在协同上要保持高效，通过合理的手段保证负责人第一时间响应，同时明确故障处理时人员的角色分工。

此外，可观测能力也至关重要，因为可以帮助我们快速定界定位问题。在快速恢复阶段，要及时决策，同时必须确保预案可执行。

5.故障恢复

故障恢复之后要进行有效的复盘，复盘内容结构化，对根因深挖，有效的复盘总结能避免同类故障再次发生。

复盘里还有一个很重要的点，就是改进措施，改进措施需要遵循smart原则：

• Specific：具体的改进项
• Measurable：可度量的验收标准
• Attainable：改进措施是否能落地，避免假大空
• Relevant：改进之间关联性，避免出现孤立的改进
• Time-bound：最重要的就是明确deadline，一般三个月内比较好，避免改进流于形式。如果这个改进项确实需要很长时间，建议拆分。

三、ERC平台化能力

上面介绍了这么多方法论，接下来看下我们内部是如何落地的，我们踩过的坑以及如何解决。

1.故障发现

1）客服

①人工驱动

对于客服类的故障，传统流程依赖人工驱动：

• 客服在保障群反馈问题。
• 研发人员进行处理并判断是否升级。
• 发出故障通知。

整个流程高度依赖研发，效率较低。

②平台驱动

为了提高效率，我们设计了新的平台驱动流程，将客服系统和应急响应中心直接对接：

• 故障录入：ERC提供故障录入页面，并内嵌到客服平台。当客服人员发现同类客诉达到阈值时，录入故障并附带用户反馈信息。
• 自动化协同：自动拉起应急协同群。通过影响面找到干系人自动进群，发出故障通告。

新流程显著提高了客服类故障的发现和处理效率。

③注意事项

需要注意的是，客服分类和服务树节点不完全一致。为了解决这个问题，我们做了以下工作：

• 关联映射：建立客服分类和服务树之间的关联映射，确保能够准确的拉取故障干系人
• 支持特殊节点：对于一些特殊节点有固定支持人员，也支持单独配置

2）SLO

客服收到大量用户反馈时，通常影响面已经非常大，用户处于无法容忍状态，对线上故障的发现，客服来源只能作为辅助。

有没有更高效的发现方式呢，最常见的做法就是基于SLO升级，SLO是用来度量业务稳定性的，基于错误预算做升级故障，能准确判断故障是否发生。

①覆盖范围

• 业务网关的SLO，和用户体验强相关
• 基础服务（稿件、账号等会有很多服务强依赖）
• 其他的核心应用

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

②降噪

在实施过程中，我们还遇到了基础设施或基础组件异常导致大量业务受影响，同时拉起大量应急协同群，形成故障风暴。为了解决这个问题，需要采用一些抑制手段：

• 对同一个业务域，xx分钟内的SLO异常都收敛到一个故障中
• 对同业务的不同应用，同样收敛到一个故障中
• 人工合并

3）业务指标

技术指标只能发现服务所有不可用问题，一些业务逻辑类的异常，需要业务指标去补位。例如：用户频繁掉登录、用户充值失败这些case通过SLO是发现不了的。

选择业务指标的标准一样要选择能描述业务稳定性的指标，指标异常，一定表示功能有损。

①业务摸排

覆盖业务指标的实时流程前置工作需要SRE同学对各业务进行深入摸排，和业务方共同选择指标。业务摸排完成后，对指标类型进行了分类：

• 业务日志
• 基础值（比如分钟开播数、卡片点击率）
• 占比（首页推荐各卡类型占比）
• 同环比（投稿件，在线人数等等）

②平台集成

前置的梳理工作完成后，接下来就是平台能力的建设，需要支持指标的定义，在定义指标时支持多基础值组合，以及不同类型组合来进行降噪。

③生产案例

稿件业务的视频人审指标 同环比异常上涨、下跌都认为是故障。

4）内部反馈&告警

除了自动召回故障之外，平台还优化了人工录入故障的交互逻辑。并且提供了openAPI供第三方系统对接，减少信息的割裂。

解决API滥用的问题

一些同学可能会担心API被滥用，有些明明不是故障，就是一个简单的告警。为了解决这一问题，我们采取了以下措施：

• 限制开放对象：目前仅仅对基础设施团队和监控团队开放此接口。
• 明确使用场景：各团队约定好具体的使用场景。
• 基础设施团队：用于基础设施类异常的故障通告。
• 监控团队：用于告警一键升级故障。

通过上述的几种故障发现，我们目前的故障自动召回率和故障有效率都达到了80%以上。

2.协同处置

1）基础能力

2）协同流程

对于自动触发的故障，erc会自动拉群，一个故障对应一个应急协同群。如果某些业务有专门的故障处理群，系统也会将故障信息直接同步到这些固定群里。

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

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

3）应急角色

在整个故障的应急协同中，我们设定了两种角色：故障指挥官和一线处理人员。

• 故障指挥官会组建处理团队，分配任务，故障进展更新同步，同时做一些决策。
• 一线处理人员主要负责分析故障原因，判断影响范围，提供止损方案，待故障指挥官确认后进行预案执行。

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

4）应急升级

因为我们是没有7*24小时的NOC团队，很多时候故障都是发生在非工作时间，所以为了提高非工作时间的响应效率，我们完善了应急升级机制：

• 故障1分钟未响应电话通知值班SRE、研发
• 5分钟未响应直接电话通知SRE leader。

5）移动端

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

①移动端优势

• 高效响应：通过移动端办公，SRE可以随时随地对故障初步处理，无需依赖电脑。
• 快速决策：移动端提供完整的故障信息和故障分析工具，帮助SRE第一时间做出准确决策。

3.故障处置

1）定界定位

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

• 错误下钻：异常可用区、path、状态码分布、实例分布；
• 关联变更：上下游、基础设施、组件变更、平台变更；
• 应用指标：系统、运行时、是否限流；
• 应用依赖：下游、中间件、基础组件、外部依赖。

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

2）故障止损

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

• 回滚：70%的故障都来源变更，变更平台需具备快速回滚的能力；
• 降级：优先保证应用核心功能，定期组织演练，验证有效性；
• 切流：多活能力建设，任务编排，快速执行。

还是其他的手段例如：

• 限流：在容量有限的情况下，丢弃部分超出自身服务能力的请求；
• 扩容：系统处理能力不足时，通过hpa等手段快速扩容；
• 重启：对于内存泄漏、连接数打满等问题，重启服务往往是简单粗暴但有效的解决方案。

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

4.故障恢复后

1）复盘

故障恢复之后的复盘需要包含以下内容：

• 对故障处理过程做回溯：什么时间，哪位同学做了什么操作，让复盘参与人员都能对整个故障时间线有所了解。
• 对整个故障的影响分析：本次故障影响了哪些，有一个摘要描述，影响面，影响了线上服务多长时间。
• 反思总结：架构编码层是否暴露出问题，70%的故障都是变更导致的，如果是变更导致的，能否在灰度过程中发现，发布时能否有指标进行阻断拦截。同时整个处理过程中的1-3-5-10是否有优化的空间。
• 定级定责：本次故障的损失统计（客诉、舆情、资损、pv等），明确责任方，同时对故障进行定级。
• 改进措施：改进项的描述，明确deadline，待办负责人，完成验收人，以及对应的优先级。

上图展示了生产的一个实际的复盘案例。之前我们的复盘信息缺少和故障的关联，用户填写成本比较高，为了解决这些问题，我们对复盘流程进行了优化。

复盘流程优化

• 复盘与故障关联：复盘变为故障的一个状态，很多信息就能联动起来，减少手工输入的工作量
• 用户输入优化：支持富文本格式，提供更丰富的文本编辑功能。同时，系统还支持报告模式，提高整体可读性。
• 在线文档托管：针对一些大型故障，某些业务习惯用在线文档进行复盘，平台上也支持在线文档的托管，方便业务团队统一管理和分享复盘文档。

2）数据运营

最后看一下平台的数据运营，运营数据统计中关于1-3-5-10，有两种统计方式：

①累加统计，总时长10min

优势：统计方便

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

②分段统计，总时长19min

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

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

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

确定了统计方式，就可以进行1-3-5-10的统计，包括：

• 整体达成率，按不同发现方式拆分的达成率
• 达成率趋势图

同时对故障数量，我们也关注：

• 周故障数趋势图
• 自动召回的有效率及准确率

以上就是我们针对故障做的一些稳定性保障工作，面向故障建立一个高效的应急响应中心，通过数据驱动的方式去持续运营，不断优化，提升故障恢复时间，降低同类故障再次发生，提高线上业务稳定性。

dbaplus社群欢迎广大技术人员投稿，投稿邮箱：editor@dbaplus.cn