Runbook：无可用账号与模型不可用
常见现象包括 No available accounts、All available accounts exhausted、503，以及某些场景下的 404 model_not_found。
先区分 404 和 503
当前实现会重新诊断 Group 中的模型能力：
- 404 model_not_found：池里有账号，但没有任何账号配置支持请求模型。重点查模型名和映射。
- 503 service unavailable：账号池为空，或有能力的账号因限流、配额、并发、过载、临时摘除等暂时不能使用。
不要对 404 盲目重试；不要把所有 503 都归因于上游宕机。
排查顺序
1. 确认用户路由
- Sub2API Key 是否有效、启用且未过期。
- Key 绑定的 Group 是否正确。
- 用户是否被授权使用该 Group。
- 请求入口与 Group platform 是否匹配。
- Group 是否 active。
2. 确认池里确实有账号
- Account 是否加入当前 Group，而不是同名测试 Group。
- 平台是否兼容。
- 是否从 Group 被误移除。
- 是否批量设置了
schedulable=false。
3. 检查每种不可用状态
在账号列表和 Ops 账号可用性中查看：
- status error/inactive。
- schedulable false。
- expires_at。
- temp unschedulable until/reason。
- rate limit reset at。
- overload until。
- quota auto-pause。
- 当前 in-use 和 concurrency。
4. 检查模型
- 请求模型拼写和大小写。
- Group dispatch mapping。
- Account model_mapping/白名单。
- 上游模型同步结果。
- Channel pricing restriction 和 billing model。
5. 检查基础设施
- Redis 是否导致运行时状态或调度缓存异常。
- PostgreSQL 查询是否失败。
- 多实例 scheduler outbox/缓存是否滞后。
- 最近是否做过批量导入、Group 修改或模型同步。
恢复动作
| 根因 | 动作 |
|---|---|
| 模型未映射 | 在测试 Group 修正映射并验证 |
| 账号手动停调度 | 确认维护结束后恢复 schedulable |
| 临时摘除但根因已修复 | 测试成功后清除 temp unschedulable |
| 上游限流 | 等待 reset 或切换独立额度账号 |
| 并发满 | 等待/扩容账号池，谨慎调整并发 |
| 凭证错误 | 修复 Key/OAuth，再测试和 Recover State |
| Group 空池 | 加入已验证账号，不直接用未测试账号救火 |
禁止动作
- 不确认 reset 时间就批量 Clear Rate Limit。
- 为消除告警而开启“忽略无可用账号错误”。
- 临时把所有平台账号混入同一 Group。
- 直接把账号并发调到很大来掩盖容量不足。
- 未核对价格就切到高价备用模型。
恢复验证
- Ops 显示目标 Group available account 大于 0。
/v1/models包含请求模型。- 实际非流式和流式请求成功。
- 请求落到预期 Account 和 upstream model。
- usage 与费用正确。
- 观察至少一个告警窗口，确认没有再次耗尽。