第3章：故障根因分析 — 从表象到本质
SRE 面试中，“你如何处理过一个复杂故障”几乎是必考题。面试官借此评估你的逻辑推理、数据驱动决策、系统思维及复盘改进能力。本章提供一套“场景还原→数据采集→假设验证→根因定位→改进闭环”的标准化回答框架，配合三个高频面试问答卡片，帮助你在面试中展现深度与系统性。
面试问题①：请描述一次你处理过的复杂故障，你是如何定位根因的？
面试官考察点：逻辑推理是否严密；是否依赖数据而非猜测；能否还原全貌并给出系统性结论。
回答框架：遵循 STAR 原则，嵌套本章框架图。重点讲“做了什么”和“怎么想”，避免只描述现象。
S：故障规模与影响 → T：角色与目标 → A：场景还原→数据采集→假设验证→根因定位 → R：改进措施。
示例回答：“双11大促期间，用户下单成功率从99.5%骤降至60%。我首先隔离问题集群、保留现场，然后通过链路追踪发现订单服务调用库存服务超时率达到80%。进一步分析慢查询日志，发现库存表因新增字段缺少索引导致全表扫描，最终加索引并限流降级，5分钟恢复。”（98字）
可能追问：如果当时监控数据不完整你会怎么做？——答：立即启用全量日志采样，同时利用依赖图反向推断。
避坑提醒：✘ 避免只讲“重启/回滚”的临时手段而忽略根因分析；✔ 即使最终是简单问题，也要展示系统化的排查路径。
面试问题②：多个告警同时触发，如何确定哪个是根因？
面试官考察点：告警关联分析能力；对系统依赖关系的理解；优先级判断逻辑。
回答框架：分层降噪 + 时间线对齐 + 依赖图拓扑。
① 查看全局关键指标（错误率/延迟/饱和度）→ ② 按依赖关系从下游往上游排查 → ③ 对同一时间窗口内的告警分组 → ④ 对比业务变更与配置变更时间线。
示例回答：“先看核心业务错误率是否异常，若存储层告警与业务层告警同时出现，优先确认存储层（如数据库CPU飙高），因为下游故障通常会引起上游连锁反应。结合变更记录，发现刚刚上线的索引重建任务导致锁冲突，回滚后全链路恢复。”（99字）
可能追问：如果两个告警层级相同且相互独立？——答：利用日志聚合分析异常记录，谁的异常模式更符合根因（如突然上升 vs 缓慢爬升）。
避坑提醒：✘ 避免凭经验猜测常见故障；✔ 始终以数据（告警时间、指标曲线、日志内容）作为判断依据。
面试问题③：故障复盘中你学到了什么？如何防止类似问题？
面试官考察点：复盘能力；行动项是否具体可执行；是否有系统性改进思维。
回答框架：时间线复盘 → 根因归类 → 影响量化 → 行动项（短期止血 + 长期治理）。
推荐使用 5Why 追问至流程/文化层面，例如：为什么没在测试环境发现？因为测试数据量不够 → 为什么数据量不够？因为没有模拟生产流量 → 行动：建设全链路压测平台。
示例回答：“一次配置变更未经过灰度导致全量故障。我们复盘后引入 Canary 发布机制，每个变更先在 1% 节点上运行 15 分钟，观察错误率。同时建立变更评审会，开发与 SRE 双签确认。后续类似变更再未触发故障。”（88字）
可能追问：如何确保改进措施被团队长期执行？——答：将行动项写入 runbook，并通过定期混沌工程演练验证有效性。
避坑提醒：✘ 避免只讲教训而没有具体改进；✔ 行动项要可量化、可验收，例如“增加告警规则”而不是“加强监控”。