二十多个自动化任务怎么管：脚本台账加心跳哨兵的治理实践

摘要
自托管玩久了，自动化任务会像滚雪球一样多起来：几个服务各一份每日备份、一个签到、两个盯梢、一个健康看护、一个镜像周检……我数了一下，光调度系统里就有二十多个任务，再加上散落在各台服务器本地的脚本和应用自带的监控，早就超过了人脑能记清的范围。任务多了之后最先出问题的不是机器，是我自己：不知道谁在跑、谁悄悄停了、谁失败了没人知道。这篇文章记录我给这堆自动化做的治理：先建一本全量台账，再把散装脚本收编进统一调度，最后加一个每半小时巡查关键任务的心跳哨兵。
第一步：一本台账，看清自己到底在跑什么
治理的第一步是盘点。我把所有在跑的东西拉成一张表，来源有三处：一是统一调度系统里的二十多个任务，二是每台服务器本地的定时任务，三是监控类应用里自带的几条盯梢规则。
台账里每一行记五件事：名称、运行频率、干什么、出了问题会影响什么、怎么停。最后一项听起来多余，实际上最重要——真出事的时候，人是慌的，与其现找停法，不如盘点时就写好。台账建成之后我给自己立了条规矩：以后新增或停用任何脚本，顺手更新这张表，不攒着。台账的价值不在建成那一刻，在它一直是新的。
第二步：收编散装脚本
盘点总能盘出意外。我在一台服务器的本地定时任务里翻出一条存在感很低的镜像更新检查脚本：每周跑一次，兢兢业业，但它不在统一调度里，也不在台账上，属于典型的影子任务——跑挂了没人知道，想停的时候想不起来它在哪。
处理方式不是删掉，而是收编：脚本本体不动，把它的触发迁进统一调度，本地只留一份原配置备份；另外两台服务器盘下来是干净的，本地只有云厂商自带的条目。这件事给我的教训是：散装脚本本身没有错，错的是它脱离了统一的记录和巡查。任何新脚本想上岗，先问一句：它进台账吗？它的心跳谁管？
第三步：心跳哨兵，专盯「该跑没跑」
台账解决「有什么」，但解决不了「还在不在跑」。定时任务最阴险的失败不是报错，而是静默消失：调度丢了、机器重启没恢复、配置被覆盖——任务没了，但没有任何东西会报错，因为压根没有「它应该出现」这个预期。
所以我加了一个心跳哨兵：每三十分钟巡查一遍十个关键任务，名单是五类服务的每日备份、一个每日签到、一个云资源抢占重试、一个用量盯梢、一个节点健康看护和一个镜像周检。巡查的判断标准有两条：到点该跑的有没有跑，跑了的最后一次是不是成功。发现漏跑或失败，立刻告警；同一次异常只报一次，不搞重复轰炸；任务恢复正常了，再补发一条恢复通知，让我知道这事翻篇了。
告警纪律：没消息就是全绿
这套东西能长期用下去，靠的是告警纪律，而不是功能多。我的原则从一开始就没变过：所有任务成功时一律静默，只有失败和异常才出声，告警同时走聊天和自建推送两个通道，任何一条挂了还有另一条。
哨兵也遵守同一套纪律。它一天巡查四十八次，如果每次都汇报「一切正常」，不到一周我就会把它的消息全屏蔽掉，那它就白建了。所以它平时是隐形的：我什么都没收到，就等于十个关键任务全部在岗。这种「沉默即健康」的设计，本质上是在保护告警通道的信誉——每一次它出声，我都愿意立刻点开看。
还没解决的问题：谁来盯哨兵
说一个诚实的短板：哨兵自己也在同一套调度系统里运行，如果调度系统整体出问题，哨兵不会自报，因为它根本没机会运行。这一层我目前没有完美的自动解法，靠的是两个笨办法：一是台账在手，我随口一问就能拉出所有任务的真实运行记录核对；二是关键服务本身还有各自的监控面板兜底，多层之间互为补充。
我把这个短板写出来，是因为自动化治理里最容易自欺的就是「已经全自动了」。承认哪一层还靠人，反而让人知道精力该往哪放。
总结
二十多个任务的治理，拆开看只有三件事：台账回答「有什么、在哪、怎么停」，收编解决「影子任务」，心跳哨兵盯住「该跑没跑」。都不复杂，但缺了任何一环，自动化规模一大就会失控。我的体会是：自动化不是把脚本写完就结束了，任务本身也是需要被运维的对象；当你开始给脚本建台账、给失败设预期，你的自托管才算从「能跑」走到了「可控」。