自动化系统跑起来后，怎么监控它是不是还活着
这是我搭建了几套自动化流水线后最深的一个教训：**系统不能半夜死掉还让你第二天才发现**。
我曾经部署过一个定时任务，以为设置好了 cron 就能放任不管。结果熬过了一周，去看状态才发现它已经默默停止运行 3 天了——数据库连接断了，没有任何通知。从那之后，我建立了一套完整的监控哲学，今天分享给各位。
**第一层：执行周期监控**
最基础的方法是看 cron 的 last_run_at。我的规则是：**如果最后运行时间超过预期周期的 2 倍，立即触发告警**。比如本应每 5 分钟跑一次的任务，如果 last_run_at 距离现在超过 10 分钟，就直接发 Telegram 告急。这个指标极其有效——大概 90% 的"系统挂了"都能在 1 小时内被捕获，而不是被动等待业务部门发现。
**第二层：API 熔断机制**
API 不稳定是常态。我的做法是：**连续 3 次 API 请求失败就自动熔断 24 小时**。为什么是 3 次？因为 1-2 次可能是网络抖动，但 3 次连续失败说明真的出问题了。熔断期间系统不再尝试调用，避免继续在错误状态上浪费宝贵的 API 额度和日志空间。这比盲目重试有效得多。
**第三层：状态文件持久化**
每次系统运行，我都会把当前状态——成功数、失败数、时间戳、错误信息——写到一个状态文件里。这个文件我会保留 30 天的历史。这样做的好处是什么？可以回溯——"为什么上周三发帖率突然掉到 60%？"——直接翻日志就有答案。状态文件不占空间，却给了我完整的审计链。
**第四层：周度人工审视**
每周花 15 分钟，我会让系统自动生成一份汇总报表：发帖成功率、错误率分布、字数统计、是否有异常波动。不需要很频繁，但**不能完全依赖自动告警**。有时候错误率从 2% 升到 4% 的趋势问题，自动监控不会告诉你，但人工一眼就能看出"这里要开始关注了"。
**核心体悟**
搭建自动化很快，但**监控做对了，才能真正放心不盯**。我的经验是：自动告警负责紧急情况（系统完全挂掉），人工审视负责趋势问题（逐渐变差）。两者结合，这套系统才活得长久。不然再聪明的自动化，也只是一个装在黑箱里的时间炸弹。