土拨鼠日志：自动化脚本的三个坑，今天一次踩全

今天大部分时间花在一件很朴素的事上：让一台机器的自动恢复真正靠得住。结果一天里踩了三个坑，都是「看起来已经修好了」的那种。写下来给同样在写守护脚本的人。

一、坑一：「已经启动了」不等于「正在工作」

现象是间歇性的：服务一会好一会坏，但每次登上去看，进程都在。

真凶是自动恢复只做了半件事——它把其中一个组件拉起来了，另一个组件没跟上。于是在「进程列表里能看到名字」，但链路是断的。

更值得记的是第二个错误：我们一开始用的验收标准是「应该有两个进程」，而实际上这套配置正常工作时本来就只有一个。标准写错，结果就是把三台明明正常的机器全判成故障，还顺手把它们「回退」到了真正有问题的机器上。

• 验收要按「功能」写，不要按「你印象里的数字」写：能通就是能通，别拿一个记忆中的进程数当真理。
• 改之前先采一次基线：正常状态下到底是什么样，先量出来，再拿它当尺子。
• 连续采样，别信单次：这次是连续 3 分钟、12 次采样全绿才敢说「稳定」，单次通过只能说明「这一秒没坏」。

二、坑二：脚本收尾「回写」会把中途的改动抹掉

这个坑很隐蔽。脚本的设计是：开工前先把配置读一份存着，干完活再写回去，保证「不动别人东西」。

听起来很稳妥，实际是经典的读-改-写竞态：如果脚本运行期间有人（或另一个程序）改了配置，收尾这一写，就把那些改动全部覆盖回开工前的样子。你以为自己改成功了，下一次看又变回去了，于是「修一天修不好」。

两条经验：

• 收尾回写要只写自己负责的那部分，或者写之前先比对一遍，发现被别人动过就放弃这次回写并告警；
• 看到「改了没生效」，先怀疑有另一个写入者，别一头钻进缓存和模型里找原因。

三、坑三：两个自动化同时操作一台机器

日志里能看到痕迹：同一个配置项，20 分钟前是一个值，10 分钟后变成另一个值，来回切。原因是这台机器上不止一个自动化在管同一件事。

两个「都很负责」的自动化互相覆盖，效果比谁都不管还差——因为每一方都能拿出「我刚修好了」的证据，但现场永远在坏。

对策不复杂，但要下决心：同一件事只留一个写入者。其他的要么只读观察，要么通过那个唯一的入口去排队。这条不只适用于机器，也适用于多人协作的配置管理。

四、这三条怎么变成日常习惯

今天之后，我们把它们落成了几条固定动作：

• 任何「自动恢复」上线前，先问一句：它怎么判断自己成功了？这个判断必须是功能级的，且经过一次真实故障验证；
• 任何会写回配置的脚本，都要有「别人动过就别写」的检查；
• 排查「改了不生效」时，第一步查有几个写入者，而不是查缓存；
• 稳定性结论必须带采样口径：跑了多久、几次、全绿还是偶发。

这几条在土拨鼠里是内建习惯：长任务会在进度卡上留痕，改完的东西要求「刷新之后读回来还是新值」才算数，而不是弹一个「保存成功」就完事。想了解这类工作方式，可以看 功能页 里关于长任务与工作区的部分；算成本去 定价页；想直接上手，下载 装一个，拿你自己那台最不听话的机器试一遍最快。

五、留给你的三个自查问题

• 你的守护脚本，判断「好了」的标准是功能，还是某个你记得的数字？
• 你有没有一个脚本，会在收尾时把整份配置写回去？
• 同一台机器上，有几只手在改同一个文件？

这三个问题里任意一个答不上来，那台机器迟早会给你一次「明明修好了又坏」的惊喜。