流水线静默死亡20天：Clarity流量掩盖与git log真相

那天晚上11点我照常打开 Clarity 后台，看到32个会话、27个独立用户，心想"流量又涨了"。然后顺手跑了 git log --since="2026-08-10" --oneline --grep="auto: publish"，返回空。我揉了揉眼睛，以为 git log 参数写错了，换了个姿势再跑一遍，还是空。

这就是我的博客发布流水线"静默死亡"20天的发现现场——8月10日之后，没有一篇新文章被发布，但 Clarity 后台每天都在报漂亮的数字，4AM 健康检查每天都在报"一切正常"，整个监控体系集体瞎了。

事故现场：8月10日之后发生了什么

8月10日是最后一次正常发布日。那天发了3篇文章：USB-C全球旅行适配器横评、WordPress ActivityPub集成、以及一篇 git pull rebase 导致177篇404的事故复盘。之后，流水线彻底停了。

但停摆这件事没有任何人——包括我自己写的自动化监控脚本——发现它。原因是：

Clarity 每天还在报流量数据。 8月28日甚至报了32个会话（近期最高），Top页面全是旧文：Claude Code API Key 配置那篇（5月31日发的）连续3天每天7个会话，GLM-5本地部署实测（4月27日发的）每天2个会话，Paperless-ngx自托管文档管理（4月29日发的）每天2个会话。

旧文的长尾SEO效应正在累积，即使停更20天流量仍在增长。这让所有人都以为"一切正常"。

4AM健康检查每天在跑，但只检查了两件事： 第一，pushed_manifest.json 是否同步（是的，它一直在同步）；第二，远端main和本地文件数是否差异>10篇（没有，因为两边都没变）。它完全没有检查"最近24小时有没有新文章被发布"这个最基础的指标。

错误的信号：三个"正常"的假象

假象一：Clarity 流量 = 博客健康

这是最致命的认知错误。Clarity 报告的是"有多少人访问了网站"，而不是"网站有没有在更新内容"。一个已经积累了600+篇文章的博客，即使完全停更，靠旧文的长尾搜索流量也能维持每天20-30个会话——至少能撑3-6个月。

我把 Clarity 会话数当成了博客健康度的代理指标，这就像用"公司银行账户还有余额"来判断"公司业务是否正常"——余额可以来自上个月的营收，不代表这个月没有停产。

假象二：pushed_manifest.json 同步 = 发布正常

4AM健康检查的逻辑是：如果 pushed_manifest.json 里记录的文件在远端main都能找到，就认为"推送正常"。但 pushed_manifest.json 的最后一次更新是8月10日——它本身就没有新记录需要同步。检查"已推送列表中的文件是否在远端"和检查"是否有新文件被推送"是两个完全不同的问题。

假象三：git commit 存在 = 内容在更新

4AM健康检查确实跑了 git commit——但那只是 chore: sync pushed manifest [4am-health-check]，是健康检查自己生成的提交，不是文章发布。git log 里每天都有commit，但没有任何一个是 auto: publish。

根因剖析：为什么监控体系集体失效

问题的根因不是某个脚本有bug，而是整个监控体系只检查了"管道是否通畅"，没有检查"管道里有没有水流"。

我画了一张图来说明这个问题：

监控层              检查项                    8/10-8/30 状态
─────────────────────────────────────────────────────────
Clarity            网站访问量                 ✅ 20-32会话/天（旧文长尾）
4AM health-check   pushed_manifest同步       ✅ 无新文件需同步
4AM health-check   远端vs本地文件数差异       ✅ 差异<10（两边都没变）
4AM health-check   git commit 存在           ✅ 每天有 chore commit
─────────────────────────────────────────────────────────
缺失的检查         最近24h auto:publish数     ❌ 从未被检查
缺失的检查         drafts/ 队列堆积           ❌ 从未被检查
缺失的检查         cron任务最后执行时间       ❌ 从未被检查

三层"正常"的假象完美覆盖了一个"完全停止"的事实。

黑客解法：3行shell脚本堵住漏洞

修复方案不需要重构整个监控体系，只需要在4AM健康检查的最前面加一个Step 0：

# Step 0: 检查最近24小时是否有 auto: publish commit
AUTO_PUBLISH_COUNT=$(git log --since="24 hours ago" --oneline --grep="auto: publish" | wc -l)
if [ "$AUTO_PUBLISH_COUNT" -eq 0 ]; then
  echo "⚠️ 警告：最近24小时无新文章发布！流水线可能停摆。"
  # 这里可以接入告警（邮件/Telegram/Slack）
  ALERT_SENT=true
fi

这三行代码的核心逻辑是：**用 git log 作为唯一的真相来源**。不看Clarity（会被旧文长尾流量骗），不看pushed_manifest（只检查已有记录不检查新增），只看一件事——最近24小时有没有 auto: publish 这个关键词出现在git commit里。

如果你的流水线用的是不同的commit消息格式，把 --grep="auto: publish" 换成你自己的关键词就行。

进阶版：连续N天告警升级

三行脚本只解决了"能发现问题"，还需要解决"问题被忽略"：

# 连续3天0发布 → 升级告警
CONSECUTIVE_ZERO_DAYS=$(cat /tmp/pipeline-zero-publish-streak 2>/dev/null || echo 0)
if [ "$AUTO_PUBLISH_COUNT" -eq 0 ]; then
  CONSECUTIVE_ZERO_DAYS=$((CONSECUTIVE_ZERO_DAYS + 1))
  echo "$CONSECUTIVE_ZERO_DAYS" > /tmp/pipeline-zero-publish-streak
  if [ "$CONSECUTIVE_ZERO_DAYS" -ge 3 ]; then
    echo "🚨 严重：流水线连续 ${CONSECUTIVE_ZERO_DAYS} 天0发布！需要人工介入。"
    # 升级告警：发邮件 + Telegram + 停止12PM/18PM/22PM cron
  fi
else
  echo "0" > /tmp/pipeline-zero-publish-streak
fi

肌肉记忆防复发：我的监控清单

这次事故之后，我在4AM健康检查脚本里加了以下检查项，按优先级排序：

P0就是前面那3行shell脚本。P1是升级版。P2检查草稿队列是否堆积（如果有20+个draft文件说明pipeline消费能力出了问题）。P3是最底层的检查——如果cron任务本身就没在跑，前面的检查全白搭。

我从这次事故里学到的3件事

第一，旧文长尾流量是蜜糖也是毒药。 它能让你的博客在完全停更的情况下仍然看起来"健康"，这既是SEO资产的价值，也是监控盲区的来源。你需要把"内容更新频率"和"流量指标"分开监控，不能用一个代替另一个。

第二，"管道通畅"不等于"有水在流"。 pushed_manifest同步、远端文件数一致、git commit存在——这些都是"管道通畅"的检查。但你需要额外检查"最近24小时有多少新内容被推送"这个"水流"指标。

**第三，git log是自动化流水线最好的审计日志。** 它不会被Clarity的长尾流量干扰，不会被pushed_manifest的同步状态迷惑，不会被chore commit的假象欺骗。只要你的流水线在commit消息里打了标签（比如 auto: publish），git log就是判断"有没有新内容被发布"的唯一可信来源。

---

👉 Join MiniMax Token Plan: AI coding acceleration for businesses

👉 Join Zhipu Coding Plan: GLM-4.6/GLM-5 coding packages, China-stable, pay-per-token unlimited

👉 Join Aliyun AI: Top AI products with exclusive coupons for business innovation

📌 This article was AI-assisted generated and human-reviewed | TechPassive — An AI-driven content testing site focused on real tool reviews