📚 课程目录第3章故障处理与根因分析案例

故障处理与根因分析案例

根因分析是SRE面试核心环节，面试官通过故障案例考察候选人的问题拆解能力、系统性思维、沟通复盘意识。本章围绕故障分类、根因分析框架、复盘报告模板三大模块，结合真实项目案例，帮你建立从现象到根因再到改进的完整应答链路。

  本章核心能力：故障分类判断 → 5Why/时间线排查 → 根因定位 → 改进措施 → 复盘报告结构化输出

面试问题	描述你遇到的一起生产故障，并说明当时如何判断故障等级和类型？
面试官考察点	是否具备清晰的故障分级标准（P0-P3）能否快速区分故障类型（硬件/软件/配置/容量）应急响应流程的规范性
回答框架	STAR：背景 → 故障现象 → 分级判断依据 → 应急动作 → 结果
简短示例回答	某次支付接口P0故障，响应成功率从99.9%降至60%。我按SLA判断为P0，立即拉起告警群并回滚最近变更配置，10分钟恢复。分类为配置变更引发的内存泄漏。
可能追问	如果回滚无效怎么办？你如何确认分类是否正确？
避坑提醒	避免只讲结果不讲分类依据；不要遗漏SLA指标和分级规则。

面试问题	如何找到故障的根因？请举例说明你使用的分析框架。
面试官考察点	分析框架的使用能力（5Why、鱼骨图、时间线）能否区分直接原因、间接原因、根因是否具备数据驱动思维
回答框架	定义现象 → 连续追问Why → 定位根因 → 验证假设 → 产出改进
简短示例回答	某次数据库慢查询导致API超时。用5Why：Why慢？→ 全表扫描 → Why扫描？→ 缺少索引 → Why缺少？→ 新业务上线未评审索引 → 根因：缺乏DDL审核流程。
可能追问	如果无法复现故障，你怎么做根因分析？
避坑提醒	避免“人”作为根因（如“开发粗心”），应深挖流程或工程缺陷。

面试问题	你是怎么写故障复盘报告的？通常包含哪些部分？
面试官考察点	复盘报告结构是否完整（事实/根因/措施/跟踪）能否区分短期止血与长期改进是否具备可落地的改进建议
回答框架	故障概述 → 时间线 → 根因分析 → 影响评估 → 改进措施（Owner/截止日） → 验收标准
简短示例回答	复盘报告包含：故障时间线（精确到秒），根因分析（5Why结果），影响（影响3%用户15分钟），短期修复（重启节点），长期改进（增加健康检查+自动摘除），Owner为SRE团队，DDL下个迭代。
可能追问	改进措施未按时完成怎么办？如何衡量措施有效性？
避坑提醒	避免只写技术措施不写流程改进；措施必须有可量化验收标准。

项目名称	双11大促支付链路容量故障复盘
业务背景	电商平台双11期间，支付接口响应时间从50ms飙升到5s，部分用户支付失败，故障持续12分钟。
规模指标	QPS峰值：50万/s；影响订单量约8万笔；涉及支付网关、订单中心、缓存集群。
技术栈	Kubernetes、Nginx、Redis、MySQL、Kafka、Prometheus + Grafana
核心难点	流量突增导致Redis热Key打满熔断阈值设置过低，提前触发降级日志采集延迟，排查耗时较长
面试高频追问	为什么Redis热Key没有提前发现？熔断策略如何设计更合理？如果再次遇到，你的自动化止损方案是什么？
可迁移回答话术	“对于大促场景，我建议引入热点探测预计算机制，结合HPA动态扩缩容；熔断应基于接口SLA分级配置，同时增加半开恢复探测；日志采集改用异步批处理并提高采样率，确保3秒内可查。”

面试加分技巧：在回答故障案例时，主动说出故障等级、SLA指标、根因分析框架名称，会让面试官立刻感知到你的专业度和系统性。

避坑清单：1️⃣ 不要否认故障责任（主动承担） 2️⃣ 不要只讲技术不谈流程改进 3️⃣ 不要遗漏复盘跟踪环节 4️⃣ 避免使用模糊时间词（用具体分钟/秒）