把scriptautorun这名字拆开看其实就是 Script Auto Run——脚本自动运行。我去年在一个长期跑批的环境里折腾了大半个月最终自己写了一个叫这个名字的小工具专门负责一件事让脚本在正确的时间、正确的条件下自动、稳定地跑起来。这篇文章既是对scriptautorun完整设计过程的复盘也把我在真实环境里踩过的坑、摸索出的经验一并记下来。如果你们手头也有一堆脚本要定时执行、按文件变化触发、或者跟着某个进程状态走这篇文章应该能帮你省掉不少弯路。先说明一下适用范围。我说的不是那种双击就运行的简单 autorun而是面向开发、运维场景的自动调度今天有数据要同步、日志要归档、健康检查要跑、还有几个临时脚本要在别人退出后接着跑。这些任务有的按时间有的要等文件出现有的要看另一个进程的存活状态。需求一复杂cron 和任务计划程序就显得不够灵活这时候就需要一个能统一收口所有触发条件的工具。1. 为什么不直接用现成的定时任务方案非要自己写一个1.1 先说清楚脚本自动运行到底在解决什么问题很多人一听脚本自动运行第一反应就是 Linux 的 cron 或者 Windows 的任务计划程序。确实大部分场景下这些现成工具够用。但问题在于它们的触发模型太单一cron 只认时间任务计划程序虽然在图形界面里做得挺友好可一旦要跨机器同步配置、要按文件变化触发、要串起A 脚本结束后 B 脚本才开始这样的依赖关系就得写一堆胶水代码。我用scriptautorun的真实场景是这样的某环境里同时跑着几个数据同步脚本、一个日志归档脚本、若干临时分析任务。同步脚本每天凌晨跑但数据源文件如果当天没有更新跑也是白跑日志归档要等同步进程结束之后再执行还有一个健康检查脚本需要每 5 分钟探测一次端口挂了马上告警。用 cron 最别扭的地方就是等文件更新和等另一个进程结束这两件事它不是不能做而是要绕很远文件更新可以用 shell 脚本里反复 stat 来判断进程结束则要写 while 轮询加 sleep。次数一多每个任务都带一套自己的等待逻辑时间长了根本没法维护。所以我把scriptautorun定位成一个胶水层它本身不替代 cron也不替代 systemd timer而是把各种触发源统一收敛到一个工具里。定时触发、文件变化触发、进程退出触发、手动触发全部都通过同一套配置描述由同一个进程负责任务拉起、日志收集、超时控制和重试。这样一来业务脚本只需要关心做什么至于什么时候做、为什么做完全交给上层调度器。1.2 现成方案看着够用实际用起来总差一口气我不是第一天用 cron也不是没用过任务计划程序。这些工具单拿出来都有各自的优势但放到脚本自动运行这个整体需求里每样都差了那么一口气。cron 的局限粒度最小到分钟秒级任务得另想办法没有内建的任务依赖脚本本身的退出码、输出、超时都靠外部包装日志散落。systemd timer 的局限配置偏重适合系统服务不适合临时性的分析脚本调试起来要 reload、enable、start 一套组合拳临时加一个任务不够轻量。任务计划程序的局限图形界面操作在服务器上不直观触发器类型虽然比 cron 多但进程退出文件变化这类还是要借助额外动作。我承认这些东西都能实现最终效果但它们把复杂度堆在了业务脚本这一侧。我想要的是一个统一的调度入口无论触发原因为何任务执行路径都一样——加载配置、匹配触发条件、拉起脚本、记录结果。这种触发源和运行器解耦的思路就是scriptautorun的核心价值。2. scriptautorun 的核心设计思路把什么时候运行变成可配置的东西2.1 触发源做成分离的插件式模块设计这个工具时我定了两条原则。第一业务脚本不知道触发源的存在第二触发源模块之间不互相依赖。scriptautorun里有三种基础触发源时间触发、文件触发、进程触发。时间触发支持 cron 表达式也支持每隔 N 秒/分钟这种简单的间隔写法。文件触发监控指定目录或文件出现、变更、消失都可以作为触发条件。进程触发监控某个外部进程的退出状态退出码为 0 或者非 0 都可以分别挂到不同的任务上。为什么这么设计因为触发源本质上就是一个等待事件的组件。把事件类型抽象出来之后新增一种触发源只需要实现一个检查条件并返回任务ID的接口完全不需要改动任务执行器。举个例子后来我加了一个Webhook 触发的模块允许外部系统通过 HTTP 请求直接唤醒某个任务加的代码量很小这都得益于一开始就按插件式结构搭好了框架。2.2 一个配置文件说清楚什么时候该跑什么整个scriptautorun的入口是一个 YAML 配置文件。我选 YAML 而不是 JSON是因为它更接近自然语言长任务列表里不容易写错括号。下面是一个精简版的配置示例tasks: - name: nightly_sync trigger: type: cron expr: 0 2 * * * command: /opt/scripts/sync_data.sh timeout: 3600 retry: 3 - name: archive_after_sync trigger: type: process_exit wait_for: nightly_sync expected_exit_code: 0 command: /opt/scripts/archive_logs.sh timeout: 1800 - name: watch_upload_dir trigger: type: file path: /data/upload event: created command: /opt/scripts/process_upload.py timeout: 600从这份配置能看到几个决策点。nightly_sync每天凌晨两点跑archive_after_sync绑定到nightly_sync进程只有同步脚本正常退出后才会触发watch_upload_dir则盯着上传目录一旦有新文件进来就跑处理脚本。整个配置读起来就像一份任务清单非技术人员也能看懂大概意思这个价值在后期维护时非常明显。2.3 触发源与执行器解耦为什么值得这么做很多人写自动化脚本习惯把判断时机和执行动作写在同一个脚本里比如 cron 调用一个 shellshell 里先检查文件是否存在再决定要不要执行下一步。这种写法在任务少的时候没问题但任务一旦到十几个就会变得很痛苦每个脚本里都有一份自己的判断逻辑时间判断、文件判断、进程状态判断混在一起改一处逻辑要翻好几个文件。把触发源和执行器解耦之后业务脚本的职责变得非常纯粹你给我参数我把活干完退出码告诉你成功还是失败。scriptautorun负责的则是什么时候调用、调用时把什么参数传进去、失败后怎么重试。这种边界让整个系统变得更容易测试因为触发源可以单独测执行器也可以单独测。我在实际使用中体会最深的是排查问题的时候这个任务为什么没跑和这个任务为什么跑挂了变成了两个独立的问题定位速度快得多。3. 动手实现一个能用的最小版 scriptautorun3.1 目录结构和主循环scriptautorun用 Python 3 实现没有用重型框架核心代码就几百行。目录结构是这样的scriptautorun/ scriptautorun.py # 主程序入口 config.yaml # 任务配置 triggers/ __init__.py # 触发源注册表 cron_trigger.py file_trigger.py process_trigger.py runner.py # 任务执行器拉进程、超时、重试 logger.py # 日志与状态记录主循环比很多同学想得简单本质就是一个遍历触发源 - 检查条件 - 投递到任务队列的轮询。之所以没有引入 Celery 或者 MQ是因为这个工具只跑在单台机器上任务数量级是几十个引入消息队列徒增运维成本。主循环的核心伪代码如下def run_once(): for trigger in active_triggers: ready_tasks trigger.check() for task in ready_tasks: dispatch(task) while True: run_once() time.sleep(poll_interval)check()方法会根据各自的触发逻辑返回一批 ready 的任务 ID。时间触发比较当前时间是否已到达计划时间点文件触发比较目录快照是否发生变化进程触发检查目标进程是否已经退出。这样一个统一循环配合不同的触发源实现就是整个scriptautorun最小的可运行版本。3.2 时间触发是最容易写错的部分时区、重复、错过窗口时间触发看起来简单实际写起来有不少细节。首先是下次运行时间的计算。如果用户给的配置是指定 cron 表达式最简单可靠的办法是直接用一个 croniter 库来解析不要自己写但如果是每隔 N 秒这种间隔触发自己算反而更可控。last_run task.last_run_at interval task.interval_seconds now time.time() if now - last_run interval: dispatch(task) task.last_run_at now这段逻辑有个潜在问题如果任务本来应该每隔 60 秒跑一次但系统因为休眠、负载或暂停错过了好几次间隔那它恢复后会立刻连续补多次吗为了安全我默认每个间隔最多只补一次跑完就更新last_run_at。这能避免一堆积压任务同时爆出来的情况。第二个容易踩的坑是时区。服务器时区可能和写配置的人不在同一个时区而 cron 表达式的语义依赖本地时间。我的约定是配置里统一使用服务器本地时间不搞时区转换但在任务心跳和日志里统一记录 UTC 时间戳。这样排查问题时看日志时间轴不会因为跨时区而混乱。第三个坑是错过窗口。比如某个任务计划凌晨三点跑但当时机器宕机了等机器恢复后已经早上八点。到底要不要补跑scriptautorun的默认策略是不补跑因为很多定时任务比如每天清理临时文件过了时间窗口就失去了意义。对于真正需要补跑的任务可以额外配置catch_up: true我宁可在配置里显式声明也不让所有任务默认具备这种行为。3.3 文件变化触发轮询和技术事件通知怎么选文件触发有两种实现路线一是轮询二是操作系统的事件通知。轮询就是定期扫描目录比对文件名和修改时间逻辑简单跨平台一致事件通知则依赖平台机制Linux 上可以用 inotifymacOS 上用 FSEventsWindows 上用 ReadDirectoryChangesW。Python 生态里 watchdog 库把这几套封装得不错。我在scriptautorun里默认用的是轮询原因很实在轮询的语义最可控代码出了任何问题都能靠过几秒再扫一次兜底而事件通知虽然实时性好但在某些网络存储挂载点、某些容器环境里压根不可用调试起来更费劲。轮询间隔我默认设为 2 秒足够应对绝大多数新文件出现后要立即处理的场景。要是对实时性要求到毫秒级那就不该用一个通用脚本工具来扛需要使用专门的流式处理系统。文件触发的一处关键细节是要记录目录快照而不是简单地看文件数量。我维护一个字典key 是文件路径value 是(mtime, size)。每次扫描时对比当前状态和上次状态差值就是新增、修改、删除三类事件。文件变化触发最大的收益在于它可以替代那些不管数据来没来都先跑一下的定时任务让不必要的空跑大幅减少。3.4 把子进程调度写好超时、输出、退出码触发源只是把任务从待命变成就绪真正干活的还是执行器。执行器模块我写得比较早但后来反复改因为它直接决定了脚本跑挂时系统怎么反馈。执行器用subprocess.Popen拉起业务脚本然后通过communicate(timeout...)等待结束。proc subprocess.Popen( cmd, shellTrue, cwdtask.workdir, stdoutsubprocess.PIPE, stderrsubprocess.STDOUT, envtask.env ) try: output, _ proc.communicate(timeouttask.timeout) except subprocess.TimeoutExpired: proc.kill() record_status(task, timeout, output)这段代码里有几个容易被忽略的点。stdout和stderr合并到同一个管道是为了简化日志记录env必须显式传入因为这个工具开启了一些系统服务上下文PATH 和普通登录用户不一定一样通信用communicate而不是proc.wait()是为了避免子进程输出量过大导致管道阻塞而死锁。这些都是实际环境里踩出来的经验不是一开始就设计好的。4. 把它放到真实环境里跑绕不开的五个坑4.1 工作目录不是你以为的那个目录第一个坑来自工作目录。scriptautorun自己可能跑在/opt/scriptautorun但如果业务脚本里使用了相对路径比如./data/input.csv那它依赖的是子进程的当前工作目录而不是脚本文件所在的目录。在 cron 环境里这类问题经常表现为手动执行好好的定时执行就报找不到文件。我的解决办法是在配置里给每个任务显式指定workdir。如果没指定执行器默认使用业务脚本文件所在目录而不是scriptautorun自己的目录。这个默认值选择是为了最大程度贴合脚本作者手动测试时的工作路径降低从手动执行到自动执行之间的环境差异。4.2 权限与用户上下文为什么有的任务必须换用户跑第二个坑是权限。有些任务需要读取密钥文件或者写入一个只有特定用户有权限的目录。scriptautorun默认以启动它的用户身份运行这看起来没问题但当它作为守护进程在开机时自动启动后用户上下文可能已经不是你的登录用户而是一个系统服务账号。我曾经遇到过一个任务手动执行成功、通过scriptautorun执行却报权限错误的案例排查半天发现是环境变量里缺少了一个私钥路径的配置项。这个问题的底层原因是脚本的自动运行环境和交互式登录环境两者的环境变量、用户凭据、甚至HOME都不一定相同。我后来在配置里增加了user字段对于确实需要降权或换用户执行的任务用setuid切换执行用户同时把所有业务脚本对外部的依赖尽量收敛到显式配置的env中而不是依赖系统环境。这样虽然一开始多写了几行配置但排错时能少掉很多不确定性。4.3 日志与状态进程退出了不代表一切正常第三个坑是日志管理。脚本自动运行最怕的就是任务跑了但不知道跑成什么样。scriptautorun里每个任务运行后都会把退出码、输出摘要、起止时间写入一个状态文件。状态文件按天切分配合 Python 的logging.handlers.RotatingFileHandler做大小轮转避免日志文件无限增长。在日志这块我更注重摘要优先。业务脚本可能输出几千行我默认只保存最后 200 行作为运行摘要完整输出则按任务归档到独立文件。这样做的原因是绝大多数排查场景里你只需要知道两个信息任务最终退出了吗它死在了哪一步。几千行日志全部堆在状态文件里反而会淹没关键线索。4.4 重试与退出码不要一失败就无限重试第四个坑是重试策略。没有重试任务可能因为一次网络抖动就失败重试策略写得差则可能让不可恢复的失败反复占用资源。我的做法是把重试次数和退避策略都放到配置中。retries 0 while retries task.retry: exit_code run_once(task) if exit_code 0: break retries 1 if retries task.retry: sleep(backoff_base ** retries)对于可重试的任务退出码为 0 是唯一判定成功的依据。非零退出码一律视为失败。要注意的是有些脚本习惯在失败时打印一段错误信息后仍返回 0这种假成功特别危险因为它会让重试机制形同虚设。我的建议是业务脚本里约定好只要发生未能处理的异常就必须以非零码退出这条约定要比任何调度器的重试逻辑都重要。4.5 守护与开机自启脚本自己怎么活下来第五个坑是守护。scriptautorun跑起来之后如果只是在前台跑终端一关就结束。后台化最简单的方式是用 systemd service而不是自己在 Python 里写 daemon 化逻辑。我自己写过一个 daemon 化模块后来觉得得不偿失double-fork、文件描述符关闭、umask 设置任何一步出了问题都很难调试而 systemd 已经把会话管理、日志收集、重启策略全都处理好。在 systemd 里配置一个服务单元核心就几行指定可执行文件路径、工作目录、用户和重启策略。我建议配Restarton-failure配合RestartSec5可以让脚本崩掉后自动复活。这里有一个经验之谈不要一上来就配置Restartalways因为always会把配置错误比如 YAML 解析失败导致的反复崩溃也伪装成服务一直在重启掩盖了真正的问题。5. 扩展成团队可用的配置化工具并发、幂等与状态回显5.1 多任务并发控制别让两个任务打架当任务数量超过十几个之后并发控制就会成为问题。两个任务如果操作同一个目录或者同一个数据库表同时运行很容易互相踩踏。scriptautorun的方案是给每个任务提供一个可选的互斥锁配置同一把锁同一时间只能由一个任务持有。实现上我用的是flock文件锁锁文件放在以任务名命名的.lock路径下。这样有个额外好处即使scriptautorun主进程重启锁不会因为进程消失而残留内核会自动释放而如果用普通文件写入加锁标记进程被强杀后锁文件还会留在原地导致后续任务永远等不到锁。文件锁和锁标记文件的区别建议大家都实测一下踩过一次就记住了。5.2 幂等性同一个脚本被触发两次会发生什么文件变化触发天然会带来一个隐患同一个文件可能因为网络同步或写入过程被扫描到两次导致处理脚本跑两遍。解决这个问题的核心思路是让业务脚本具备幂等性——同一份数据被处理多次结果不变。我在一个数据导入任务里吃过亏。上传目录里每进来一个 CSV 就触发一次导入但文件是被分批拷贝进来的轮询扫描时发现文件已存在但内容还没写完处理脚本读到半截文件直接报错。后来我在扫描逻辑里增加了一个文件稳定期判断只有文件的mtime连续两次扫描都保持不变且大小不为零才认为它已经写完。这在实现上很简单但价值很大。它反映了一个更通用的道理自动触发系统只能保证事件发生了会通知你但无法保证事件发生时数据是完整可用的。业务侧必须自己处理数据未就绪的情况要么重试要么跳过绝不能把收到触发等同于数据已具备。5.3 状态回显与通知怎样知道 scriptautorun 今天干了什么工具用了一段时间后最实用的功能不是某个任务的执行能力而是回顾能力。scriptautorun在每次任务结束后都会更新状态目录我可以随时看到每个任务的最近运行时间、最近退出码、最近一次输出摘要。用命令行查看状态的话大概是这种感觉scriptautorun status nightly_synctask: nightly_sync last_run: 2024-03-27 02:00:33 UTC exit_code: 0 duration: 12.4s状态回显这件事比很多人想象的重要。判断一个自动化系统是否成熟不是看它执行了多少任务而是看它是否能在任务失败时快速给出足够的信息。为了让告警不至于漏掉我在任务失败且重试完毕之后还会向内部的群机器人推送一条通知包含任务名、退出码和输出摘要前几行。这里有一个尺度要把握好通知只在重试结束仍然失败时发送不要每次失败都刷屏不然团队很快会对告警脱敏。5.4 手动触发是最后一道兜底即便有这么多自动触发机制手动触发仍然是任何自动化系统都该保留的接口。加了手动触发之后scriptautorun的命令行交互就稳定在这样几个动作查看任务状态、手动运行某个任务、暂停某个任务的自动触发、查看最近运行日志。这四大功能对应着四个子命令简单直接。我在设计手动触发时坚持一个原则手动运行和自动运行必须走同一条执行链路。也就是说手动触发只是把一个任务直接标记为就绪并投递到执行队列而不是另写一套手动执行逻辑。这样能保证手动跑出来的结果和自动跑出来的结果在环境、参数、行为上完全一致不会出现我手动执行成功了但自动执行还是失败的怪象。这个怪象在自动化系统里特别常见根子往往就是两条执行路径不一致。结尾的几句心里话回看整个scriptautorun的实践过程我最大的体会是这类脚本自动运行工具真正难的不是把脚本拉起来而是把什么时候跑、跑完怎么记录、失败怎么处理这些问题想清楚。工具能解决的是执行层的稳定性但每个任务本身的业务逻辑、幂等性、可信退出码依然要靠写脚本的人自己去保证。最后再分享一个调试小技巧。早期我在排查一个任务耗时过长的问题时半天看不出是调度器慢还是业务脚本慢。后来我在scriptautorun里为每次任务运行打了两类时间戳一类是触发源判定就绪的时间另一类是子进程真正退出的时间。一对比就发现时间几乎都耗在业务脚本处理数据上调度器本身的开销连千分之一都不到。这个认知帮我在后来优化性能时没有走错方向——先查业务再查工具。希望你们做自动化调度时也能先有这个判断。
