故障响应与排查
故障响应通过协作处置缩短业务受损时间。本文负责定级、止血、定位、恢复验证与复盘。跨服务故障应按用户请求路径组织证据。
1. 面试核心
先记住这几条，再读正文- 响应分工。 事故负责人统一决策，处置人员和沟通人员分别承担执行与同步。卡 · 处置流程
- 止血与根因修复。 止血恢复服务，根因修复消除触发故障的条件。卡 · 处置流程
- 影响范围。 地区、版本和入口维度能缩小用户故障的影响范围。卡 · 请求路径与影响范围
- 故障复盘。 复盘记录影响、时间线、因果链与可验收的改进项。卡 · 复盘
- 恢复验收。 恢复标准包含业务成功率、延迟、积压和数据完整性。卡 · 恢复验证与回切
2. 处置流程
| 阶段 | 产出 |
|---|---|
| 确认 | 告警与业务探测相互印证 |
| 定级 | 受损功能、用户范围与损失估计 |
| 组织 | 事故负责人、执行人、沟通人和记录入口 |
| 止血 | 明确动作、预期收益、风险及撤回条件 |
| 定位 | 支持或排除假设的日志、指标和变更记录 |
| 修复 | 根因对应的修复与验证结果 |
| 复盘 | 有负责人、截止时间和验收条件的改进项 |
事故负责人维护统一的处置计划。执行人同步动作和结果，避免多人相互覆盖。交接时需明确当前影响、已做动作和待验证假设。
最近的变更是优先核对的线索。时间重合只说明相关性，还需检查影响范围与机制。故障也会由容量、依赖和硬件变化触发。
2.1 止血措施
- 回滚适合由新版本或新配置触发的故障。执行前确认数据格式和数据库变更兼容。
- 切流将请求转向健康实例或机房。接收端需有容量，并满足数据一致性要求。
- 扩容增加处理能力。限流在扩容完成前保护核心请求。
- 降级关闭非核心依赖，或返回可接受的替代结果。
- 隔离摘除异常节点，并暂停扩大影响的任务。
证据采集应控制耗时与负载。关键日志、线程栈和变更记录可并行收集。堆转储会消耗资源，应评估后再做。恢复服务的动作无需等待完整证据包。
3. 请求路径与影响范围
排查先明确三个维度。
- 哪些用户受影响，是否集中于地区或版本。
- 故障何时开始，与哪些变更同时发生。
- 哪个功能异常，其他功能是否正常。
| 环节 | 核对证据 |
|---|---|
| 客户端 | 版本分布、DNS 与建连耗时、客户端错误 |
| DNS | 受影响地区的解析结果与缓存 TTL |
| CDN | 节点错误、回源状态与证书有效期 |
| 网关 | 状态码、上游地址、连接池与限流记录 |
| 应用 | 请求追踪、线程池、GC 和发布版本 |
| 依赖 | 数据库查询、缓存命中率、外部调用耗时 |
同一请求标识能关联各段日志与追踪。地区故障可对比健康地区的拨测结果。部分用户故障可按实例、分片和灰度批次对照。网络命令与抓包方法见 Linux 网络排查。
4. 复盘
复盘将故障证据转成可验证的改进。
- 概要说明故障内容与持续时间。
- 影响记录用户、请求、业务功能及数据损失。
- 时间线区分触发、发现、响应、缓解和恢复。
- 因果链区分触发条件、直接原因与防护缺口。
- 处置评估记录有效动作、失败尝试和沟通问题。
- 改进项明确负责人、优先级、截止时间和验收方法。
证据不足时，保留尚待验证的假设。无责复盘关注当时的信息、工具和系统约束。它仍要求改进项有责任人。更深入的复盘协作见 事故复盘。
5. 恢复验证与回切
恢复需覆盖用户结果和系统余量。错误率下降后，还要确认流量没有同时跌落。否则，用户放弃请求也会掩盖故障。
验证应包含核心交易探测和真实请求指标。队列积压、重试量和连接池占用需回到可控范围。有状态故障还需核对重复处理、丢失记录与副本延迟。
切流前确认目标端容量和数据可用性。回切从少量流量开始，观察后逐步扩大。每一步都要有停止条件和撤回方案。
服务恢复与事故关闭是两个节点。前者满足预先约定的业务指标。后者还需明确后续修复、证据保存和交接责任。
6 · 面试题卡片
本页题目与参考回答
6.1 一个高优先级的线上故障发生了，你的处置流程是什么？如果一个机房整体故障了怎么办？
考察重点
- 止血优先于根因；先查最近的变更。
- 定级、角色分工与沟通；机房故障的切流前提。
参考回答
先确认影响并组织响应，再执行可回退的止血动作。
事故负责人统一决策，沟通人定时同步。执行人记录动作、时间和结果。
核对最近的变更及其影响范围。回滚前验证数据兼容，切流前验证容量与数据状态。扩容、限流、降级分别处理不同瓶颈。证据采集与止血并行，避免高成本采集拖延恢复。
机房 B 故障时，先确认 A、C 的剩余容量。再按预案分批接收 B 的流量。有状态服务需确认副本进度与切主条件。恢复后核对业务指标、积压和数据完整性。根因修复与复盘继续跟进。
6.2 用户反馈某个功能很慢或打不开（例如某个地区搜索出了问题），你怎样从客户端到服务端定位？
考察重点
- 先确定影响范围、开始时间和功能，找出受影响用户的共同特征。
- 沿 DNS、CDN、接入层、应用、依赖逐段排查，每段说出检查方法。
相关内容：请求路径与影响范围、Linux 网络排查。
参考回答
先按地区、版本、功能和时间缩小范围。
通过拨测与真实请求确认用户症状。将受影响组和健康组做对照。
沿客户端、DNS、CDN、网关、应用、依赖检查。客户端看解析、建连、TLS 和首包耗时。入口看解析结果、证书、状态码与上游地址。应用和依赖用请求标识关联日志及追踪。
局部地区故障优先比较接入点和路径。实例或分片故障优先核对用户路由。定位可用的替代路径后，按容量执行切流。随后验证恢复效果并继续修复。
6.3 故障复盘应该包含哪些内容？怎样验证复盘改进的效果？
考察重点
- 复盘文档的结构：影响、时间线、根因、防线为什么失效、改进项。
- 改进项可跟踪；无责文化；按预防、发现、恢复、减小影响分类。
参考回答
复盘应记录影响、时间线、因果链和可验收的改进项。
因果链说明触发条件及防护缺口，尚未确认的原因标为待验证假设。
改进覆盖预防、发现、恢复和影响范围控制，每项写明负责人、截止时间和验收条件。例如，回滚改进应通过演练验证恢复时间。无责复盘如实记录当时的信息与约束，帮助团队修正系统和流程。
6.4 错误率恢复正常后，怎样判断故障已经恢复？
考察重点：流量分母、积压、数据完整性和回切。
相关内容：恢复验证与回切。
参考回答
还要核对请求量、核心交易、延迟与积压。
流量骤降也会使错误率下降。有状态故障需检查数据丢失和重复处理。观察窗口内指标稳定后，才逐步回切。事故关闭还需明确后续修复和交接责任。