天勤策略钉钉告警：交易信号与异常通知怎么分流
前言
策略上云之后，我和同事最怕两件事：一是真出事了没人知道，二是没事也被钉钉刷屏刷到麻木。最早接推送时图省事，在wait_update里每次last_price变就发一条，一个活跃品种白天能几百条，两天之后群里全员静音，某天进程凌晨挂了，直到早上九点半才有人发现——因为大家默认「又是行情刷屏」。
后来我们按天勤advanced/dingding.rst接好发送函数，又定了一张「分级表」：什么必须叫醒人、什么只写日志、什么一天汇总一条。推送变成运维工具，而不是行情转播站。下面写集成位置和频率习惯，Webhook 仍放环境变量，别进 git。
一、为什么要分流
不同类型消息频率差几个数量级，混在一个通道里一定失控。
| 类型 | 频率 | 建议 |
|---|---|---|
| 断线、未捕获异常、紧急平仓 | 低 | 立即推送 |
| 成交、调仓、风控拒单累计 | 中 | 合并、阈值、日终汇总 |
| 行情 tick、指标值 | 极高 | 禁止推送 |
告警疲劳的代价，是真故障被当成噪音。我们吃过亏，所以宁可少推，也不滥推。
二、集成位置
在策略初始化或循环外层接发送能力，类名参数以dingding.rst为准。禁止在每个 tick 调发送接口。
defnotify_alert(msg:str):# 按 dingding.rst 调用官方或自建发送passwhileTrue:try:api.wait_update()exceptExceptionase:notify_alert(f"[策略A] uncaught:{e}")raisenotify_alert内部也应轻量：失败写本地日志，别在循环里无限重试 HTTP，否则行情泵再次被拖死。
三、推荐触发点
这些点我倾向于推钉钉：
TqApi创建失败、连续多次wait_update长时间无更新（阈值自定）- 紧急平仓或
emergency_flat执行后 - 日终一条：各品种净持仓、当日盈亏摘要、拒单次数
- 风控拒单在同一原因下累计超过 N 次
这些点不要推：每根 K 线金叉死叉、每个 tick 价格、每次is_changing为真。
成交是否实时推，看团队风格。我倾向日终汇总 + 大额调仓即时推，中间小调仓只进文件日志。
四、频率控制
- 同一错误文本 5 分钟内只推一次，用本地时间戳去重
- 夜盘结束发汇总，而不是每笔成交一条
- 测试环境关闭推送，或打到「测试群」，避免吓到交易员
有一次测试 webhook 没改，生产群半夜连发「模拟平仓成功」，第二天被风控约谈——这种笑话能避免就避免。
五、与日志分工
| 渠道 | 内容 |
|---|---|
| 文件日志 | 全量、可检索、事后复盘 |
| 钉钉 | 需要人马上介入的事件 |
文件日志负责全量落盘；钉钉不能替代审计。监管或内控要查历史，永远以日志为准，推送只是提醒你有日志可看。
六、安全
- Webhook、密钥仅环境变量或密钥管理，不进仓库
- 消息里不打密码、不打完整资金账号
- 群成员最小权限；离职及时轮换 webhook
总结
钉钉接天勤策略，价值在「少而准」，不在「全而烦」。文档把发送能力准备好了，团队若不做分级，很快就会回到全员静音的老路。我现在的底线是：tick 绝不进钉钉，异常一定进钉钉，成交看规模在即时和日终之间取平衡。你若正准备加推送，建议先用模拟盘跑一天，数一下「如果全开会有多少条」——这个数字会帮你定阈值。往往算完，你自己都会想把一半触发点划掉。
FAQ
1）能否推企业微信？
文档若仅钉钉，其他 IM 可自研 HTTP，注意异步、短超时、失败不阻塞循环。
2）发送失败怎么办？
记本地日志，主策略继续跑或按预案停机，别在循环里死重试。
3）回测要推送吗？
关闭，避免测试消息进生产群。
4）多策略共用一个群？
消息前缀带策略名、主机名、单元名。
风险提示
本文用于期货量化技术实践讨论，不构成投资建议。