我批准部署的那一刻，抓「部署没发生」的门禁变绿了

10-05 16:39:37Z，我点了批准。30 小时 42 分之后，一个卡在 release 环境审批队列里的部署终于落地了。

3 秒后，一个专门用来抓「部署没发生」的工作流变绿了。

它叫 Deploy Freshness。它存在的原因写在文件第 3 行：Is production running the commit that main says it should? Once a day, without a deploy.

这个 run 变绿的方式是：跳过唯一一次真正的测量。

那一步的 step 状态是 skipped，不是 success。它不是"测了发现没问题"，它是"没测"。 而在它变绿的那一刻，生产跑在 82cee67f，main 在它前面 2 个提交。

这篇文章写四层：同一个冻结，四层全绿，最外那一层是我自己按出来的 —— 而且按了两次。

  10-04 09:57:31   部署 run 226（sha 82cee67f）创建，status=waiting，卡在 release 环境审批队列  

  10-04 10:07:23   code scanning 开出告警 #325 / #326，规则 GITHUB_ACTIONS_UNTRUSTED_CHECKOUT  

  10-04 10:46:37   哨兵 run #2（event=schedule）→ failure  

  10-04 10:46:46   探针第 1 次失败  

  10-04 10:46:56   探针第 2 次失败  

  10-04 10:47:06   探针第 3 次失败，run 判红  

  10-05 11:52:34   哨兵 run #3（event=schedule）→ failure  

  10-05 16:39:37   run 226 被批准并完成，success（等了 30h42m）  

  10-05 16:39:40   哨兵 run #4（event=workflow_run）→ success，第 5 步 skipped  

  10-05 16:49:49   部署 run 227（sha babb2a9e）创建，status=waiting，又卡回审批队列  

  10-05 17:00:36   cf1a8563 chore: update leaderboard snapshot（#2878）进 main  

  10-05 17:04:00   run 227 被批准并完成，success  

  10-05 17:04:02   哨兵 run #5（event=workflow_run）→ success，第 5 步又是 skipped  

探针三次失败说的都是同一句，逐字：

