把重复运维做成流水线：青龙面板的定时任务实践

前言：手上有几台服务器，运维脚本散落在各自的 crontab 里——备份在一台、证书续期在另一台、日志清理在第三台，改一个通知地址要登三台机器。后来把定时任务集中迁到青龙面板（qinglong），集中管理、统一通知、失败可查。本文记录部署和三个实战细节。

一、为什么是青龙而不是裸 crontab

crontab 的问题不是不能用，而是"散"：

1. 脚本与机器绑定，迁移要重新配一遍 cron 表达式和路径；

1. 失败没有统一出口——任务挂了不会主动告诉你；

1. 依赖混乱：每台机器的 Python/Node 版本不可控。

青龙面板把这三件事集中化：Web 界面管理所有定时任务、内置依赖管理（npm/pip 一键装）、统一通知渠道（任务失败自动推送）。部署本身是一条 Docker 命令的事。

二、部署与基础配置

起来之后按顺序做四件事：改默认密码 → 配置通知渠道（邮件/企业微信机器人二选一）→ 建环境变量（token、密码类全部走环境变量，不写死在脚本里）→ 拉取/新建脚本。

任务以"订阅 + 脚本 + cron 表达式"三元组存在，Web 界面里改表达式、看日志、手动触发，都不用再登机器。

三、一个实战脚本：数据库备份 + 失败通知

定时任务里最常见也最不能失败的就是备份。写备份脚本的两个要点：可校验和失败必通知：

青龙里设 0 3 * * * 每日 3 点执行。空文件校验和 MD5 是给"备份命令成功返回但产出空文件"这种静默失败准备的——这种情况不校验，三个月后需要恢复时才发现全是空包。

四、三个细节坑

1. 时区：容器默认 UTC，cron 表达式"每天 3 点"会跑在北京时间 11 点。compose 里加 TZ=Asia/Shanghai 环境变量，或镜像内 ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime；

1. 任务并发锁：两个任务同时写同一个 SQLite 文件会锁冲突。青龙支持任务分组与串行，把写同一资源的任务放进同一分组错峰执行；

1. 日志膨胀：每个任务每次执行的日志都落盘，高频任务（每分钟）一个月能积累上万条。定期清理或把高频任务的 stdout 精简到一行结论。

五、总结

运维自动化的收益公式很简单：单次人工操作时长 × 频率 × 遗漏风险。备份、证书续期、日志清理这类"低频但高风险"的任务，值得花一次部署成本迁进统一的定时任务面板——从此它们从"记在脑子里"变成"失败会主动喊你"。

（完）环境：Ubuntu 22.04 / Docker / qinglong 2.x / Python 3.11 / 2026-10 实测