故障响应与排查
线上故障时最重要的不是立即找到根因，而是尽快恢复服务。SRE 面试中的故障题通常有三种：一个高优先级故障来了，你按什么流程处理；用户反馈某个功能慢或打不开，你怎样从客户端到服务端定位；故障结束后怎样复盘并推动改进。本文按这三部分讲解。单机层面的排查见 Linux 性能排查，复盘中的组织问题见事故复盘与组织学习。
1. 面试核心
先记住这几条，再读正文- 处置流程：发现与确认 → 定级并拉起响应（指定负责人、沟通人）→ 止血（先恢复服务）→ 定位根因 → 修复与验证 → 复盘与改进。止血优先于根因：回滚最近的变更、切流、扩容、降级、重启，同时保留现场证据。卡 · 处置流程
- 先看最近的变更：多数故障由发布、配置变更和流量变化引起，时间点对得上的变更是第一嫌疑，最快的止血手段往往是回滚。
- 用户反馈“慢”或“打不开”，先确定影响范围（全部用户还是部分地区、运营商、客户端版本），再沿请求路径逐段排查：客户端与本地网络 → DNS → CDN 与接入层 → 负载均衡 → 应用 → 依赖。卡 · 从用户反馈定位问题
- 复盘写清楚时间线、影响、根因、做得好和不好的地方，以及有负责人和截止时间的改进项；关注系统和流程，不追究个人。卡 · 复盘
2. 处置流程
| 阶段 | 要做的事 |
|---|---|
| 发现 | 告警、用户反馈、巡检。确认是真实故障，而不是监控误报 |
| 定级 | 按影响的用户比例、核心功能、资金损失确定级别，决定拉哪些人、多久同步一次 |
| 组织 | 指定事故负责人统一决策，指定沟通人对内对外同步进展，其他人分头排查；建立专门的沟通频道并记录时间线 |
| 止血 | 回滚变更、切换流量到正常的机房或实例、扩容、开启降级或限流、隔离异常节点、重启。先恢复，再查根因 |
| 定位 | 对比故障开始时间与变更记录，看监控、日志和链路追踪，缩小到具体组件 |
| 修复 | 根本修复，验证指标恢复到正常水平并观察一段时间 |
| 复盘 | 无责复盘，形成改进项并跟踪落实 |
常用的止血手段
- 回滚：故障时间与发布或配置变更吻合时最直接。前提是发布支持快速回滚，数据库变更向前兼容。
- 切流：一个机房或可用区故障时，通过 DNS、全局负载均衡或网关把流量切到其他机房。前提是其他机房有足够的容量，数据在机房间有同步，切换方案事先演练过。
- 扩容与限流：流量突增时扩容，扩容来不及时限流保护核心功能。
- 降级：关闭非核心功能（推荐、评论），返回缓存或默认结果。
- 隔离：摘除异常节点，暂停异常的批处理任务。
保留现场：重启前先收集线程栈、堆转储、关键日志和监控截图，否则根因可能无法确认。
3. 从用户反馈定位问题
用户说“某个功能很慢”或“页面打不开”，先回答三个问题：
- 影响范围：所有用户还是部分？按地区、运营商、客户端版本、接入机房拆分错误率和延迟，找出共同特征。
- 开始时间：与哪些变更、流量变化或外部事件同时发生？
- 哪个功能：只有一个接口，还是整个应用？
然后沿请求路径逐段排查：
| 环节 | 可能的问题 | 检查方法 |
|---|---|---|
| 客户端与本地网络 | 新版本客户端的缺陷、弱网、本地 DNS 被劫持 | 按版本拆分指标、客户端日志与埋点 |
| DNS | 解析错误、TTL 导致切换不生效、某地运营商解析异常 | 在受影响地区用 dig 查询、拨测平台 |
| CDN 与接入层 | 节点故障、回源失败、证书过期 | CDN 节点日志与回源错误率、证书有效期 |
| 负载均衡与网关 | 后端被摘除、连接数打满、限流误触发 | 网关的状态码分布、上游健康状态 |
| 应用 | 新发布的缺陷、线程池耗尽、GC 停顿 | 链路追踪定位慢的环节、应用日志、实例指标 |
| 依赖 | 数据库慢查询、缓存失效、第三方接口变慢 | 依赖调用的耗时和错误率 |
只影响部分地区时，重点看该地区的 DNS 解析结果、接入的 CDN 节点和机房，以及当地运营商网络；可以用分布在各地的拨测确认是否能复现。只影响部分用户时，看这些用户是否落在同一个实例、分片或灰度批次上。
4. 复盘
复盘文档的结构：
- 概要：发生了什么，影响多大，持续多久。
- 影响：受影响的用户比例、功能、请求数、资金损失、是否违反 SLA。
- 时间线：从变更或触发事件开始，到发现、响应、止血、恢复的每个时间点，用来计算发现时长和恢复时长。
- 根因与触发条件：直接原因，以及为什么防线没有拦住（测试、灰度、监控、告警、限流各自为什么没起作用）。
- 做得好与不好的地方：响应、沟通、工具。
- 改进项：每一项有负责人、优先级和截止时间，并跟踪到完成。
改进项按“预防、更早发现、更快恢复、减小影响”分类，例如：增加变更前的自动检查、补充缺失的告警、缩短回滚时间、加入演练、消除单点。复盘要无责：个人操作失误说明流程和工具允许这种失误发生，改进的对象是系统。
5 · 面试题卡片
5.1 一个高优先级的线上故障发生了，你的处置流程是什么？如果一个机房整体故障了怎么办？
出现公司：快手、莉莉丝、百度、东方财富
考察重点
- 止血优先于根因；先查最近的变更。
- 定级、角色分工与沟通；机房故障的切流前提。
参考回答
第一步确认和定级：确认告警或反馈是真实故障，评估影响的用户比例、核心功能和资金损失，确定级别，拉起响应，指定一个负责人统一决策、一个人负责对内对外同步，建立沟通频道并开始记录时间线。
第二步止血，目标是尽快恢复服务而不是马上找到根因。先查故障开始前后的变更，时间吻合就回滚；单个实例或机房异常就摘除或切流；流量突增就扩容或限流；依赖故障就降级。动手重启之前保留线程栈、堆转储和日志。
第三步在服务恢复后定位根因并彻底修复，观察指标稳定，最后组织复盘，把改进项落实到人。
如果 A、B、C 三个机房中 B 整体故障：先确认是机房级问题（B 的所有服务同时异常，其他机房正常），然后通过 DNS、全局负载均衡或网关把 B 的流量切到 A 和 C。切流前要确认 A、C 有足够的容量，必要时先扩容或对非核心功能限流；有状态的服务要确认数据同步情况，按预案把主库切到其他机房，评估可能丢失的数据。B 恢复后先验证，再逐步把流量切回。这类预案需要事先演练，故障时才能快速执行。
5.2 用户反馈某个功能很慢或打不开（例如某个地区搜索出了问题），你怎样从客户端到服务端定位？
出现公司：百度、滴滴、小红书、好未来、集度、神策数据
考察重点
- 先确定影响范围、开始时间和功能，找出受影响用户的共同特征。
- 沿 DNS、CDN、接入层、应用、依赖逐段排查，每段说出检查方法。
相关内容：从用户反馈定位问题、Linux 网络排查。
参考回答
先缩小范围。看监控确认问题是否真实存在，按地区、运营商、客户端版本、接入机房拆分错误率和延迟，判断影响的是全部用户还是一部分，以及它们有什么共同点；确认开始时间，和变更记录、流量变化对照；确认是单个功能还是整个应用。
然后沿请求路径逐段排查。客户端：是否集中在某个新版本，客户端埋点中的 DNS、建连、TLS、首包时间分别是多少。DNS：在受影响地区解析域名，看结果是否指向正确的接入点，是否有运营商解析异常或切换后 TTL 未过期。CDN 和接入层：对应节点的错误率和回源情况，证书是否过期。负载均衡和网关：状态码分布、后端是否被摘除、是否触发限流。应用：用链路追踪找出慢的环节，检查最近的发布、线程池、GC。依赖：数据库慢查询、缓存命中率、第三方接口。
只有某个地区出问题时，重点检查该地区的解析结果、CDN 节点、接入机房以及当地运营商到机房的网络，用各地的拨测节点复现；部分学生卡顿这类问题，还要看这些用户是否连到同一个媒体节点、网络质量是否差。定位后先止血，例如把该地区的解析切到其他接入点，再修复根因。
5.3 故障复盘应该包含哪些内容？怎样让复盘真正推动改进？
出现公司：共济科技、快手、滴滴
考察重点
- 复盘文档的结构：影响、时间线、根因、防线为什么失效、改进项。
- 改进项可跟踪；无责文化；按预防、发现、恢复、减小影响分类。
参考回答
复盘文档包括：概要；影响范围，如受影响的用户、功能、请求数和时长，是否违反 SLA；时间线，从触发事件到发现、响应、止血、恢复的每个时间点，用来看发现和恢复各花了多长时间；根因和触发条件；本应拦住它的防线为什么没起作用，例如测试没覆盖、灰度范围太大、没有告警或告警没人看；处置中做得好与不好的地方；改进项。
改进项要能落地：每一项有负责人、优先级和截止时间，录入任务系统并定期检查进度，未完成的在例会上跟进。分类上覆盖四个方向：预防（变更前的自动校验、消除单点）、更早发现（补充告警）、更快恢复（一键回滚、切流预案演练）、减小影响（降级、隔离）。复盘要无责，关注系统和流程为什么允许这次失误发生，否则大家会隐瞒信息，复盘就失去意义。还可以定期汇总多次复盘，找出反复出现的风险类型，例如单点依赖或配置变更，作为稳定性治理的重点。