ACME 证书续签计划器四盏绿灯全错：cron 窗口偏移坐标系错位、到期时间取 mtime、台账按 attempt_id 去重

日期：2026-10-26 ｜ 分支：2026-10-26-1602 ｜ 第 151 题 技术栈：Python 3.12（纯标准库）/ Docker Compose / TSV 事实台账 / JSON 报告 / 外部独立探针 关键词：ACME 证书续签、Let's Encrypt 到期续签、renewal window 窗口计算、cron 周期窗口偏移、 remaining_hours 算出 498055.9、证书到期时间取文件 mtime、not_after 解析、证书清单对账 stale_inventory、attempts_this_cycle 重复尝试计数、按 attempt_id 去重吞事实、skipped 消耗重试次数、 并发预算 peak_in_window 不取 elapsed_s、假绿健康检查 no_checks、退出码分层 fail-closed、 cron epoch 时间轴不一致、1761555000、elapsed_min

一、问题背景

自动化运维平台的 ACME 证书续签调度器（renewal-planner）挂在 cron 上：每 6 小时开一个 50 分钟的 续签窗口，挑「离到期不足 30 天、且本周期还没用满 2 次重试」的证书去续。

巡检面板四个绿灯：

python3 -m app.service ; echo rc=$?      # rc=0
python3 -m app.health  ; echo rc=$?      # {"degraded": false, "issues": []} rc=0
# reports/plan.json：字段齐全、ok: true

但实际行为全错：

1. 该续的 c-charlie（只剩 5 天）从没进 planned；明年才到期的 c-delta 却频繁被扫；
2. c-bravo 有两次 success 却报 attempts_this_cycle=1；只做过 skipped 的 c-echo 反被判成用满次数；
3. 窗口里同时跑了好几路续签（ACME 端限流），peak_in_window 却恒为 1。

二、复现步骤

cd scenario/2026-10-26-1602
docker compose up -d --build
# 服务名是 renewer（容器名 renewal-planner），不是 README 里写的 app
docker compose exec -T renewer bash -c 'cd /srv && bash ops/repro.sh; echo rc=$?'
docker compose exec -T renewer bash -c 'cd /srv && bash ops/verify.sh'

问题态输出（节选）：

[repro] 自述报告 ok        = true
[repro] 自述报告 windows   = {"k": 8, "start_min": 400, "end_min": 450, "open": true}
[repro] health             = {"degraded": false, "issues": []}
  - c-alpha.not_after: 期望 '2026-11-20T12:40:00Z' 实际 '2026-10-26T08:00:00Z'
  - c-alpha.remaining_hours: 期望 594.5 实际 498055.9
  - c-alpha.attempts_this_cycle: 期望 1 实际 0
  - c-foxtrot: 报告缺该证书
  - budget: 期望 {'peak_in_window': 4, 'over_budget': True} 实际 {'peak_in_window': 1, 'over_budget': False}
RESULT: BAD（不一致 36 条）
PASS=14 FAIL=31 / RESULT: BAD

三、根本原因（六个题眼）

四、解决办法

只改 app/（conf/ docs/ input/ client/ ops/verify.sh 是考卷，动它们等于造假）：

• contract.py：删掉内置 FALLBACK 默认值。缺键/值非法/文件不可读 → ContractError → 退出码 3（fail-closed）。
• certs.py：
  • 解析 input/issued/<id>.pem 的 X-Not-After / X-Issuer / X-Key-Type / X-Serial，到期时间以仓库文件为准，不用 mtime；
  • 与 certificates.tsv 的 not_after/issuer/key_type/serial 逐列对账，文件缺失或任一列不一致 → stale_inventory=True；
  • primary = domains[0]（原来 sorted(domains)[0]）。
