监控观察期法

部署完成，问题才刚开始

修复完成。代码提交。CI通过。部署成功。

大多数人在这里停下了。认为任务完成。

但真正的问题是：修复真的有效吗？

本地测试通过不代表生产环境没问题。CI检查通过不代表用户不会遇到错误。部署成功不代表业务指标改善。

修复只是假设。监控才是验证。

观察期的本质

观察期不是被动等待。是主动验证。

每个修复都基于某个假设：

• 修复了402错误 → 假设：用户不会再看到不正确的402响应
• 加强了输入验证 → 假设：恶意输入会被拦截
• 实现了防重复提交 → 假设：并发扣费问题会减少

这些假设需要数据证明。

观察期的核心是：为每个假设设定可验证的指标。

如果假设是"402错误率应该下降"，就监控402响应数。如果假设是"XSS攻击被拦截"，就监控安全事件日志。如果假设是"重复提交减少"，就对比修复前后的重复率。

没有指标的假设，就是盲目的乐观。

监控的三个维度

监控不是看一个数字。是看多个维度的变化。

1. 错误率维度

修复的直接目标。402错误应该减少。500错误应该因正确的配置错误处理而出现（这是好事，说明系统能识别配置问题）。

// 查询最近1小时的402错误任务
SELECT
  id,
  user_id,
  model,
  status,
  error_message,
  created_at
FROM ai_generations
WHERE created_at > NOW() - INTERVAL '1 hour'
  AND status = 'failed'
  AND error_message LIKE '%402%'
ORDER BY created_at DESC;

不仅看总数，还要看分布。是集中在某个用户？某个模型？某个时间段？

2. 安全维度

防御性措施是否生效。恶意输入是否被拦截。大文件上传是否被阻止。

# 查找被拦截的恶意prompt
wrangler tail api-gateway --format pretty | grep "Blocked potentially malicious prompt"

# 查找图片验证失败
wrangler tail api-gateway --format pretty | grep "Blocked invalid image"

这个维度的指标很特殊：有时候没有日志才是好消息。如果没有恶意攻击，就不会有拦截日志。但如果有拦截日志，说明防御措施在工作。

3. 业务维度

最终目标不是减少错误，而是改善业务指标。视频生成成功率应该提升。用户体验应该改善。

-- 最近24小时视频生成成功率
SELECT
  COUNT(*) FILTER (WHERE status = 'completed') as completed_count,
  COUNT(*) FILTER (WHERE status IN ('failed', 'failed_processing')) as failed_count,
  COUNT(*) as total_count,
  ROUND(100.0 * COUNT(*) FILTER (WHERE status = 'completed') / COUNT(*), 2) as success_rate
FROM ai_generations
WHERE created_at > NOW() - INTERVAL '24 hours'
  AND type = 'video';

如果错误率下降了，但成功率没提升，说明修复可能不够彻底。

分阶段检查清单

48小时观察期，分三个检查点。

部署后1小时：快速验证

修复是否正常工作。基本功能是否可用。有没有明显的回归问题。

检查项：

• 部署状态确认（Worker版本、环境变量）
• 首次错误日志扫描（是否有新的异常）
• 核心功能冒烟测试（手动触发一次正常流程）
• 告警系统测试（Telegram通知是否能收到）

这个阶段不是找所有问题，而是确认"没有重大灾难"。

部署后24小时：趋势观察

数据开始有意义。可以看到初步的趋势。

检查项：

• 错误率对比（与修复前同期对比）
• 用户分布分析（是否集中在特定用户）
• 业务指标初步对比（成功率、转化率）
• 异常模式识别（是否有新的错误类型）

这个阶段是发现问题的关键窗口。如果修复无效，通常在24小时内会显现。

部署后48小时：最终评估

数据足够完整。可以做出结论。

检查项：

• 完整数据汇总（所有维度的指标）
• 预期目标达成评估（是否达到预期改善）
• 修复有效性结论（是否需要进一步优化）
• 后续行动决策（是否需要新的修复迭代）

48小时不是随意选择的。太短，数据不够；太长，反馈太慢。对于大多数Web服务，48小时足够覆盖用户的主要使用场景。

应急响应的预设

观察期不只是观察。也是准备。

如果监控发现问题，应该如何响应？提前规划，而不是临时决策。

场景1：错误率突增（>5%）

症状：Cloudflare Analytics显示402或500响应数激增

响应步骤：

1. 立即排查（5分钟内）- 查看实时日志，识别错误模式
2. 临时缓解（15分钟内）- 如果是特定模型，禁用该模型；如果是配置问题，修复配置
3. 根因分析（1小时内）- 深入日志，理解为什么修复无效
4. 修复部署（根据情况）- 准备hotfix或配置更新

场景2：告警过多（>10次/小时）

症状：Telegram群组频繁收到告警

响应步骤：

1. 确认真实性 - 是真实问题还是告警配置过于敏感
2. 修复配置 - 如果是模型配置缺失，更新pricing
3. 调整告警 - 如果是告警阈值问题，调整阈值

场景3：性能下降（P95 > 2000ms）

症状：响应时间显著增加

响应步骤：

1. 检查瓶颈 - 数据库、外部API、还是Worker自身
2. 临时优化 - 增加超时、减少日志、降级服务
3. 长期规划 - 实施缓存、优化查询、架构调整

预设响应计划的价值在于：减少决策时间，增加响应速度。

当问题发生时，你不是在想"该怎么办"，而是在执行"已经计划好的步骤"。

相关阅读：错误隔离讨论了如何设计系统使单个组件失败不会级联；让错误浮现强调了不掩盖问题的重要性。

监控的哲学

监控不是为了证明"我们做对了"。是为了发现"我们做错了什么"。

修复代码时，我们做出了很多假设：

• 假设问题的根因被正确识别
• 假设解决方案能解决问题
• 假设没有引入新的问题

监控是在系统性地验证这些假设。

有些团队把监控当作形式。部署完看一眼日志，没有明显错误就收工。这不是监控，是自我安慰。

真正的监控是：

• 主动寻找问题，而不是被动等待问题出现
• 对比预期与现实，而不是只看绝对数字
• 持续验证假设，而不是一次性检查

每个指标都在回答一个问题：修复是否真的解决了问题？

如果答案是"是"，观察期结束，任务完成。

如果答案是"否"，观察期提供了足够的数据，告诉你下一步该如何改进。

数据驱动的修复迭代

修复不是一次性的。是迭代的。

第一次修复可能解决了80%的问题。监控发现还有20%的边缘案例。第二次修复针对这20%。监控再次验证。

这个循环持续，直到：

• 所有预期目标达成
• 边际收益递减（继续优化的投入产出比过低）
• 新的更高优先级问题出现

监控提供反馈，反馈驱动改进。

没有监控，修复是盲目的。你不知道问题是否解决，不知道引入了什么新问题，不知道下一步该优化什么。

有了监控，修复是科学的。数据告诉你哪里好，哪里差，哪里需要关注。

最后

部署不是终点。是验证的起点。

修复代码时，我们在纸上画出了解决方案。监控观察期，让这个方案在真实世界中接受检验。

48小时，三个检查点，多个维度的指标。不是为了完美，而是为了真实。

真实的数据，真实的反馈，真实的改进。

监控观察期不是额外的工作，而是修复流程的有机组成部分。没有监控的修复，就像没有测试的代码，看起来完成了，但谁也不知道它是否真的有效。

让数据证明修复。这是对用户负责，也是对自己负责。