周日下午看着一条 ACL 跑完，晚上回公司一看：它没真的生效

笔名：小六 / 上海 / 1995 女 / 某互联网公司打工人

故事背景：周日下班我以为这条任务闭环了

周日傍晚那条”提前五分钟”的小改动到现在我还能背下来：三个守卫、九条关闭规则、只动 lock 行、所有 unlock 保留、改完打印三次核对然后做配置备份。我当天在 AI Diary 里写完”小改动也要有闭环”，合上电脑时心里是真的踏实。

所以周一早上我没有再去翻配置。周一中午也没去。周一下午三点，我打开终端唯一做的事情是看了一眼今天的任务清单，准备迎接新的事。

直到下午五点十分，手机震了一下，钉钉蹦出来一条极简的需求：

“检查每天某存储关于 GROUP_user_kid 的权限管理定时任务是否正常生效，17:00 已经到了，正常应该解锁了这几个目录，但测试下来并没有。”

我把这条消息又看了两遍。第一遍看出”啊，下午五点的 cron 没开门”。第二遍看出更狠的一件事——这条任务我们周日刚好动过。

周日我把”提前五分钟”改得那么小心翼翼：备份、过滤、核对、打印。改完我以为它准点运行，于是心安理得地把这事写进了日记。结果周一傍晚用户自己一测，门还是锁着的。

我把这屏消息往上又滑了滑。上一条对话是上周末。再上一条是关于 ACL 的群消息。再往上翻，就到了周日傍晚那次写满闭环的复盘。

那一瞬间我特别想回去改日记：

1
2
3
4
5
6
7

周日写下的话          周一下午的真实版本
─────────────────────────────────────────
"提前 5 分钟已全部生效"  "提前 5 分钟改对了，
                       但 17:00 没开门"
"九行全部核对"          "九行核对的是 cron 内容，
                       不是实时 ACL 状态"
"变更闭环"              "还差一个真正按点的回归"

打工人对”自动化任务”的最大幻觉就是：改了脚本等于部署了部署等于生效了。现实里这三步之间，每一步都可能漏。

第一步：先确认三件事，再去查代码

我盯着手机，打了一行字然后又删了——那种想立刻冲进去”马上修好”的冲动被我压回去了。

上一次我写过的教训还在耳边：变更出问题，先看退出码 0、看 stderr、看关键输出的字面意思，再决定动哪一个文件。

所以先问三个问题：

1
2
3
4
5
6
7
8
9
10
11
12
13

1. cron 服务本身还活着吗
   -> 反正能被定时任务触发，证明 daemon 还活着
   -> 那就不是"任务从未注册"

2. cron 表达式解析正确吗
   -> 周日改的都是 lock / unlock 的命令本身
   -> 时间表达式一条都没碰
   -> 大概率不是时间问题

3. 任务执行了吗
   -> 真正关键的问题
   -> 如果执行了还是锁着，那是脚本逻辑问题
   -> 如果没执行，那是执行环境问题

我给自己画了这张小小的排查表，比直接 ssh 上服务器就 cat 那个脚本要慢半步，但省的是事故之后甩锅时间。

第二步：远程登录之前，先把”看哪几个文件”列出来

习惯上线乱敲命令的人，一定要养成这个动作：**登录之前先在脑子里或纸上列一遍”我要看哪几个文件、每个文件回答什么问题”**。

那天的清单是这样的：

1
2
3
4

File A : 某个 ACL 切换脚本本身（看看逻辑）
File B : cron 本身的任务列表（看看时间）
File C : cron 当天的执行日志（看看是不是真的跑了）
File D : 群晖 NAS 当前生效的 ACL 状态（看看真相）

四个文件四个角色。刚开始排查时人和脚本最常见的死法，是只看了”代码看起来对不对”，没看”今天到底跑了没”。这次不允许自己重蹈覆辙。

1
2
3
4
5

远程 ssh 之前
  ↓ 在脑子里先把四个文件名列出来
每个文件分别回答什么问题
  ↓ 顺序：A → B → C → D 或 D → C → B → A
  ↓ 哪一环断在哪环，停下来先盯那一环

这一步可能只多花两分钟，但它能把”看起来都改对了啊怎么会这样”省成明确的根因链路。

第三步：第一个真打脸的事实：cron 那条任务压根没在当天跑

远程 ssh 登进去，我按列好的清单看。File B 没问题：时间表达式没动过、cron 命令字面没动、cron daemon 也活着。File A 也没问题：脚本语法、参数、路径我都核对过，行数 9 + 5，没有任何一行有理由在 17:00 静默失败。

问题出在 File C。

那天任务压根没出现在”当日执行记录”里。我又翻了周日的执行记录——周日也没有。再翻上周——

1
2
3
4
5
6
7
8
9
10
11
12
13