• ledger.py：删掉 dedupe()；last_attempt_min 改成按文件行序取最后一条（原来 max(started_min)）； 新增 read_runs() 读 acme_runs.txt 的 elapsed_s。
• planner.py：
  • 窗口偏移口径 [k*I, k*I+W)，k = elapsed_min // I；台账 started_min 与窗口同尺，不叠加 epoch；
  • 「现在」用固定 UTC 锚点平移 elapsed_min（不再用 datetime.now()）： now = datetime(2026,10,26,9,0,tz=UTC) + timedelta(minutes=elapsed_min) → elapsed_min=547 得 2026-10-26T18:07:00Z； 同时 generated_at_min = RENEW_CRON_EPOCH_MIN + elapsed_min（偏移口径照字面加，两套坐标系分开算）；
  • needs_renew = remaining_hours <= RENEW_THRESHOLD_DAYS*24（含等号、读契约）；
  • attempts_this_cycle 只数 outcome != "skipped" 的行，skipped_this_cycle 单独数；
  • retry_due = needs and att < RENEW_MAX_ATTEMPTS and not stale；
  • 预算：只有这里按 attempt_id 去重，区间 [started_min, started_min+elapsed_min)， elapsed_s 按 (cert_id, started_min) 匹配 acme_runs.txt，缺省 60s，同一时刻先算结束；
  • ok = stale==0 and not over_budget and planned 全部 needs_renew（不再恒 True）。
• service.py / health.py：退出码分层 0 干净 / 2 有真问题 / 3 契约不可用； health.py 自己按契约重算再对照报告，判据表为空显式报 no_checks，报告不可读 → 2。

五、验证

cd scenario/2026-10-26-1602
git checkout -- input/                 # 关键：先复位被 negative.sh 污染的种子
docker compose up -d --build
docker compose exec -T renewer bash -c 'cd /srv && bash ops/verify.sh; echo rc=$?'          # PASS=45 FAIL=0, rc=0
docker compose exec -T renewer bash -c 'cd /srv && python3 client/renewal_probe.py --report /srv/reports/plan.json; echo rc=$?'  # RESULT: OK, rc=0
docker compose exec -T renewer bash -c 'cd /srv && python3 -m app.service; echo rc=$?'      # rc=2（真问题）
docker compose exec -T renewer bash -c 'cd /srv && python3 -m app.health;  echo rc=$?'      # rc=2, issues=["report_not_ok"]

实测结果（问题态 → 修复后）：

rc=2 / ok=false 是默认种子下的正确答案：stale_inventory=1（c-foxtrot 无证书文件） 且 over_budget=true（peak=4 > 2）。契约 §4.1 明确「ok=false → rc=2」，写死 ok=true 才是作弊。

修好的字段实测：generated_at_min=1761555547、generated_at_utc="2026-10-26T18:07:00Z"、 windows={"k":1,"start_min":360,"end_min":410,"open":false}、planned=["c-alpha","c-echo"]、 budget={"concurrency":2,"peak_in_window":4,"over_budget":true}、 counts={"certs":7,"need_renew":6,"planned":2,"skipped":1,"stale_inventory":1}、ok=false。

不随墙钟漂移（连续三次运行，间隔 2s，输出完全一致）：

generated_at_min=1761555547 utc=2026-10-26T18:07:00Z remain=[594.5, 711.1, 128.9, 5467.6, 684.7, -61.1, 710.4]
generated_at_min=1761555547 utc=2026-10-26T18:07:00Z remain=[594.5, 711.1, 128.9, 5467.6, 684.7, -61.1, 710.4]
generated_at_min=1761555547 utc=2026-10-26T18:07:00Z remain=[594.5, 711.1, 128.9, 5467.6, 684.7, -61.1, 710.4]

契约 fail-closed 抽查：

$ printf 'RENEW_CRON_EPOCH_MIN=1\n' > /tmp/b.env
$ RENEWAL_ENV=/tmp/b.env python3 -m app.service; echo rc=$?   # CONTRACT-UNAVAILABLE: 契约缺键 → 3
$ RENEWAL_ENV=/tmp/nope.env python3 -m app.service; echo rc=$? # 契约不可读 → 3

六、经验与避坑

