钉钉报错提醒策略实战教程：基于轻易云的集成异常实时通知

这个策略解决什么问题

做供应链集成的同学几乎都被同一件事折磨过：晚上回家的地铁上，群里突然蹦出一条"销售订单同步失败"，而平台其实 30 分钟前就已经报错，只是没人看到。钉钉报错提醒这条策略干的就是把"平台知道、人不知道"这个鸿沟填上——它不搬运业务数据，只负责每隔几分钟去问一次"哪些策略挂了"，把结果用钉钉机器人推给值班人。

数据流向与字段映射

这条策略是平台内部的「自我巡检」型闭环，源和目标都不是业务系统，而是轻易云自己的两个 WebAPI。

中间没有数据落库，全靠请求体里的占位符 {{strategy_name}}、{{number}}、{{response_at}} 把源接口的响应字段一一喂给钉钉消息体。recentSeconds 默认填 300 秒，刚好对齐后面的调度周期，避免漏报也避免重复打扰。

在轻易云上如何配置

源接口配置：API 选 StrategyErrorDetail，类型 WebAPI、效果 QUERY、POST。请求体里两个字段是核心——recentSeconds 写死 300，ids 填需要监控的策略编号，多个用英文逗号分隔。响应字段直接勾上 strategy_name、strategy_id、number、response_at、problem，平台会自动回填。

目标接口配置：API 选 DingTalkRobotDetail，类型 WebAPI、效果 EXECUTE、POST。access_token 在钉钉群 → 群设置 → 智能群助手 → 添加机器人 → 自定义机器人里拿到，配置时把它放进轻易云的凭证管理而不是明文贴请求体。消息体的 name、number、response_at、problem 一律用 {{}} 占位符引用源接口的同名字段。

整体策略：把这两个接口串成一个策略，注册到调度中心即可。所有客户常见的「凭证集中管理、占位符透传字段」在这里都用得上。

实施步骤

1. 建一个独立的「告警通道」策略：不要塞进任何业务策略里，单独建一条命名清晰的策略，方便后续单独启停。
2. 圈定监控范围：ids 字段先用 1~2 个高频失败策略做联调，跑通后再批量替换成全量策略编号。一次性塞 60 个 ID 不利于排错。
3. 调度频率：源策略 crontab 写 */5 8-22 * * *（每 5 分钟一轮，覆盖白天作业时段），目标策略错开写成 1-59/5 8-22 * * *，避免同一秒两个接口抢资源，也避免告警与业务策略同步撞车。
4. 消息模板：钉钉文本里建议带 strategy_name、number（单据号）、response_at（失败时间）、problem（错误摘要）四要素，值班人一眼能定位。
5. 值班兜底：8-22 点之外的时间段要么停掉，要么把告警频次拉长到 30 分钟一轮，深夜告警疲劳反而让人忽略真问题。

踩坑复盘

1. recentSeconds 写太大。一次客户把 300 改成 3600，结果同一笔失败每 5 分钟重报一次，群里刷屏。稳妥做法是让它与调度周期一致，最多略大一点做防漏。
2. ids 一次性塞全部策略。策略一多，响应体里失败记录交叉，定位耗时翻倍。稳妥做法是分阶段：先核心业务（订单、库存），再补外围。
3. access_token 裸写在请求体。钉钉机器人 token 一旦泄露，群消息可被伪造。必须走轻易云的凭证管理，或放私有化环境的安全变量里。
4. 没有 idCheck 意识。这条策略本身 idCheck=true，但很多同学复制到其他策略时顺手关掉，导致失败单据漏报。
5. 告警群拉太多人。全公司 200 人进群，告警等于没告警。建议只拉运维 + 当事业务负责人，且在钉钉群里开「强提醒」仅对值班人。

适用场景与不适用场景

适用：私有化部署、有多个集成策略需要统一监控、运维需要被动接收而非主动巡检的场景。不适用纯 SaaS 轻量集成（一条策略就能数完的体量）、以及告警必须经过审批流才能外发的强合规场景——后者要走企业内部的 IM 审批网关，不能直接走自定义机器人。