钉钉运维机器人明细策略实战:把集成异常推到群里
这个策略解决什么问题
在一个集成项目里跑了几十条同步策略之后,运维同事最痛的不是「数据没同步」,而是「我什么时候才知道它挂了」。金蝶云星空和钉钉之间每天有上百个方案在跑,光靠登录后台翻日志不现实。
「钉钉运维机器人(明细)」这条策略做的事很朴素:每隔二十分钟,主动去轻易云数据集成平台拉一次最近若干秒内的策略异常明细,再通过钉钉自定义机器人发到运维群里,让值班同学在手机上就能看到「哪个方案、哪条单据、在哪个环节报错」。
它的价值不在传输数据,而在缩短从「集成失败」到「人看见」的时间。一次实际项目里,客户原本人工巡检要 1–2 小时,上了这条策略之后基本压到 30 分钟以内,夜班告警也能在群里直接看到。
数据流向与字段映射
这条策略是「平台 → 平台 + 群消息」结构,源是轻易云自身的查询接口,目标是钉钉自定义机器人 webhook,中间不需要落库。
| 字段(源 Query 响应) | 含义 | 目标机器人字段 | 说明 |
|---|---|---|---|
| strategy_name | 方案名 | name | 群里第一眼看到的标识 |
| lessee.name | 租户名 | lessee_name | 多租户场景下区分归属 |
| number | 单据编码 | number | 定位到具体哪条单据 |
| response_at | 响应时间 | response_at | 判断是「刚刚挂」还是「一直挂」 |
| problem | 问题描述 | problem | 直接进群消息正文 |
源接口 StrategyErrorDetail 是 POST 查询接口,需要传 recentSeconds(本次查最近多少秒,这里取 600)和 ids(需要监听的方案 ID 列表,用英文逗号分隔)。目标接口 DingTalkRobotDetail 走标准钉钉自定义机器人 webhook,access_token 在机器人创建时一次性生成,明文存放在轻易云的连接器配置里,不要写死在请求脚本里。
在轻易云上如何配置
在轻易云数据集成平台里,这条策略配成两个节点:源节点是「轻易云平台」连接器,选 StrategyErrorDetail 这个 API;目标节点是「钉钉」连接器,选自定义机器人明细推送 API。
几个关键配置点:
- 方案 ID 列表维护方式:不要把所有 ID 写死在请求体里。稳妥的做法是在轻易云里建一张轻量映射表,把「业务方案名 → 方案 ID」集中管理;新增方案时只改这张表,
ids字段通过变量引用即可。 - 请求体变量化:
{{strategy_name}}、{{lessee.name}}、{{number}}、{{response_at}}、{{problem}}这些字段全部用源响应的 JSON 路径带过去,避免在目标节点再做一次解析。 - 响应不做解析:
autoFillResponse设为false,钉钉机器人只关心发送是否成功,不消费返回内容。 - 构建模型关闭:
buildModel=false,因为明细数据是「一次性消费」的,不需要建表缓存。 - 机器人 access_token 集中存放:钉钉机器人的 token 在钉钉端创建后,放到轻易云连接器的凭证管理里,只让运维角色可见;群里的同学不应该看到完整 token。
实施步骤
第一步,先把源接口跑通。在轻易云里手动触发一次 StrategyErrorDetail,确认 recentSeconds=600 能拉到数据,核对返回字段是否包含 strategy_name、lessee.name、number、response_at、problem 这五项。
第二步,配置目标节点的钉钉机器人。先在钉钉群里建一个自定义机器人,拿到 webhook 地址里的 access_token,粘贴到轻易云连接器。然后在策略里把源字段通过变量映射到目标字段,做一次手工发送,确认群里能看到完整明细。
第三步,分阶段调度。运维机器人最容易「炸群」,所以节奏要慢:
- 增量起点:先把
recentSeconds设成 600、调度设成*/20 9-20 * * *(工作时间内每 20 分钟一次),先覆盖白天。 - 全量触发:等白天稳定运行一周后,再扩到夜间,或者把
recentSeconds加大到 1800,避免深夜噪音。 - 调度频率:明细类建议 20–30 分钟一次,不要 1 分钟一次;否则群里会被刷屏,真正严重的问题反而被淹没。素材中源节点是
*/20,目标节点是*/30,这种「源比目标稍快」的拍法是有意为之,让目标侧总是有积压可发,避免空跑。
第四步,加一条兜底:同一个方案在 1 小时内连续报错超过 N 次,轻易云层面要触发告警升级(电话或短信),不能只靠机器人推送。
踩坑复盘
典型错误一:recentSeconds 和调度周期不匹配。 如果调度是每 20 分钟一次,recentSeconds 至少要比 1200 大,否则两个周期之间会有窗口漏报。
典型错误二:ids 列表忘了同步。 新上一个方案后忘了把它的 ID 加进 ids,结果这个方案挂了群里根本不响。建议把「方案上线」和「加入监控列表」做成一个 checklist。
典型错误三:机器人 webhook 泄露。 很多人把 access_token 直接贴在群里,虽然 DingTalk 机器人 token 不算高敏感凭证,但一旦被外部拿到就能伪造消息,污染运维判断。把它放在轻易云连接器里集中管理,是更稳妥的做法。
典型错误四:多租户场景下 lessee.name 没带出来。 一旦平台服务多个租户,群里不分租户,值班同学根本不知道该谁处理。源响应里 lessee.name 一定要透传到消息里。
典型错误五:群消息正文没截断。 如果直接拼字段,某些异常堆栈会非常长,钉钉机器人单条消息有长度上限,过长会发送失败。建议在轻易云的目标节点做一次截断,只保留前 N 个字符。
适用场景与不适用场景
适合「多策略、多租户、运维需要第一时间看到失败明细」的项目,尤其是金蝶云星空这种业务系统对外接口多、报错链路长的场景。
不适合「只有一两条策略」的小项目,也不适合「需要做故障归因分析」的场景——明细推送只负责告警,不负责诊断,真正的根因分析还是要回到轻易云的运行日志里看完整堆栈。