❌ production runs 7897946bc034, but this checkout is 4a8e5749a452

   — 6 commit(s) behind. The worker is stale; the deploy did not land. (#2779)

第 9 行：那个抓「部署没发生」的门禁，在 3 秒后报绿。

第 12、13 行：同样的事又发生了一遍。 10 分钟后又一个部署卡回队列，17:04:00 我再点一次批准，2 秒后门禁又变绿了。我把 run #5 的 step 也拉下来了，和 run #4 一模一样：

[4] success  A deploy succeeded, so there is nothing to re-measure

[5] skipped  Is production running main's commit?

同一个洞，踩了两次。 我没有做任何修复 —— 我只是又点了一次批准。这不是我为了文章效果补的转折，是我在写这篇查数据的时候它自己发生的。

run #4 的 run_id=37342530363。它一共有 5 个 step：

[2] success  Run actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1

这个工作流的名字叫「生产跑的是 main 的 commit 吗」。第 5 步的 skipped 就是它的答案。

第 4 步 success 了，但它的内容只是 echo。三行 echo，没有一次 curl，没有一次 python3 scripts/doctor.py，没有一次读 /api/health。

走绿的分支条件写在 deploy-freshness.yml:89：

if: github.event_name == 'workflow_run' && github.event.workflow_run.conclusion == 'success'

也就是说：只要"有人刚部署成功"，这个门禁就自动放弃测量。

而"部署成功"这个信息，是从 github.event.workflow_run.conclusion 读来的 —— 一个关于另一个工作流的结论，不是一次对生产的观测。

这就是整件事的形状：一个门禁把自己要回答的问题，外包给了另一个门禁的退出码。

那一刻生产在 main 后面几个提交

在 run #4 变绿的那个时刻（main 当时停在 4a8e5749），gh api compare/82cee67f...4a8e5749：

  e84b24ba  ci(registry): pin the advertised tool surface ... (#2823)

  4a8e5749  fix(ci): the freshness probe depends on a cron that has never fired (#2827)

我把这两个 commit 的文件清单拉下来数了一遍，没有一个文件在 workers/ 下：

· e84b24ba 改了 3 个文件：.github/workflows/registry-drift-watch.yml、docs/CI.md、tests/test_mcp_tool_surface_matches_docs.py

· 4a8e5749 改了 5 个文件：两个 workflow、三个 test

所以那一刻的真相是：worker 产物其实是最新的，只有 commit SHA 落后 2 个。

方法上补一句。main 是个移动靶子 —— 我写完这段再查，它已经又往前走了几个提交，82cee67f 落后 5 个而不是 2 个。所以这个数必须钉在时刻上："run #4 变绿的那一刻，落后 2 个"。一个会随时间自己变号的证据，读者没法复核。

这句必须写清楚，因为它决定了后面 critique 的落点 —— 如果生产真的少了东西，那这就是一次货真价实的漏报。它不是。 绿色的那一刻，生产跑的就是 main 上最新的 worker 代码。

但门禁报的是 success，判据写的是「production runs main's commit」。

而 production 并不跑 main 的 commit。它跑的是 main 的 worker 产物，那两个提交没碰过 worker。

一个事实为真的状态，被一个为假的断言盖住了。这比真的漏报更难查 —— 真的漏报你能查出来，你只是没查；断言为假，你查出来之后也不知道该信哪个。

三、这个 skip 是我自己写的，理由当时是对的

我不打算把这个 skip 写成"我犯了个蠢"。因为它不是。deploy-freshness.yml:101-109 是我自己写的注释，理由完整、具体、而且在那条分支的局部范围内是正确的：

Re-measuring here would compare production against whatever main has become by now, and a push landing in the seconds between "deploy succeeded" and "this job checks out" would report production behind by a commit it is not behind by in any meaningful sense — a red for a reason that is not a defect, which is the fastest way to teach people to ignore this workflow.

它防的是一个真实存在的假红：部署在 T 时刻成功，这个 job 在 T+5 秒 checkout，有人在 T+2 秒 push 了一个跟 worker 无关的 commit —— 探针于是报「生产落后 1 个 commit」，而那 1 个 commit 根本没碰 worker。

这个红是假的，而且它会教人忽略这个工作流。 我怕的正是这个。

一个正确的局部权衡，产生了一个错误的全局绿灯。

错在哪：我在那条分支上论证的是「不要因为无关的 commit 报红」，然后把它实现成了「不测」。

正确的做法是让判据对那类假红免疫 —— 比如只统计碰了 workers/ 的提交数。那样 T+2 秒那个 push 报 0，"红是假的"这个结论仍然对，但红本身不会出现。

我实现的是「把这次测量取消掉」。在一条防假红的注释下面，我写了一个产生假绿的分支。

四、四层：同一个冻结，四层全绿

这才是我事后最在意的部分。同一个冻结（线上 3 天、5 个已合并 PR 没上线），有四层本该拦住它的地方，四层全绿，而且最外那一层是我自己按出来的。

L0：症状是「版本号两边一样」

issue #2779 记的是原始现场。线上 3 天没更新，最先暴露它的是首页 7 天活动图不更新 —— 但那只是症状。真正的证据：

GET https://misakanet.org/api/activity/history?days=7   → HTTP 404

handler 本身在 88b360004（#2692）里已经进 main，完整、无条件，缺 store 返 503、内部异常返 502 —— 它不可能返 404。所以 404 只能由"线上 bundle 里没有这段代码"解释。

而当时 post-deploy 的版本校验是通过的：

两边版本号一模一样，校验通过，而线上其实少了 5 个提交。

deploy-freshness.yml:13-16 记着原因：release-please 只在 release 时 bump 版本，所以 fix: / feat: 提交会让生产和 main 长期报同一个版本号。版本号这个判据对"版本变了的陈旧部署"有效，对"版本没变的陈旧部署"完全失明 —— 而后者是日常的大多数。

L1：修它的哨兵自己，几乎没跑过

这是我今天最想写的一层。deploy-freshness.yml:22-27 是我自己写下的复盘：

as of 2026-10-04T06:00Z it had produced exactly one run ever — a manual workflow_dispatch from a PR branch — and its first daily slot (04:53Z) had passed with nothing. So the safety net for the very freeze it was written for had never once run on its own, and the guard below could not see that, because asserting a cron *string* is not asserting a cron *firing*.

我服务端复核了一遍，五个 run 全在这儿（截至 10-05 17:04:02Z）：

  run   时刻 (UTC)   event   第 5 步   run 结论  

  #1   10-03 18:08:11   workflow_dispatch   failure（真测了）   failure  

  #2   10-04 10:46:37   schedule   failure（真测了）   failure  

  #3   10-05 11:52:34   schedule   failure（真测了）   failure  

  #4   10-05 16:39:40   workflow_run   skipped   success  

  #5   10-05 17:04:02   workflow_run   skipped   success  

· 它跑过 5 次，一次都没自己触发过。 10-03 18:08 到 10-04 18:08 整整 24 小时里它一次都没动，10-04 那个 04:53Z 的日槽是空的 —— 那是它被创建后的第一个日槽。5 次的触发源是 1 次手动派发 + 2 次 cron 槽 + 2 次"别人部署成功了"。

· 它测过的 3 次，全红；它绿着的 2 次，一次都没测。

而那个本该守住它的测试，我打开看了正文（tests/test_deploy_freshness.py:118）：

def test_the_freshness_probe_is_scheduled_not_only_post_deploy():

    """The whole point: post-deploy verification cannot catch a deploy that never ran."""

    assert "schedule:" in text, "a workflow_dispatch-only probe is a probe somebody must remember"

三个 assert 全是对文件文本的字符串匹配。 它断言的是"yaml 里有 schedule: 这个字符串"。

GitHub 那天负载高，会丢 scheduled 事件 —— 这个仓库自己在 approval-watch.yml 的头注释里记着 2026-09-29 的实测：9 小时里只跑了 1 次，连续 5 个槽位连 run 都没创建。

一个字符串断言，测不出一个被平台丢掉的调度。 这个测试全绿，而被它守护的东西从来没响过。

顺带一个我今天才发现的小事：deploy-freshness.yml:26 引用的那个测试名 test_the_freshness_probe_does_not_depend_on_the_scheduler_alone，在仓库里根本不存在。我全仓 grep 过，只有注释里这一处提到它。

一条注释在给一个不存在的测试挡枪。 而这个注释恰恰是在解释"为什么测试测不出来"——它自己就是那个现象的样本。

L2：30 小时 42 分，红了 2 次，没有一次被消费

run 226 创建于 10-04 09:57:31Z，status=waiting。我 10-05 16:39:37Z 批准。中间 30 小时 42 分。

这 30 小时 42 分里，哨兵红了两次（#2、#3），每次都把同一句话打进日志三次，每一句都精确到 commit SHA 和落后提交数，末尾还附了 issue 链接。

这些红没有产生任何后续动作。 不是"我看到了但决定不处理"，是它们在 GitHub 上以 failure 状态静静躺着，等一个不会来的通知。

GitHub Actions 不会因为一个 scheduled workflow 变红就叫人。它需要一个 required check 的上下文、一个通知的订阅、或者一个人恰好在看。而这个工作流三条触发器全都不是 required check —— 它是旁路的。

一个旁路探针红了，等于没红。

L3：红消失的方式，是我按了一下；绿的方式，是跳过测量

10-05 16:39:37Z，run 226 变成 success。3 秒后（16:39:40Z），哨兵 run #4 被这个 success 触发，然后它读到这个 success，判定"部署已经成功了，不用再测"，跳过第 5 步，报 success。

我消除一个告警的方式，是制造一个事件；而这个门禁把那个事件当成了证据。

红 2 次没人看，1 次人工点击就全绿。这个门禁的输入是 github.event.workflow_run.conclusion —— 一个人工动作的副产品。它不是自己发现的。

10 分钟后的 16:49:49Z，一个新的部署 run 227 又卡进了同一个队列。17:04:00Z 我再点一次批准。2 秒后（17:04:02Z），哨兵 run #5 变绿，第 5 步 skipped，和 run #4 一字不差。

两次人工点击，两个绿灯，零次测量。中间隔了 24 分钟，仓库里没有一行代码被改过。

这个洞不会因为我注意到它就自动补上。它只会在下一次有人点批准的时候，再绿一次。

五、不变式选错了：该断言产物，不是 commit

现在回到最要紧的地方。这个门禁的判据是：

production 的 /api/health 报的 commit_sha == 这个 checkout 的 HEAD

SHA 相等是一个既过严、又过松的条件。

过松，是刚刚发生的这件事：跳过测量就等于放行。判据在"部署事件"这条分支上完全不生效，但它报的是 success。

过严，是 L0 那一层：那两个提交（e84b24ba、4a8e5749）一个字节都没碰 workers/，但 SHA 不相等。判据分不出来"落后"里哪些碰了 worker、哪些没碰。

真正该断言的是「生产跑的是 main 的 worker 产物」，不是「生产跑的是 main 的 commit」。

部署的是 bundle，main 上是源码，SHA 层面没法直接比。但有一个可以落地的近似判据：

1. 比产物指纹，不比 commit。 部署时把 workers/ 的内容哈希写进 /api/health，探针拿它对 main 上 workers/ 的哈希。无关 commit 不再影响判据，碰了 worker 的提交一定影响判据。 假红从定义上消失，那条 skip 分支也就没有存在必要了。

2. 退一步：比"碰过 workers/ 的提交数"。 纯 git 层就能做：git log --oneline <deployed_sha>..<head> -- workers/ 数一下。10-05 那一刻这个数是 0，探针就该报绿 —— 它本来就不会假红，那条 skip 分支是在解决一个自己造出来的问题。

3. 版本号不能当判据（L0 已经证过），但可以当辅助信号：版本号不变且 SHA 不变，恰好是"该红没红"的形状。

还有一个更便宜的止损：让 skipped 不等于 success。

第 5 步 skipped 时整个 run 报 success，在 GitHub 的语义里是"通过了"，但实际含义是"没测"。这两件事在 CI 的颜色上无法区分。 任何把 CI 颜色当结论的流程（合并规则、通知、看板），都会把"没测"读成"过了"。

我改不动 GitHub 的颜色语义，但我可以给这个工作流一个 required check 的位置，让 skipped 至少出现在必须有人看的那个面板上。

六、顺带：那天同一天的两条 error 级告警，是误报

10-04 10:07:23Z，code scanning 开了 #325 / #326，规则 GITHUB_ACTIONS_UNTRUSTED_CHECKOUT，说的是"特权工作流检出了不受信任的代码（workflow-run head ref）"。

run #4 恰好是它们的反证：run #4 的 head_sha 是 4a8e5749（main），而触发它的部署 run 226 的 head_sha 是 82cee67f（非 main）。

workflow_run 触发下，checkout 取到的是默认分支，不是触发方的 head。 告警假设"特权工作流会检出触发方的代码"，而这里它检出的是 main —— 一份我完全控制的代码。

10-05 16:39:37Z 我点了批准，3 秒后一个抓「部署没发生」的工作流变绿了。它叫 Deploy Freshness，变绿方式是跳过唯一一次真正的测量：第 5 步状态是 skipped，不是 success。那是冻结 30h42m、红两次无人消费之后，红消失的方式。

运维

架构设计

测试

生产部署门禁DeployFreshness存在致命缺陷：在部署成功事件触发时跳过核心测量步骤，将"未测试"标记为绿色。两次人工批准部署后，门禁均在3秒内报绿，而实际生产环境落后main分支2个提交。该工作流5次运行中，3次真测全红，2次跳过全绿，从未独立发现过部署冻结问题。

GitHub

2026上云采购 | AI焕新·智启新局

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

我批准部署的那一刻，抓「部署没发生」的门禁变绿了

我批准部署的那一刻，抓「部署没发生」的门禁变绿了

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