第21章:风控告警系统

告警系统,说白了就是做市商的「神经末梢」。

我见过太多团队,策略写得漂亮,回测曲线完美,一上线就出问题。为什么?因为没人告诉他们在出事。等发现的时候,仓位已经爆了,亏损已经成了定局。

所以这一章,我们来聊聊怎么搭一套靠谱的告警系统。我个人习惯把它分成四个模块:告警级别、规则引擎、通知渠道、升级机制。咱们一个一个说。

21.1 告警级别定义

不是所有异常都值得半夜爬起来处理。我刚开始做风控时,恨不得每个小波动都报警,结果呢?团队所有人对告警都麻木了。这叫「狼来了」效应。

所以,告警级别必须分清楚。我一般用四级制:

级别 名称 含义 响应要求
P0 致命 系统不可用、资金损失、严重违规 立即处理,5分钟内响应
P1 严重 策略异常、连接中断、数据延迟 15分钟内响应
P2 警告 指标接近阈值、资源使用率高 1小时内处理
P3 提示 日常运维信息、非紧急状态 记录即可,无需立即处理
我的经验:P0和P1的告警,一定要有「人工确认」机制。我曾经遇到过P0告警发了,值班人员没看到,结果半小时后才发现。从那以后,我要求P0告警必须人工点「已确认」,否则每2分钟重发一次。

21.2 告警规则引擎

规则引擎是告警系统的「大脑」。你想想看,如果每条告警都要手写if-else,那维护成本得多高?

我推荐用规则引擎的方式,把告警条件做成可配置的。核心思路就三个要素:

  • 指标:你要监控什么?比如持仓量、敞口、延迟、成交率
  • 条件:什么情况下触发?比如大于某个值、小于某个值、连续N次异常
  • 动作:触发了怎么办?比如发邮件、发短信、调用webhook

举个例子,一个典型的规则配置长这样:

{
  "rule_id": "POSITION_LIMIT_001",
  "name": "持仓超限告警",
  "metric": "position_size",
  "condition": {
    "operator": "gt",
    "value": 1000000,
    "duration": 60
  },
  "level": "P1",
  "actions": ["email", "sms", "webhook"]
}

这里有个细节:duration: 60 表示持续60秒都超限才触发。为什么要加这个?

因为市场瞬间的毛刺太多了。如果不加持续时间,你会被假告警烦死。我见过一个团队,没加这个参数,结果一天收到2000条告警,全是市场瞬间波动导致的。后来加了3秒的持续判断,告警量直接降到每天20条。

21.3 告警通知渠道

不同级别的告警,通知渠道应该不一样。这个道理很简单:P0告警你肯定不希望只发个邮件,因为没人会实时看邮件。

我一般这样分配:

  • P0:电话 + 短信 + 即时通讯(如企业微信、钉钉)
  • P1:短信 + 即时通讯
  • P2:即时通讯 + 邮件
  • P3:仅邮件,或者直接写入日志
注意:不要把所有渠道都用在所有级别上。否则P3告警也会给你打电话,那跟没分级有什么区别?我曾经接手过一个项目,P3告警也发短信,结果运维人员直接把短信通知关了——连P0都收不到了。

另外,通知渠道要有「降级」机制。比如短信服务挂了,自动切换到即时通讯。这个在架构设计时就要考虑进去。

21.4 告警升级机制

这是很多人容易忽略的点。告警发出去,没人处理怎么办?

升级机制就是解决这个问题的。核心逻辑很简单:如果告警在规定时间内没有被确认或解决,就自动升级到更高层级的人。

我常用的升级策略:

  1. 第一级:值班工程师,响应时间5分钟
  2. 第二级:值班工程师未响应,升级到技术负责人,响应时间10分钟
  3. 第三级:仍未响应,升级到部门负责人,响应时间15分钟
  4. 第四级:最终升级到CTO或CEO

升级的时间间隔,我建议根据告警级别动态调整。P0的升级间隔可以短一些,比如2分钟;P2的可以长一些,比如10分钟。

避坑指南:我曾经犯过一个错误——升级机制没有「闭环」。告警升级到CTO后,CTO处理完了,但值班工程师不知道。结果第二天复盘时,值班工程师说「我没收到告警啊」,其实是他没确认。从那以后,我要求所有告警处理完成后,必须通知到所有相关人,包括最初的值班人员。

21.5 整体架构图

说了这么多,咱们用一张图把整个告警系统的流程串起来:

风控告警系统架构图 数据源 行情/交易/风控指标 告警规则引擎 指标 + 条件 + 动作 告警级别判定 P0/P1/P2/P3 通知渠道 电话/短信/IM/邮件 升级机制 逐级升级 + 超时重试 人工确认/处理 确认 → 处理 → 关闭 闭环反馈 通知所有相关人

这张图把整个流程串起来了:数据源进来,经过规则引擎判断,再根据级别走不同的通知渠道,最后通过升级机制确保告警被处理,处理完还要闭环通知。

21.6 一些实战建议

最后,分享几个我在实战中踩过的坑:

  • 告警去重:同一个告警在短时间内重复触发,只发一次。否则你会被刷屏。
  • 告警聚合:类似的问题合并成一条告警。比如「10个交易对同时延迟」,不要发10条,发1条带列表的。
  • 静默期:告警处理期间,不要再发同样的告警。这个我吃过亏——处理P0告警时,手机一直在震,差点把手机摔了。
  • 告警日志:所有告警都要记录,包括谁处理的、什么时候处理的、处理结果是什么。这是复盘的基础。
一个小技巧:告警消息里一定要带上「如何解决」的指引。比如「持仓超限,请执行减仓操作,参考文档:xxx」。这样值班人员不用翻文档,直接就能处理。我见过太多告警消息就一行字「持仓超限」,然后值班人员一脸懵。

嗯,告警系统这块,说白了就是「让正确的人在正确的时间,用正确的方式,知道正确的事」。架构不难,难的是细节。希望这一章能帮你少走一些弯路。


交易系统化学习资料 微信Strategy888888