1. 风控稳定性巡检概述
1.1 风控系统稳定性的重要性
在实时风控体系中，系统稳定性是业务安全的生命线。一次短暂的规则引擎抖动、Flink 作业反压或 CEP 状态回溯延迟，都可能导致数万笔交易在无风控保护下通过，或误杀大量正常用户请求。稳定性巡检不是可选项，而是保障风控 SLA 的核心手段。
关键数据： 某头部支付平台统计，风控系统每宕机 1 分钟，平均造成约 120 万元欺诈损失；每发生一次规则误杀（假阳性率上升 0.5%），影响约 3 万笔正常交易。
1.2 巡检目标
风控稳定性巡检围绕以下四个核心目标展开：
| 目标维度 | 具体描述 | 关键指标示例 |
|---|---|---|
| 可用性 | 风控服务持续对外提供决策能力，无中断或降级 | 服务可用率 ≥ 99.99% |
| 时效性 | 事件从接入到输出决策的端到端延迟可控 | P99 延迟 ≤ 200ms |
| 准确性 | 规则命中、模型打分、名单匹配结果正确无误 | 规则命中率偏差 ≤ 1% |
| 一致性 | 多副本、多集群间状态与决策结果保持一致 | 状态快照校验通过率 100% |
1.3 巡检范围
巡检覆盖风控系统全链路，从数据接入到最终决策输出，包含以下关键层次：
- 数据接入层： Kafka/RocketMQ 消费延迟、消息积压量、序列化/反序列化异常率。
- 计算引擎层： Flink 作业 Checkpoint 失败率、反压水位、算子繁忙度、状态大小与 RocksDB 读写性能。
- 规则与模型层： CEP 模式匹配超时、规则编译失败、模型加载异常、特征缺失率。
- 存储与状态层： Redis/MySQL 连接池水位、状态后端 I/O 延迟、快照文件完整性。
- 决策输出层： 结果回写延迟、下游回调超时、决策日志落盘成功率。
巡检边界提示： 建议将基础设施层（网络、CPU、内存、磁盘）的监控交给 SRE 团队，风控巡检聚焦于业务语义层面的稳定性，避免职责重叠。
1.4 巡检频率与时机
不同巡检对象的敏感度和影响面不同，需要差异化设定巡检频率。以下为推荐策略：
| 巡检类型 | 推荐频率 | 典型时机 | 说明 |
|---|---|---|---|
| 秒级巡检 | 每 5~10 秒 | 7×24 持续运行 | Flink 作业反压、Kafka 消费延迟、Checkpoint 状态 |
| 分钟级巡检 | 每 1~5 分钟 | 7×24 持续运行 | 规则命中率波动、模型打分分布、状态大小变化 |
| 小时级巡检 | 每 1 小时 | 整点或半点 | 全链路端到端延迟、数据一致性校验、日志完整性 |
| 日级巡检 | 每日 1 次 | 业务低峰期（凌晨） | 状态快照全量比对、规则变更审计、模型版本回滚检查 |
| 事件驱动巡检 | 按需触发 | 发布后、故障后、大促前 | 版本上线后立即执行全链路冒烟巡检 |
巡检时机避坑： 避免在业务高峰期执行全量状态快照比对或大范围规则重载，这类操作会额外消耗 I/O 和 CPU，可能引发连锁反压。建议将重载型巡检安排在低峰窗口，并设置熔断降级开关。
1.5 巡检与监控的边界
巡检与实时监控是互补关系，但职责不同：
- 实时监控： 持续采集指标，触发阈值即告警，关注“当前是否异常”。
- 稳定性巡检： 按固定节奏执行深度检查，关注“系统是否健康”，包含监控无法覆盖的离线校验、数据一致性比对、状态快照完整性验证等。
最佳实践： 将巡检结果作为监控告警的二次确认源。例如：监控发现 Checkpoint 失败率升高，巡检随即触发全量状态快照校验，定位具体失败算子与状态文件，避免误告警或漏报。