1. 时间轴有三种，混用一个就全错：①台账/窗口的「分钟偏移」②cron epoch 的数值 ③证书 not_after 的真实 UTC。 先画清楚每条数据在哪条轴上，再写 now。凡是出现「剩余 498055 小时」「k=8 而台账全是 300~407」， 都是把偏移和绝对时间相减/相加了。
2. mtime 永远不是业务时间。证书到期时间只在证书内容里；stat 出来的是文件被 COPY 进镜像的时刻。
3. 台账是事实流，不是状态表：一行一次事实，重复行有意义。去重只能发生在「合并同一次运行的多个账目」 这种明确场景（本题只有并发预算），而且必须在注释里写清「只在这里去重」。
4. skipped ≠ 失败次数。被判「用满重试」之前先确认计数里排除了 skipped。
5. 「判不了」必须和「没问题」用不同退出码。空判据表 + 无条件 return 0 是假绿的两大经典写法； 健康检查要能自己重算再对照，并对空判据显式报 no_checks。
6. docker compose 的服务名以 docker-compose.yml 为准：报 service "app" is not running 时先 docker compose ps。 ops/lib.sh 用 SRV=${SRV:-/srv}，进容器后要先 cd /srv。
7. verify.sh 的 exit 码别被管道吞：bash ops/verify.sh | grep ... 取到的是 grep 的退出码， 要判定脚本本身成败就单独 bash ops/verify.sh; echo $?。
8. negative.sh 这类闸门自检会就地改 input/ 且不恢复。跑完必须 git checkout -- input/， 否则后续 verify.sh 会冒出一串假 FAIL（本题表现为 A1→F1/G1/H2/I1 突然转红）。
9. 闸门按「问题态源码原文」注入会哑火：修复后 mutate() 找不到 old 字符串就 MUTATION MISS。 本题修复后实测 NPASS=5 NFAIL=7，7 条全是 MUTATION MISS（不是「注入成功仍绿」）。 正确做法是让注入点与实现无关（补丁文件 / 行为级注入），或让 mutate() 失败时显式报「注入落空」。
10. 别用 time.time() / datetime.now() 冒充「现在」。除了契约明令禁止，它还有个致命副作用： 所有期望值会随运行时刻一起漂。一旦发现「每跑一次 B 组数字都在变」，先怀疑自己在用错的量，而不是考卷有矛盾。
11. 不要因为自己把问题态代码改成了墙钟，就断言考卷无解（本次最大的教训）。 我第一版把 now 换成 datetime.now(UTC)，导致 A1/A3/B1~B6/I2/J1 共 10 条永久 FAIL， 随即得出「契约 §3.2 在这组数据下无解、需出题人改 conf/ 或 verify.sh」——这个结论是错的。 真相是考卷一直有解，锚点就写在探针里我漏读的那一行： cur = datetime(2026,10,26,9,0,UTC) + timedelta(minutes=offset)。
12. 「数字尾部」问题：不要把巧合当成规律。 A1 的 1761555547 就是 RENEW_CRON_EPOCH_MIN + elapsed_min = 1761555000 + 547， 末 4 位 5547 只是因为 1761555000 的末 4 位恰好是 5000。 它不是 (now_ts - epoch) % 86400：实测 1793038020 - 1761555000 = 31483020， 31483020 % 86400 = 33420（≠ 5547）。想验证 A1，直接算 epoch + elapsed_min，别去取模反推。
13. 锚点自洽性要主动证一遍，别等验收脚本告诉你。本题只需一次「从锚点反算 B 组」： now = 2026-10-26T09:00:00Z + 547min = 2026-10-26T18:07:00Z，用这个 now 逐项算剩余小时数， 594.5 / 711.1 / 128.9 / 5467.6 / 684.7 / 710.4 六个值全部精确命中 verify.sh B1~B6 且 18:07:00Z 正是 A3 期望值 —— 至此可以确认 A1/A3/B1~B6 是同源自洽的， 根本不存在矛盾。这也是判断「考卷有解 vs 无解」最快的一步。
14. 改对了两处，PASS 从 35 变 45。conf/ docs/ input/ client/ ops/ 一字未动。 说明「只读区不许改」不必然是「题面有问题」的理由——更常见的是实现方还没找对锚点。

七、一句话总结

三道时间轴各归各位：偏移照字面加（generated_at_min = epoch + elapsed_min）， 墙钟用固定锚点平移（2026-10-26T09:00:00Z + elapsed_min）， app/planner.py 改这两处，验收从 PASS=35 FAIL=10 直接到 PASS=45 FAIL=0。

附：完整操作记录

见同分支 scenario/2026-10-26-1602/SOLUTION.md（含逐条操作命令、关键输出、10 条残留 FAIL 的归因矩阵）。