企微报错提醒策略实战:让集成任务失败第一时间有人接管

这个策略解决什么问题

跑过集成方案的工程师都懂一个痛点:夜里某个同步任务静默失败,早上业务方找过来才发现断了好几个小时。 「企微报错提醒」就是把这个口子堵上——只要轻易云(Qeasy)上的方案执行出错,机器人立刻把策略名、单据编号、错误时间推到企业微信群里,责任人直接接手。 我们建议把它放在整个集成链路的"最后一公里",作为旁路观测策略独立运行。

数据流向与字段映射

这条策略的流向比较特别,它不搬业务数据,而是搬"平台自己的报错数据"。

源端是轻易云集成平台内部的一个查询接口,目标端是企业微信群机器人 WebAPI。两边都部署在公有云,中间不需要落库。

注意 access_token 是企微机器人的凭据,在轻易云里走连接器的鉴权参数,不会出现在每条消息体里。

在轻易云上如何配置

打开轻易云数据集成平台,新建一条策略,选「WebAPI」作为源类型,目标也选「WebAPI」(企微机器人推送)。

源端配置要点:api 选 StrategyErrorDetail,effect 选 QUERY,method 选 POST。把需要监控的方案 ID 填到 ids 字段,多个用英文逗号分隔,这样机器人只推送你关心的那几条策略,不会刷屏。recentSeconds 建议给一个略大于调度周期的值,避免同一条错误被重复拉取。

目标端配置要点:api 选 WeChatRobotDetail,effect 选 EXECUTE。access_token 走企微机器人连接器,不要硬编码在请求体里。其他字段通过变量映射把源端返回的 strategy_name、number、response_at、problem 拉过来,lessee_name 走租户上下文变量。

这一套走下来,源和目标都是轻易云自家接口,所以编码映射集中管理这件事天然就成立——你不需要为它单独建一张映射表,平台上下文就是它的"映射中心"。

实施步骤

分三个阶段推进,节奏稳一些。

第一阶段,观察期(全量触发)。先把监控范围放开,设一个 7×24 小时的全量观察窗,让轻易云把所有报错都推到群里。这样做的好处是先摸清"正常情况下一天大概多少条报错",避免后面调阈值时拍脑袋。我们在实际项目里常用 1-59/7 这种节奏(每 7 分钟一次)放在工作时段,夜里再降频。

第二阶段,收敛期(增量起点)。观察一周后,把 ids 收敛到核心方案,通常只保留那几个跑批失败代价最大的。同时把 recentSeconds 调成调度周期的 2 倍左右,避免窗口重叠漏报。

第三阶段,稳态期(调度频率定型)。最终的调度配置可以是工作日高频、夜里低频,例如 1-59/7 7-22 * * *。轻易云这边是调度和执行分离的,调度只决定什么时候触发拉取,真正决定告警密度的,是源端那条 recentSeconds。

踩坑复盘

• 凭据硬编码:典型错误是把企微机器人的 access_token 直接写在 request 字段里,换一个机器人就要全量改。稳妥的做法是走轻易云的连接器鉴权,token 失效后平台自动刷新。
• recentSeconds 太小:常见翻车点是这里设成 60,结果同一条报错在一分钟内被拉了 8 次,群消息刷屏。稳妥做法是让它略大于调度周期。
• ids 留空:如果忘了填方案 ID,接口会把租户下所有策略的报错都拉回来,轻则刷屏,重则触发企微机器人的频率限制。一定要白名单式收敛监控范围。
• 租户上下文缺失:lessee_name 这个字段很多客户会忘,结果群里只看到策略名,看不出是哪家公司、哪个环境出的问题。运维现场定位时少这一列非常难受。
• 告警与处置脱节:只推报错到群,没人认领,等于没推。建议在轻易云这条策略之后再接一条人工 ack 机制,或者和值班表打通,这是组织流程的事,但平台侧的字段要预留好。

适用场景与不适用场景

适合:有 7×24 跑批任务、对停机敏感、希望问题不过夜就能推到责任人手上的团队,尤其是零售、制造等业务连续性要求高的行业。 不适合:低频手工触发的方案、没有企微协作习惯的团队,以及报错量大但绝大多数是已知噪音的场景——这种情况下应该先在前置策略里收敛噪音,而不是靠企微机器人兜底。