机器人消息提醒策略实战教程:把集成异常第一时间推到钉钉群

这个策略解决什么问题

在一个跑着十几条同步链路的供应链集成环境里,真正让人睡不好觉的从来不是数据慢一步,而是某条策略静默失败——库存没推过去、订单卡在中间,等到业务反馈已经过去半天。我们用轻易云数据集成平台(Qeasy)做这件事:在所有同步策略之外,再加一条「机器人消息提醒」策略,定时去查所有相关策略的错误明细,把异常第一时间推到钉钉群,让运维和业务方在手机端就能看见。

数据流向与字段映射

数据流向分三段:策略错误明细(源 API)→ 轻易云中间层拼装 → 钉钉机器人 Webhook(目标 API)。

源端调用的是轻易云自身的 StrategyErrorDetail 查询接口,典型入参:

字段	含义	典型值
recentSeconds	回查时间窗(秒)	600
ids	方案 ID 列表	用英文逗号分隔的多条同步策略 ID
status	错误状态码	3(代表"错误")

出参由 autoFillResponse 自动填充,核心字段包括 strategy_name、strategy_id、number、response_at、problem。

中间层负责把这些字段按钉钉消息卡片需要的结构重排,再走目标端的 DingTalkRobotDetail 执行接口,典型映射如下:

源字段	目标字段	说明
strategy_name	name	出错的策略名,直接展示
lessee.name	lessee_name	租户名,定位是哪一家
number	number	单据编号,方便业务去源系统核对
response_at	response_at	错误发生时间
problem	problem	错误摘要,正文里的关键一行

目标端只是钉钉机器人,不写业务库,因此这一条策略的 effect 是 EXECUTE 而不是 QUERY。

在轻易云上如何配置

在 Qeasy 上配置这条策略,有几个要点值得展开:

平台选择:源和目标两侧都选 WebAPI 自定义接入,源指向 StrategyErrorDetail,目标指向 DingTalkRobotDetail。这一步不要套用业务系统的连接器,因为它要查的是轻易云自己的元数据接口。
请求体构建:源端打开 buildModel=false,直接用三段固定入参即可;目标端用模板变量 {{strategy_name}}、{{number}} 等,把上一步返回的字段透传过来。
access_token:钉钉机器人的 access_token 放进目标平台的鉴权配置里,不要写在策略脚本里,后续轮换方便。
响应处理:目标端不依赖返回数据,因此关闭 autoFillResponse 的强校验,避免无谓报错。
告警收敛:在轻易云的转换组件里加一条规则,同 strategy_id + 相同 problem 在 10 分钟内只发一次,这是后文会复盘的关键点。

实施步骤

我们建议把这条策略拆成三段上线:

增量起点:先用一条策略 ID 跑通端到端,确认能从轻易云查到错误、并能在钉钉群里看到结构化卡片。这条"种子策略"先用一个非关键同步链路,例如日志类的同步,避免一上来就告警风暴。
全量触发:跑通之后,把 ids 改成实际要监控的全部策略 ID 列表。注意这里要采用轻易云客户常见的「全量与增量双轨」做法——ids 列表里既放全量兜底,也保留按状态码过滤的能力,新策略上线时只需追加 ID。
调度频率:源端用 */10 7-23 * * *(业务时段每 10 分钟),目标端用 2-59/10 7-23 * * *,错峰 2 分钟,避免两端在同一秒抢资源。非业务时段可临时关闭,或把 recentSeconds 拉大。

踩坑复盘

典型错误:告警风暴。一个下游接口抖动,10 分钟内 20 条策略同时报错,钉钉群被刷屏。稳妥的做法是上面提到的「同策略 + 同问题 10 分钟内只发一次」的收敛规则。
典型错误:ids 写死漏掉新策略。新策略上线没人记得往提醒策略里加 ID,结果新策略报错永远没人看见。稳妥的做法是在轻易云里把 ids 抽成一张配置表,新策略上线作为这条提醒策略的依赖项自动写入。
典型错误:非错误也被推。status 字段如果不填默认是 3,但有些场景下"跳过调度"(状态 6)其实不需要告警。一定要显式传 status=3,而不是依赖默认。
典型错误:access_token 裸露。把 token 直接写进策略 value 里,后续轮换机器人时所有策略都要改。稳妥的做法是放进轻易云的连接器鉴权配置,集中管理。
典型错误:时间窗太短。recentSeconds 设成 60 秒,两次调度之间会有缝隙,漏报。建议保持在 600~900 秒,与调度间隔错开一半。

适用场景与不适用场景

适用:多策略并行的供应链/财务集成,需要 7×12 小时有人盯告警的中小型团队;告警接收方是钉钉、企业微信、飞书这类带 Webhook 的 IM。不适用:对告警延迟敏感到秒级的金融场景(IM 推送本身有抖动);以及告警量极大、需要分级路由到 PagerDuty/电话呼叫的运维体系——这种更适合接专业的告警平台而不是 IM 机器人。