3. 实时风控稳定性巡检概述
实时风控系统对延迟和准确率有极高要求，任何稳定性问题都可能导致资损或用户体验下降。稳定性巡检是主动发现隐患、防止故障蔓延的第一道防线。本章从目标、范围、触发机制及与告警的关系四个维度，系统阐述巡检体系的设计原则。
3.1 巡检的目标
稳定性巡检的核心目标可归纳为以下四点：
| 目标维度 | 说明 | 关键指标示例 |
|---|---|---|
| 提前发现 | 在故障影响业务前，通过趋势分析和阈值预警识别潜在风险 | CPU 使用率趋势、GC 频率、连接池水位 |
| 快速定位 | 当异常发生时，通过巡检链路快速缩小故障范围 | 响应时间分位值、错误码分布、上下游超时率 |
| 持续验证 | 确保系统变更、配置下发、模型更新后仍保持稳定 | Drift 检测通过率、模型推理一致性 |
| 量化度量 | 用数据驱动稳定性改进，避免主观判断 | 巡检覆盖率、巡检通过率、MTTR |
实践要点：巡检目标必须与业务 SLA 对齐。例如，支付风控场景下，巡检应优先覆盖“决策延迟 > 200ms”和“模型调用失败率 > 0.1%”等高敏感指标。
3.2 巡检的覆盖范围
实时风控系统的巡检覆盖范围应包含基础设施、中间件、应用层、数据层和业务逻辑五个层面。下图展示了典型的巡检覆盖架构：
巡检范围优先级：建议按“业务影响度”排序。先覆盖核心决策链路（应用层 + 数据层），再逐步扩展到中间件和基础设施。避免一开始就追求全量覆盖导致巡检系统自身成为瓶颈。
3.3 巡检的触发机制
巡检触发机制决定了巡检的时效性和资源消耗。根据业务场景，通常采用以下三种触发方式：
- 定时触发：按固定周期（如每分钟、每5分钟）执行全量或抽样巡检。适用于基础设施、中间件等变化较慢的指标。
- 事件触发：当特定事件发生时（如模型发布、配置变更、流量突增）立即触发巡检。适用于变更验证和故障应急场景。
- 条件触发：基于指标阈值或趋势预测，当系统状态进入“亚健康”区间时自动触发深度巡检。适用于资源水位、响应时间等动态指标。
| 触发类型 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| 定时触发 | 基础设施、中间件健康检查 | 实现简单、可预测 | 可能错过突发异常 |
| 事件触发 | 变更发布、配置下发 | 响应及时、针对性强 | 依赖事件源可靠性 |
| 条件触发 | 资源水位、响应时间趋势 | 智能、节省资源 | 阈值设置需要调优 |
避坑提示：条件触发巡检的阈值设置不宜过窄。过窄会导致频繁触发，浪费计算资源；过宽则失去预警意义。建议结合历史数据使用动态基线（如 3σ 或百分位法）自动调整阈值。
3.4 巡检与告警的关系
巡检和告警是稳定性保障体系中两个紧密关联但职责不同的环节。巡检负责“发现”，告警负责“通知”。下图展示了二者的协作流程：
巡检与告警的协作遵循以下原则：
- 巡检是告警的前置条件：巡检负责采集和判断，告警负责将判断结果以合适的方式通知到人。
- 告警降噪依赖巡检质量：巡检的误报率直接影响告警的有效性。高精度巡检可以大幅减少无效告警。
- 告警升级策略：当巡检连续多次发现同一异常，或异常指标持续恶化时，告警级别应自动升级。
- 巡检结果反馈闭环：告警处理后，应将处理结果反馈给巡检系统，用于优化后续巡检策略（如调整阈值、增加巡检频率）。
最佳实践：建议将巡检和告警解耦为独立模块。巡检模块只负责“检测”和“判断”，告警模块负责“通知策略”和“升级规则”。这样当告警方式变更时，巡检逻辑无需修改。