Odoo 19 生产稳定性很少死在「CPU 偶尔冲高」，更常见的是异步队列堆满、mail.mail 发送失败却无人知、出入站 Webhook 静默丢单。把这三项放进同一告警通道，并给每条告警附 runbook 链接，值班才能在夜班真正修好。本文说明各指标怎么取数、阈值怎么分昼夜、告警字段必须带什么，以及一次重放演练怎么做。
队列深度：积压比成功率更敏感
无论用企业队列作业还是自建任务表，都要监控：等待中数量、失败重试中数量、最早任务已等待多久、消费者是否存活。长报表、大批量导入、重建价格表必须入队，避免 HTTP 卡死。工作时间建议 5 分钟探测一次；夜间可 15–30 分钟。毒丸消息（反复失败同一 payload）要隔离，不要堵住后面整队。
邮件：事务与营销通道拆开
监控 mail.mail 的失败状态、SMTP 返回、积压封数。重置密码、订单确认、审批通知属于事务邮件；营销推送、订阅期刊走另一通道或另一 SMTP / 中继。混用会导致营销被拒连累事务邮件，用户无法登录重置。告警示例：「15 分钟内失败 ≥10 封」或「事务通道成功率 < 99%」。排查顺序：凭据、黑名单、SPF/DKIM、收件人无效、附件过大。
Webhook：错误率、延迟、最近成功时间
出站自动化与入站控制器都要记日志：业务单据 id、HTTP 状态、耗时、幂等键。指标：错误率、P95 延迟、距离上次成功的时间。告警必须能点进业务单；附「如何重放 / 如何降级」runbook。入站侧坚持验签 + 快速 ACK + 异步消化；出站侧坚持幂等键与人工重放台账。
同一告警通道与 runbook
队列、邮件、Webhook 接到同一 Discuss 频道或企业微信机器人，避免三个系统三套值班群。告警正文固定字段：环境、指标、当前值、阈值、样本链接、runbook URL、已经自动执行过的缓解（若有）。runbook 至少含：查看命令/菜单路径、常见误判、重放步骤、升级呼叫谁。
演练与验收
- 人为断开 SMTP，确认事务邮件失败告警在阈值内到达。
- 暂停消费者让队列堆积超阈值，确认告警并按 runbook 恢复。
- 伪造 Webhook 失败，值班按文档完成一次重放。
- 记录 MTTA/MTTR，纳入月度运维回顾。
- 三项指标在工作时间可见。
- 告警可跳转样本单据或任务。
- 新值班员只看 runbook 能完成一次重放。
值班 runbook 最小目录
建议三份独立 runbook：队列积压、邮件失败、Webhook 错误。每份包含：
如何确认指标、常见误判（如营销通道拒信）、缓解步骤、重放步骤、升级呼叫树。
告警消息用同一模板字段，便于新人复制粘贴到事故单。每月桌面推演一次：不碰生产，
只按 runbook 口述操作；每季实操一次注入故障。与 mail.mail 失败列表、
队列管理菜单、出站台账菜单互相做深链。
告警静默窗口（维护模式）必须有结束时间自动恢复，禁止长期静默。
指标字典与值班交接
为队列深度、邮件失败率、Webhook 错误率各写阈值（工作时间/夜间）、数据来源、图表位置、 关联 runbook。交接班必须包含：当前告警、静默窗口、进行中重放。维护模式自动到期解除静默。 月度回顾 MTTA/MTTR 与误报率，误报高就调阈值或修探测，而不是让值班麻木。三板斧进同一频道， 但 runbook 分开，避免步骤串台。
注入故障的日期提前公告，防止与真实大促重叠。
主题 393 收尾：权限、测试数据清理与 runbook 链接由负责人签字。
预生产勾选表需覆盖文章编号 393 全部验收点后再约生产窗口。
将文章编号 393 的配置变更记入发版说明，便于回滚对照。
将文章编号 393 的配置变更记入发版说明，便于回滚对照。
将文章编号 393 的配置变更记入发版说明，便于回滚对照。
将文章编号 393 的配置变更记入发版说明，便于回滚对照。
落地备忘（393-0）：把本文验收项做成检查表，预生产逐条勾选并附截图；生产窗口前提交负责人签字。相关模型与字段以当前 Odoo 19 实例开发者模式显示为准。
中国Odoo网｜对照 Odoo 19 企业版运维监控实践：队列·邮件·Webhook 同通道告警，每条告警带可执行 runbook。