1. 精算模型延迟告警背景
1.1 精算模型批处理流程
在保险公司的准备金评估体系中，精算模型通常以批处理（Batch Processing）方式运行。整个流程按时间窗口划分为多个阶段，每个阶段依赖上游数据产出，形成严格的DAG（有向无环图）依赖链。
| 阶段 | 任务描述 | 典型耗时 | 依赖上游 |
|---|---|---|---|
| E1 | 保单数据抽取与清洗 | 20 min | 核心系统 |
| E2 | 理赔链路归因与截断 | 15 min | E1 |
| E3 | 精算假设参数加载 | 5 min | 参数库 |
| E4 | 逐单准备金计算（核心） | 60 min | E2, E3 |
| E5 | 聚合校验与报表输出 | 10 min | E4 |
整个批处理窗口通常被限定在凌晨 02:00 – 06:00 的静默时段内完成，以保证日间业务系统不受影响。
关键约束： 精算模型批处理是“单链串行 + 局部并行”结构，任何上游阶段的延迟都会向下游传递，最终导致整体完成时间超出窗口。
1.2 延迟对准备金评估的影响
准备金评估具有强时效性要求。延迟带来的直接后果包括：
- 评估结果滞后： 准备金数据无法在监管截止时间前报送，面临合规风险。
- 决策失真： 管理层基于过时数据调整再保策略或产品定价，可能造成重大误判。
- 连锁故障： 下游偿付能力报告、资产负债匹配模型因缺少输入而阻塞，形成“延迟雪崩”。
| 延迟时长 | 影响等级 | 典型后果 |
|---|---|---|
| < 15 min | 轻微 | 报表延后，可人工追赶 |
| 15 – 45 min | 中等 | 监管报送窗口压缩，需紧急报备 |
| > 45 min | 严重 | 当日无法完成评估，触发业务连续性预案 |
1.3 尖峰告警的定义与业务价值
尖峰告警（Spike Alert） 并非简单的“超时告警”，而是指在批处理流程中，某个环节的运行时长突然偏离历史基线 3 个标准差以上，且持续时间超过预设阈值时触发的实时告警。
- 与传统阈值告警的区别： 传统告警只判断“是否超过固定阈值”，尖峰告警关注“相对异常”，能更早发现隐性故障。
- 业务价值：
- 提前止损： 在延迟扩散到下游前定位瓶颈，平均缩短故障恢复时间 40% 以上。
- 精准排障： 通过尖峰时段 SQL 执行计划快照，直接锁定慢查询或锁等待。
- 容量规划： 积累尖峰模式，为资源扩容和 SQL 重构提供数据支撑。
实战经验： 某寿险公司上线尖峰告警后，准备金批处理延迟事件从月均 12 次降至 2 次，且 80% 的告警在 5 分钟内完成自动根因定位。
1.4 为什么选择 SQL 作为告警实现载体
精算模型的核心计算逻辑大量依赖复杂 SQL（多层嵌套、窗口函数、大表关联），延迟根因往往隐藏在 SQL 执行计划中。直接使用 SQL 实现尖峰告警具有以下优势：
- 零架构侵入： 无需引入额外监控中间件，直接在数据库层采集执行时长与等待事件。
- 细粒度定位： 可精确到 SQL_ID、执行计划步骤、锁对象，比应用层日志更精准。
- 低延迟反馈： 通过轮询系统视图（如
pg_stat_activity/sys.dm_exec_requests），秒级感知异常。
注意： SQL 实现方案对数据库性能有一定消耗，需控制采样频率（建议 5–10 秒/次），避免监控本身成为延迟源。