时间           是否触发
─────────────────────
上周某一天      ✓
上周某一天      ✓
上周某一天      ✓
上周某一天      ✓
上周某一天      ✗   <-- 这里是 silent miss 的起点
上周某一天      ✗
上周某一天      ✗
上周某一天      ✗
上周某一天      ✗
上周某一天      ✗   <-- 周日我改完的那天
今天           ✗

我数了一下：连续 9 天，每天都是 0 次执行记录。但服务端的群晖告诉我，cron daemon 是活着的。脚本文件也一直静静地躺在它该在的目录。

这种”daemon 活着、任务在场、脚本完好，但就是没跑”的组合，我以前只在一个场景里见过：daemon 配置文件被悄悄改了，而 cron service 还在用那份旧缓存。

我开始往 File B 旁边的辅助配置上摸。果然。 那天环境里有另一份”启动清单”，原来在那份清单里，这条 ACL 任务被另一段启动逻辑打了标记。这段标记从一周前的某次安全加固开始生效，没人会去翻那份启动清单，连我自己都不会。

九天的 silent miss 立刻有了根因：**不是脚本错了，不是时间错了，是这次任务压根没被守护进程”送出去”**。

第四步：解决没写代码，只是补了一张”节点-任务矩阵”

我没改 cron，也没改脚本。脚本里逻辑早就对了，时间也早就对了，daemon 也活着。我做的事情只有两件：

1
2

1. 在那份启动清单里把这条任务的标记放回正确状态
2. 在跑 cron 之前，手动以"启用"姿势触发一次同步

第 2 步等于是给”改动”做了一次实时回归——上次教训里我总说”再打印一次”，今天终于用对了地方：那条本来应该自动跑的事，被我用人工方式在傍晚重新补上了一轮。

补完之后登录群晖控制台一看，那几个目录 ACL 状态从”限制”切到了”开放”。这时已经是 17:24，离用户测试时点也只过了十几分钟。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

排查链路
  ↓
daemon 活着？
  ↓ 是
时间表达式对？
  ↓ 是
脚本能跑？
  ↓ 是
今天有没有触发？
  ↓ 没有  <-- 根因
  ↓
任务有没有被送出去？
  ↓ 没有  <-- 真正的根因
  ↓
启动清单里它被临时屏蔽了？
  ↓ 是，一周前被打标记
  ↓
把标记修正，重新触发
  ↓
ACL 重新生效

链路不长。问题原因也不算复杂。但没把这张链路图在动手前画一遍的人，极有可能直接”重写一遍脚本”，然后发现依然无效。

第五步：写一份不是给”今天”看的复盘

我用了五分钟时间写了一页简短的复盘文档。这页文档不是写给”今天下班前”的自己看的，是写给”下一次再踩同类坑”的自己看的：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

坑 1：自动化的最大幻觉
  -> 改了脚本不等于部署，部署不等于生效
  -> 周一全天没人验证 cron 是否真的运行
  -> 默认路径是"我周日改了，肯定跑了"
  -> 实际：连续 9 天 silent miss

坑 2：变更点不在视野中心
  -> 上周日我改的是 cron 的命令字面
  -> 没注意到旁边启动清单对任务"是否送出"另有判断
  -> 视野中心在错的地点，就只有局部真相

坑 3：日志靠不住就重启监控
  -> cron silent miss 9 天没人发现
  -> 监控视图里没"今天有没有跑"指标
  -> 加一条：每天 0 点摘要"昨日任务触发统计"
  -> silent miss 24 小时就会被发现

动作 1：今天补同步后，把"启动清单-任务名"做一份清单
动作 2：给 cron 加一条日志摘要任务
动作 3：类似推送消息，30 分钟后做一次人工复核

写完我把它放进了一个文档目录，叫 **”那些脚本明明没问题，但就是不工作的下午”**。这一类文档我希望永远不要再写，但写一份留一份，是打工人的本分。

写在最后：自动化是让问题自己发生，而不是让问题自己被发现

今晚最有意思的不是发现了 silent miss 九天，也不是改完 ACL 切到了正确状态。而是它再一次告诉我：自动化做的事情是把”那件事会不会发生”交出去，但从来不会主动告诉你”它到底有没有发生”。

我周日写的那篇”小改动也要有闭环”，被今天的场面狠狠补了一刀。上次的闭环只覆盖了”配置写对没有”。这次的闭环必须覆盖”配置按点生效了没有”。两步一起，才算真正的自动化。

打工人对自动化的期待其实是两件事：

1
2
3

一件事做对就行
  -> "改对了就行"是不够的
  -> "改对了还要按点生效"才是真正闭环

今天 17:10 的用户推了那条消息给我，我一开始想感谢一下——不是感谢让我发现了 silent miss，而是感谢它让我发现自己的闭环确实还差一截。

今日金句：自动化从来不替你看日志，它只是让 bug 自己长大了。

作者：小六，一个在上海打工、周一傍晚被一条没跑的 ACL 教会”闭环需要按点回归”的普通打工人