事故响应与止血：第一时间发现、快速评估影响范围、临时修复与数据回滚、通知相关方

数据质量事故一旦发生，时间就是生命。我见过太多团队把精力花在「追责」上，结果黄金抢救期白白浪费。这一章，咱们就聊聊怎么在事故发生后，用最短的时间把损失降到最低。

说白了，事故响应就四个字：快、准、稳、通。快是发现快，准是评估准，稳是止血稳，通是通知通。一个都别落下。

3.1 第一时间发现：监控告警的「黄金三分钟」

事故响应能不能快，取决于你发现得有多早。我个人习惯把监控分为三个层级：

监控层级	检测对象	典型指标	响应时效
L1 基础设施	数据管道、任务调度	任务失败率、延迟、吞吐量	1分钟内
L2 数据质量	数据内容、完整性	空值率、唯一性、值域校验	3-5分钟
L3 业务指标	下游报表、模型输出	日活异常、转化率波动	15分钟内

你想想看，如果只盯着 L1，任务跑完了但数据全是错的，你根本不知道。我在项目中遇到过，调度系统显示「成功」，结果某张核心表因为上游字段变更，整列数据都偏移了。要不是 L2 的空值率告警，这个错误会一直蔓延到周末的财报里。

3.2 快速评估影响范围：别慌，先画一张「影响地图」

告警响了，第一件事不是修，是评估。我曾经犯过一个错——看到空值率飙升就立刻去修数据源，结果修完才发现，受影响的是三个下游报表和一个推荐模型，而我只修复了其中一个管道。

评估影响范围，我建议按这个顺序来：

1. 确认数据资产：出问题的是哪张表？哪个字段？什么时间范围的数据？
2. 追踪血缘关系：谁消费了这些数据？下游有哪些 ETL 任务、报表、API、模型？
3. 量化影响程度：影响多少行数据？多少用户？是否涉及核心业务（交易、风控、合规）？
4. 判断严重等级：P0（核心业务中断）、P1（大面积数据错误）、P2（局部异常）、P3（轻微偏差）。

3.3 临时修复与数据回滚：止血要果断

评估完影响，就该动手了。这里分两种情况：

情况一：问题数据还未被下游消费

这是最理想的。直接回滚数据管道，重新跑历史数据。我习惯的做法是：

-- 示例：回滚到上一个快照
-- 假设事故表为 dwd_order_daily
-- 1. 暂停当前管道
ALTER TABLE dwd_order_daily RENAME TO dwd_order_daily_corrupted;

-- 2. 恢复快照
CREATE TABLE dwd_order_daily AS
SELECT * FROM dwd_order_daily_snapshot_20250101;

-- 3. 记录事故时间戳
INSERT INTO data_quality_incidents (table_name, incident_time, action)
VALUES ('dwd_order_daily', NOW(), 'ROLLBACK_TO_SNAPSHOT_20250101');

情况二：问题数据已被下游消费

这就棘手了。你需要：

• 临时阻断：暂停下游任务，防止错误扩散。哪怕影响业务方几分钟，也比让他们基于错误数据做决策强。
• 数据订正：写一个订正脚本，只修复受影响的行。不要全量重跑，太慢了。
• 标记异常：在数据中增加一个 `is_corrected` 字段，或者写入异常日志表，方便下游识别哪些数据被修复过。

我记得有一次，某个用户画像表的年龄字段因为上游解析 bug，把一批用户的年龄写成了 0。下游的推荐模型已经基于这批数据跑了两个小时。我们当时做的不是回滚，而是写了一个补丁任务，只修复 age=0 的记录，同时给推荐模型团队发了一个「数据修正通知」，让他们重新拉取受影响用户的数据。

3.4 通知相关方：信息同步是止血的一部分

很多人觉得通知是「善后工作」，其实不是。通知本身就是止血的一部分。为什么？因为如果你不告诉下游团队数据有问题，他们可能基于错误数据做出错误决策，那个损失比数据本身的问题大得多。

我建议的通知策略：

通知对象	通知时机	通知内容	通知渠道
数据团队内部	发现后立即	事故现象、影响范围、初步判断	即时通讯群
下游数据消费者	评估影响后	受影响的数据资产、预计修复时间、临时规避措施	邮件 + 即时通讯
业务方/管理层	确认严重等级后	事故等级、业务影响、修复进展、预计恢复时间	邮件 + 事故管理系统

通知的内容要简洁，别写长篇大论。我一般遵循「5W1H」结构：

• What：发生了什么（数据异常、管道失败、延迟）
• Where：哪个数据资产、哪个环境
• When：什么时间开始、持续多久
• Who：影响哪些团队、哪些用户
• Why：初步原因（不需要根因，给个方向就行）
• How：正在做什么、预计什么时候恢复

嗯，这里要注意一点：通知的语气要客观，不要带情绪。别说「XX 团队又搞砸了」，就说「上游数据源字段变更导致解析异常」。事故响应阶段，大家的目标是一致的——尽快恢复系统，不是追责。