4. 哨兵告警系统定位：哨兵在风控体系中的角色、告警与监控的区别、实时 vs 离线告警
4.1 哨兵在风控体系中的角色
在量化风控体系中，哨兵告警系统并非一个独立的决策引擎，而是位于监控层与响应层之间的关键枢纽。它的核心角色可以概括为：“风险信号的最后一公里”——将模型回测、实时评分、资产质量等数据转化为可执行的告警事件。
哨兵系统在风控体系中的具体职责包括：
- 信号捕获：从回测引擎、实时计算平台、离线数仓中采集坏账率、逾期率、评分分布等关键指标。
- 规则判定：基于预设的阈值、趋势、波动规则，判断当前指标是否触发告警条件。
- 分级通知：根据告警严重程度（P0/P1/P2），通过邮件、短信、即时通讯工具通知对应责任人。
- 闭环跟踪：记录告警产生、确认、处置、恢复的全生命周期状态，形成可追溯的审计链路。
关键认知：哨兵系统不直接干预风控决策（如拒绝/通过），而是为风控策略人员提供“风险仪表盘”和“异常触发器”，帮助团队在坏账率恶化前采取干预措施。
4.2 告警与监控的区别
在实际工程中，监控和告警经常被混用，但它们在风控体系中有明确的职责边界。理解这一区别，是设计哨兵系统的前提。
| 维度 | 监控 (Monitoring) | 告警 (Alerting) |
|---|---|---|
| 核心目标 | 持续观察系统状态，记录指标变化趋势 | 在异常发生时，主动通知相关人员或系统 |
| 输出形式 | 仪表盘、趋势图、报表 | 邮件、短信、即时消息、Webhook |
| 触发条件 | 周期性采集（如每分钟、每小时） | 规则匹配（阈值、同比、环比、波动） |
| 响应要求 | 无需立即响应，用于事后分析 | 需要及时响应，通常有SLA要求 |
| 数据粒度 | 全量数据，包含正常与异常 | 仅异常数据，过滤掉正常状态 |
| 典型场景 | 查看今日坏账率趋势 | 坏账率突增超过阈值，触发P0告警 |
实践建议：监控是“看”，告警是“动”。一个好的哨兵系统，应该先建立完善的监控体系（数据采集+可视化），再基于监控数据配置告警规则。没有监控基础的告警，容易产生“盲警”或“漏警”。
4.3 实时 vs 离线告警
根据数据源和处理时效的不同，哨兵告警可以分为实时告警和离线告警两类。它们在风控场景中各有用途，通常需要组合使用。
4.3.1 实时告警
实时告警基于流式计算或事件驱动架构，在数据产生后毫秒级或秒级内完成判定和通知。适用于对时效性要求极高的场景。
- 数据源：实时评分、实时交易流水、实时拒绝率。
- 典型规则：连续5分钟内拒绝率超过50%；单笔坏账金额超过10万元。
- 技术栈：Kafka + Flink / Spark Streaming + 告警引擎。
- 响应方式：自动熔断、限流、即时通知值班人员。
4.3.2 离线告警
离线告警基于批处理或定时任务，在数据完成ETL后（通常T+1）进行判定。适用于对准确性要求高、但时效性要求相对宽松的场景。
- 数据源：离线数仓、回测结果表、资产质量宽表。
- 典型规则：当日坏账率较前7日均值上升超过20%；回测AUC下降超过0.02。
- 技术栈：Hive / Spark SQL + 定时调度（Airflow / DolphinScheduler）。
- 响应方式：生成告警工单、发送日报/周报、触发人工复核。
4.4 哨兵告警系统的核心能力矩阵
综合以上角色定位和分类，一个成熟的哨兵告警系统应具备以下核心能力：
| 能力维度 | 能力描述 | 优先级 |
|---|---|---|
| 多源接入 | 支持实时流（Kafka）和离线批（Hive）数据源 | P0 |
| 规则引擎 | 支持阈值、同比、环比、波动、组合规则 | P0 |
| 分级告警 | P0（严重）/ P1（警告）/ P2（提示）三级体系 | P0 |
| 通知渠道 | 邮件、短信、企业微信/钉钉、电话 | P1 |
| 告警抑制 | 防止重复告警、告警风暴 | P1 |
| 告警回溯 | 记录告警产生、确认、处置、恢复全链路 | P1 |
| 自愈能力 | 自动恢复后自动关闭告警，减少人工操作 | P2 |
常见误区：不要试图用一套规则覆盖所有场景。实时告警和离线告警的规则设计思路不同——实时规则要“快而准”，避免误报；离线规则要“全而稳”，避免漏报。建议分别维护两套规则配置。