批量、审计、任务与监控

批量操作先固定目标条件和预览数量，再执行。系统逐项生成回执；部分成功时查看失败项和原因，不要盲目重跑整批。导出、营销群发与异常工作台分别受各自权限控制，执行前检查预览与审计。批量通知可同时选择邮件、站内信与 Telegram；预览会列出所选通道或语言缺少的模板，补齐前不能执行；没有绑定 Telegram 的用户记为跳过并注明原因，报告按通道统计。

可靠任务复制标题链接

业务事务将副作用写入 PostgreSQL jobs/outbox。普通任务由分钟 Cron，重任务由小时 Cron 驱动；自托管用进程循环。检查积压、最老任务年龄、租约、尝试次数、最后错误与死信。处理器按当前状态幂等执行，不能通过直接修改任务载荷“修复”历史。

重放死信前先修复根因、核对外部结果与去重策略。暂停外部服务后注意恢复的突发负载。故障证据使用 request id 串联请求、审计和任务，日志中的敏感字段必须脱敏。

健康和指标复制标题链接

入口	表示什么	注意
/healthz	表示什么进程存活	注意不访问数据库，不代表可提供业务
/readyz	表示什么数据库、schema 兼容、安装状态与积压	注意发布后必须检查
/metrics	表示什么队列、死信、付款、节点、用量与降级指标	注意Bearer 抓取令牌（配置其 SHA-256 摘要），或持有 ops.health.read 的服务账号 API Key

对任务积压、死信增长、未匹配支付、节点离线/未收敛、异常上报和易失层不可用告警。缺失/非法 metrics 摘要均拒绝访问。HTTP 延迟与错误率在 Workers 使用平台分析，自托管使用进程指标；只看存活探针会漏掉业务故障。

维护开关与恢复复制标题链接

恢复数据前，在运维工作台打开维护开关（需要 system.maintenance.manage，预置角色中只有 root，并需再验证）。打开后所有写接口返回 503 platform.read_only，后台任务停止领取，门户与后台显示维护横幅。它不是数据库只读模式：审计、限流计数和开关本身仍会写入；开关打开前已在执行的请求与任务会继续完成，确认它们结束后再开始恢复。后台不可用时，可用直连数据库的命令行工具开关维护模式。

唯一的 root 丢失 TOTP 时，由两人在场使用直连数据库的 root 恢复工具：默认只预演，执行时需交互输入确认语句，会重置该账号的 TOTP 与备用码、撤销全部会话并写审计。恢复后立即重新绑定，并增加第二名 root。

回滚和恢复步骤见升级与备份。