运维

发布检查

1. 记录版本，跑新增逻辑回归及 SQLite、MySQL、PostgreSQL 迁移/运行路径验证。
2. 发布前做一致性数据库备份与校验，保留旧镜像及配置。
3. 发布后检查健康接口、实际请求、采集任务与账本。有人正在调用时 pending 大于 0 是正常现象，关注长时间未结算项。
4. 失败时按既定回退方案处理；回退镜像不等于可以随意覆盖掉发布后新增的数据。

采集与保留

正常采集约 5 分钟一轮，管理员池页面约 15 秒刷新。连续失败达到阈值会走现有通知通道；需确认通知接收配置可用，不能只看代码存在通知调用。

reservation、采集事件、符合清理条件的关闭窗口与 allocation、专用标定记录有批量保留清理；默认 90 天，环境变量 UPSTREAM_QUOTA_RETENTION_DAYS 最低 30 天。保留期应覆盖分析和审计所需区间。

pending 默认超过 30 分钟可能被回收。超长流式请求存在误回收风险，尚不能承诺长任务的精确份额记账。异步任务提交后已经结算的上游用量，不一定随任务后续失败退款一起退回。

权限与备份

普通成员只持有本站厂商密钥。不要把 CPA 管理凭据、上游 OAuth/Cookie、生产数据库或真实用户记录放进文档站。

日常应定期验证数据库备份可恢复，并把代码版本保存在独立介质或私有远端。本文列的是运维要求，不是对源码远端、CI 或定时备份已完成的承诺；实际以执行回报为准。