事件响应流程

Runbook 解决单类故障，本页解决多人协作和处置顺序。目标是先控制影响，再定位根因，最后验证数据和计费完整性。

事件级别

级别	示例	响应目标
P0	全站不可用、数据库损坏、凭证大规模泄漏	立即响应，优先止损和隔离
P1	生产 Group 无可用账号、大面积 5xx、计费错误	立即处置，尽快恢复核心能力
P2	单平台/模型退化、延迟明显、部分账号失效	工作时段快速处理
P3	单用户配置、低风险告警、优化项	排期处理

严重级别应由用户影响和数据风险决定，不只看 HTTP 状态码。

前 10 分钟

1. 记录事件开始时间、发现方式和当前版本。
2. 确定影响范围：全站、平台、Group、模型、用户还是单账号。
3. 保存一个失败 Request ID 和一个成功对照 Request ID。
4. 检查最近发布、批量配置、凭证轮换和上游公告。
5. 判断能否通过摘流、切备用池、关闭功能或回退快速止损。
6. 指定一名处置人和一名记录/沟通人。

快速分层

/health 不通
  → 进程、容器、DNS、TLS、反向代理

/health 通，但登录/后台异常
  → JWT、Redis、DB、反向代理、前端资源

登录正常，但所有模型请求失败
  → API Key middleware、Group、调度、账号池、DB/Redis

仅单平台/Group/模型失败
  → 模型映射、账号状态、上游、Proxy、价格

请求成功但费用异常
  → usage、billing model、价格、倍率、异步写入

止损动作优先级

从影响最小到最大选择：

1. 单账号 schedulable=false。
2. 从单个生产 Group 移除问题账号。
3. 切换到已验证备用池。
4. 暂停单模型或单功能。
5. 回退刚发生的配置变更。
6. 回退应用版本。
7. 数据库恢复或全站维护。

不要在没有证据时同时重启应用、Redis、数据库并清除账号状态，这会丢失现场并扩大影响。

收集证据

• 失败和成功 Request ID。
• 时间范围、时区、平台、Group、模型。
• 应用版本、镜像 digest、Git commit。
• Ops 错误详情的 phase/owner/source/account。
• 反向代理、应用、PostgreSQL、Redis 相关日志。
• 变更前后配置和操作者。
• 上游响应码、request ID、余额/限额和状态页。
• 用户费用与账号成本是否已写入。

复制日志时必须脱敏 API Key、OAuth token、Cookie、Authorization 和用户 prompt。

恢复验收

恢复不以“错误消失”为终点。必须验证：

• 外部 /health 和后台登录。
• 目标 Group 的 /v1/models。
• 非流式、流式和业务所需能力。
• 主/备用账号实际被正确调度。
• 错误率、TTFT、队列和账号可用数恢复。
• Usage Log、token、模型映射和费用正确。
• 客户端断开后并发槽位释放。
• 告警事件进入 resolved 或人工关闭并有说明。

复盘模板

事件：
级别与影响：
开始/发现/恢复时间：
用户症状：
直接原因：
根因：
为什么监控没有更早发现：
止损动作：
恢复动作：
是否有数据/计费影响：
短期改进：
长期改进：
负责人和截止时间：

“上游不稳定”不是完整根因。还要说明为什么备用池、告警、容量或错误隔离没有把影响控制在可接受范围。