08｜定时任务和触发机制怎么设计？

开场先讲触发的三种来源：定时触发（cron 表达式的周期任务，夜间回归是主场景）、手动触发（用户即时执行，调试和补跑）、事件触发（CI 流水线的 webhook、代码合并事件）——三源统一进任务队列，一套执行体系服务三种来源。统一抽象是设计能力。

回答思路

第一步：讲定时调度的实现

• celery beat 或 APScheduler 做调度器（平台自管）
• cron 表达式的用户友好化（界面上下拉选择，而不是让用户写表达式）
• 时区和节假日的处理（凌晨任务避开发布高峰、大促封网期自动暂停）

调度细节的考虑深度就是运维经验。

第二步：讲 CI 集成的设计（能不能嵌进研发流程的关键）

• 平台提供 webhook 接口（CI 流水线一个 HTTP 调用触发任务）
• 执行结果回传 CI（门禁卡点——测试不过流水线不往下走，回调状态或 CI 轮询）
• 触发的上下文传递（带分支名和环境参数——测的是这个分支）

第三步：讲任务编排的进阶

• 任务依赖（A 任务成功才触发 B——冒烟过了跑全量的串行逻辑）
• 失败重试策略分级（环境类失败自动重试、断言失败不重试）
• 并发互斥（同一环境的任务排队，防互相干扰）

收尾：讲可观测

定时任务的执行历史和成功率看板——调度本身也要监控，任务没触发要有告警。调度静默失败是平台最阴险的故障（用户以为每晚在跑，实际停了半个月）。

考察重点

维度	说明
企业动机	定时和触发是平台从「工具」变「流程设施」的关键（夜间回归、CI 门禁全靠它）——调度静默失败这种坑只有真运营过平台的人才提防
过线标准	三源统一 + CI 集成设计 + 调度自身的监控
区分度	讲任务依赖、重试分级、调度静默失败告警的是平台老手
加分项	cron 用户友好化和节假日暂停这类贴心的细节
减分项	只有用户手动点执行，平台没有自动触发能力，等于没进入流程

来源

整理自知识星球帖《面试情报 08｜测试工具平台开发 20 题》，返回题库。