控制台里的任务心跳：自动化任务卡住、失败或漏跑，首页亮灯，一键重新执行
自动化最怕的不是报错，而是悄悄停了：出价计算卡在半路，报告同步没跑，你却以为系统一直在工作。琼仁智度给每个自动化任务装上心跳，出了问题就在运营控制台顶部亮灯，原因写清楚，点一下就能重新执行。
自动化悄悄停了，是最贵的故障
以为在跑，其实停了
出价任务卡在半路，没有报错，也没有结果；你照常下班，第二天才发现一整晚什么都没做。
告警太多等于没有
每一次小失败都发一条通知，真正需要处理的那一条淹没在几十条里。
知道失败却不知道怎么办
看到“任务失败”四个字，不知道是哪一步、为什么、要不要重跑、重跑会不会重复执行。
为什么广告自动化系统必须能“自己报平安”？
一个指示器、一块面板、一个按钮
指示器
位于运营控制台时间范围选择器旁边，一切正常时显示“正常”；有异常任务时亮灯并显示数量。
面板：每个异常任务一张卡片
- 状态
- 未执行（到点没跑）、中断未完成、运行中但心跳停滞、超时、失败。
- 时间信息
- 预期执行时间、开始时间、已运行时长；心跳正常或停滞。
- 处理记录
- 已自动重试的次数、已补跑的次数。
- 错误原因
- 失败时的错误信息原文，方便判断是网络、凭证还是数据问题。
- 操作
- 未执行的任务显示“立即执行”，其余显示“重新执行”。
克制的告警
- 同一任务只显示一张卡片，不重复刷屏。
- 失败之后，同一任务已经成功（补跑、恢复或下一周期成功）的，不再显示。
- 已下线的任务不显示，也不能被重新触发。
- 手动重新执行会被记录为一次新的执行，结果同样进入任务记录。
脚本 + 手工检查、通用工具、琼仁智度：任务停了怎么知道
| 能力 | 手工运营（脚本 + 人工检查） | 通用工具 | PPCWISER 琼仁智度 |
|---|---|---|---|
| 发现卡住的任务 | ✕要等结果没出来才发现 | –视工具而定 | ✓心跳停滞即亮灯 |
| 发现漏跑 | ✕ | –视工具而定 | ✓到点未执行单独标出 |
| 错误原因 | –翻日志 | –通常只有“失败” | ✓面板直接显示原文 |
| 告警去重 | – | –视工具而定 | ✓同一任务一张卡片，已恢复的不再打扰 |
| 一键重跑 | –登录服务器手动执行 | –视工具而定 | ✓面板上点一下，并记录执行 |
对比基于功能机制描述，不代表具体效果承诺。
自动化是否在工作，一眼就知道
停了会被看见
卡住、漏跑、失败、中断，都会在首页亮灯。
只看该看的
去重与已恢复过滤，面板里留下的都是需要你处理的。
原因写在卡片上
不用翻日志，就能判断是网络、凭证还是数据问题。
处理一步到位
一键重新执行，执行本身也有记录。
与数据新鲜度互补
心跳看任务在不在跑，状态条看数据新不新鲜。
晚上睡得着
第二天打开控制台，先看指示器是不是“正常”。
出价、同步、下发，都在同一套任务体系里
出价计算、报告同步、否词与下发都是按时运行的自动化任务，它们的调度、补跑与中断恢复见 任务监控、漏跑补执行 与 定时任务不漏跑、不重跑。这些任务按系统的标准广告结构读取和写回数据——算法按结构设计，接入时可选择重构现有系列，或保留原系列另建一套标准结构，详见 广告结构说明。
关于任务心跳的常见问题
什么情况下指示器会亮灯？
重新执行会不会让同一个任务跑两次？
任务失败了，系统会自动重试吗？
电脑关机后，任务会怎样？
我需要每天盯着这个指示器吗？
相关功能
任务心跳监控
心跳停滞、失败、超时、没执行，首页亮灯并写明原因，一键重新执行。
查看 →任务可靠任务不漏跑不重跑
只认“做成了”：漏跑补做、中断接续、卡住收尾、不重复启动。
查看 →数据新鲜度数据新鲜度与同步
订单、退款、产品主数据的同步时间与健康状态一条看清；一键同步、一键回补，缺数不冒充 0。
查看 →漏跑补执行漏跑补执行与续跑
按执行窗口判断有没有做成：窗口内补做有上限，中断按原范围续跑，离线回线补一次。
查看 →离线保护关机断网不失控
离线推迟、回线补做一次、超 2 小时双向提醒，亚马逊上的设置照常生效。
查看 →运营控制台运营控制台
PPCWISER 的旗舰界面：同步状态、12 张 KPI、利润瀑布、排行、广告位、趋势、预警、ASIN 全景表，一屏看清全店真实经营。
查看 →参考资料与权威来源
本页所有涉及亚马逊规则、行业数据与方法论的表述均标注来源。链接指向官方文档、同行评审论文、专利或法律法规原文；访问日期 2026-09。
- [1]论文Distributed Periodic Scheduling with Cron（Site Reliability Engineering 第 24 章） — Google SRE Book · 2016定时任务有“漏跑”和“重复执行”两类失败；许多任务不是幂等的，重复执行可能无法撤销，因此需要可靠记录任务“即将启动”和“已经完成”两个时点，才能在故障后正确恢复。
- [2]论文Monitoring Distributed Systems (Site Reliability Engineering, Chapter 6) — Google SRE Book · 2016监控系统要回答两个问题：什么坏了、为什么坏了；每一条告警都应当可以采取行动，只为需要人判断的新问题打扰人。
- [3]官方REL05-BP01 Implement graceful degradation to transform applicable hard dependencies into soft dependencies — AWS Well-Architected Framework · Reliability Pillar · 2026依赖不可用时，组件应以降级方式继续履行核心功能，把失效视为正常运行状态；反模式包括部分失败留下不一致状态、刷新失败时清空本地状态，下游持续失败时继续重试只会加重负载。