大数据面试怎么讲一次线上故障？只说重跑恢复为什么不够？
本文目录
面试怎么回答
我会先说明故障影响了哪些数据和消费者，再按时间线讲观察证据、最初假设及排除过程。止损与最终修复分开，重跑前确认范围和幂等，恢复后核对完整性、重复与下游结果，而不是只看任务变绿。最后说明根因、监控或流程改进以及验证方式。只讲自己实际参与的部分，没有可靠数字就不虚构效果。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
面试官问：“线上出过什么问题？”你回答：“上游延迟导致任务失败，后来重跑好了。”这句话说明任务曾经失败，却没有说明你怎样判断、重跑是否安全，以及坏数据有没有真正修复。
一段可信的故障复盘，要连接影响、证据、止损、数据修复和防复发；恢复执行与恢复正确数据必须分开证明。
从影响开始，而不是从报错名称开始
一段故障描述先回答业务为何在意：哪段时间、哪些分区或对象、哪类消费者受影响，表现为延迟、缺失、重复还是错误结果。
如果只说某个异常类名，面试官不知道这是一个自动重试即可恢复的小故障，还是已经传播到多个报表的结果错误。
范围应以证据为准。只确认了一个业务日，就说已确认一个业务日；其他日期尚未检查，就保留不确定性。不要用“全平台都挂了”营造严重程度。
把当时的假设与最终根因分开
排查并不要求第一分钟就猜中。可以说明最初为什么怀疑上游延迟，后来哪条日志、哪组样本或哪段SQL否定了这个判断。
真正有价值的是证据如何改变行动。比如任务成功但缺失数据，说明仅查调度状态不足；重跑仍错且差异固定在某些键，可能需要继续追踪关联条件或版本边界。
不要把最终结论写成一开始就知道的事实。合理的排除过程更能体现诊断能力，也方便面试官追问你为什么没有选择其他方向。
止损措施与根因修复不是同一动作
暂停错误输出、回退到可信版本、临时隔离异常数据，都可能是止损；它们不一定解决产生故障的原因。
采取动作前，要确认影响范围和授权。不能把直接修改线上数据、扩大重跑范围或删除状态描述成当然正确的应急手段。
如果你只负责定位并提出建议，执行由其他人完成，就如实说清分工。无需把团队所有操作都包装为自己的个人贡献。
一个典型场景：重跑成功后，报表仍不可信
下面是一个通用复盘示例，不代表Wood或读者的真实经历。假设上游迟到导致日报缺数，补齐后重跑任务变绿，但下游金额反而偏高。
起初认为还有一批补录数据，排查发现目标使用追加写入，第一次部分输出并未清理或幂等覆盖，重跑把已处理数据又写了一遍。
旧验收只看调度成功与总行数增长，没有检查目标业务键重复，也没有核对同一输入范围的金额。修复应先确认受影响范围，再按批准的幂等重建或纠正流程处理，最后检查下游消费结果。
这个例子中，上游恢复只是第一阶段；任务重跑是处理动作；数据真正正确，需要另一次独立验收。三个阶段不能缩成一句“后来好了”。
恢复证据至少覆盖结果和传播范围
可以说明检查了哪些日期、哪些主键、哪些核心金额与空值，以及下游报表或接口是否读取到正确版本。检查项应与故障类型相匹配，而不是每次都背同一张清单。
如果重复已经被下游聚合吸收，修好明细并不意味着汇总自动恢复。需要确认依赖传播和重算边界，也要检查外部通知等无法简单回滚的副作用。
效果数字只能来自真实记录。没有准确恢复时长，就说明恢复经过，不要编造几分钟解决；没有同口径前后数据，就不要随意声称降低了某个百分比。
防复发措施要和根因一一对应
如果根因是重跑不幂等，只加一个失败告警不够；如果根因是上游完整性没有校验，只增加机器资源也解决不了。
改进可以包括输入就绪判断、幂等写入、边界单测、发布门禁或可追溯运行记录，但每项都要说明怎样验证它能够拦住同类问题。
还应区分已经实施、已经验证和仍在计划中的措施。面试不是写愿望清单，把尚未落地的想法当成既成成果，会在追问时失去可信度。
准备一分钟主线，再准备可展开的证据
一分钟里讲影响、关键判断、恢复与验证，深入追问时再展开日志、SQL和取舍。提前准备去敏后的信息，不暴露客户、账号、内部凭证或不应公开的数据。
好案例不一定规模最大。一个范围明确、推理完整、修复可验证的故障，比堆满组件名却说不清结果的“大事故”更能体现实际能力。