自动化没人盯，出错了谁发现
定时任务半夜自己跑，成功了没人夸，失败了没人知道——这才是最危险的。自动化的前提是「可观察」：能留下记录、能监控状态、出问题能主动告警。这一节讲日志、监控与告警。
一句话：无人值守的前提，是「出问题能知道、能定位」。
日志：让每一步都有据可查
脚本/任务要记日志，否则出问题无从查起。
日志至少记录：
- 时间：什么时候执行的
- 做了什么：每步的结果
- 成功/失败：状态标记
[2026-08-12 09:00:01] 开始报表任务
[2026-08-12 09:00:02] 步骤1/3 拉取数据 ✓
[2026-08-12 09:00:05] 步骤2/3 生成报表 ✓
[2026-08-12 09:00:06] 步骤3/3 发送邮件 ✓
[2026-08-12 09:00:06] 任务完成
日志 = 出问题时，你能倒推出发生了什么。
deploy-bot 的部署日志更要有「审计味」，因为要回答「谁在何时把什么部署到了哪」：
[2026-08-12 09:00:01] deploy-bot 开始部署 v2.3.1 → staging
[2026-08-12 09:00:02] 拉取代码 ✓
[2026-08-12 09:00:05] 测试通过（42/42）✓
[2026-08-12 09:00:08] 构建 ✓
[2026-08-12 09:00:12] 部署 staging ✓
[2026-08-12 09:00:13] 部署成功，状态已上报
出了问题，顺着这份日志就能定位是哪一步、什么版本、哪个环境。
监控：让状态「看得见」
光有日志不够，要主动监控：
- 任务是否执行了（有没有漏跑）
- 成功率（最近失败的次数）
- 关键指标（数据量、耗时、错误数）
监控的意义：在用户发现之前，你先发现。
对 deploy-bot，值得盯的指标：
| 监控项 | 看什么 |
|---|---|
| 部署是否触发 | 有没有漏掉该部署的提交 |
| 部署成功率 | 最近 N 次部署的成功/失败比 |
| 耗时 | 部署是否变慢、卡在哪一步 |
| 回滚次数 | 是否频繁回滚（说明流程不稳） |
告警：别等出大事才反应
监控发现问题，要主动通知你——告警：
- 任务失败 → 告警
- 连续失败 → 告警
- 关键指标异常 → 告警
告警方式：邮件、IM、或集中告警系统。核心是「问题一出现，你就知道」。
对 deploy-bot，哪些该告警很明确：
- 部署 staging 失败 → 告警（可自动重试）
- 部署 production 失败 → 告警（需人工介入，可能已影响线上）
- 连续 3 次失败 → 升级告警（别被一条失败淹没）
- 回滚发生 → 告警（高关注事件）
一个可落地的「可观察」设计
给每个自动化任务配上：
1. 日志：任务把每步记到日志文件
2. 状态：任务结束写一个「成功/失败」标记
3. 告警：失败时主动通知（脚本里加一行通知）
if ./report.sh; then
echo "报表成功"
else
echo "报表失败" >> /var/log/report.err
# 发告警：curl 通知接口
fi
三件套齐了，自动化才「敢无人值守」。
deploy-bot 的部署脚本结尾，也应该有这段「成败标记 + 告警」逻辑：
if ./deploy.sh --env staging; then
echo "[$(date)] staging 部署成功" >> /var/log/deploy-bot/deploy.log
else
echo "[$(date)] staging 部署失败" >> /var/log/deploy-bot/deploy.err
# 上报告警：通知负责人
curl -s -X POST "$ALERT_WEBHOOK" -d "deploy-bot staging 部署失败"
exit 1
fi
失败即告警，deploy-bot 才靠谱。
常见误区
- 没日志：出问题无从查起
- 没监控：失败没人知道
- 没告警：知道了也晚了
- 告警轰炸：一有风吹草动就告，久了没人看——告警要分级、要准确
对 deploy-bot 最要防的是告警轰炸：如果每次 staging 部署失败都狂响，负责人很快就不看了。真正的核心告警（production 失败、回滚、连续失败）要保证触达，非关键的就降级或合并。
常见坑：告警没分级，小事刷屏，大事被忽略
「可观察」做得最糟的状态：告警一条不漏全发，结果真正的大事反而被人忽略。
真实场景：deploy-bot 的 staging 部署因为网络抖动失败了一次，告警响个不停；同时 production 的回滚事件也混在里面。负责人被刷了一屏 staging 噪音，等看到 production 那条时，已经耽误了。
为什么：告警没分级 = 所有事件一个权重，重要和不重要在信噪比上一样。噪音一多，重要告警就「被淹没」。
怎么破：给告警分级——staging 失败可降级/合并，production 失败、回滚、连续失败走最高优先级（IM/电话那种「必须看到」的通道）。先保证核心告警触达，再谈覆盖。
小结
- 自动化前提 = 可观察：能知道、能定位
- 日志：让每步有据可查
- 监控：让状态看得见
- 告警：问题一出现就主动通知；要分级、要准确
下一模块进入「CI/CD 流水线」。