接口稳定性与 SLA
Swarmix 的可用性目标、维护窗口、订阅状态通知。
SLA 目标
| 支持级别 | 月可用性 | 故障响应时间 | 补偿 |
|---|---|---|---|
| 标准账户 | 99.0% | 工作日 48h | 无 |
| 高优先级支持 | 99.5% | 工作日 24h | 故障时间 ×1 倍余额补偿 |
| 生产保障 | 99.9% | 7×24h · 2h 响应 | 故障时间 ×3 倍余额补偿 |
| 企业合约 | 99.95% 合约级 | 7×24h · 30min 响应，专属客服 | 合同约定 |
不计入 SLA 的情况
以下场景造成的不可用，不计入 SLA 可用率统计：
- 提前 7 天公告的维护窗口
- 不可抗力（机房 / 运营商故障）
- 上游厂商大规模故障（阿里云 / 腾讯云等超过 30min 的事故）
- 客户自身导致（Key 泄露被封、恶意攻击流量等）
状态页
公开状态页：status.swarmixtoken.com
每分钟从独立监控节点探测：
- Router
/v1/chat/completions（用 mock 模型，不产生真实消耗） - 客户平台 API
/v1/auth/me - 按厂商分组的上游可用率
维护窗口
- 计划内维护：每周三 03:00 - 04:00（UTC+8），影响 < 30s
- 大版本升级：提前 7 天邮件 + Webhook 通知；滚动发布对客户透明
- 紧急修复：无法预告，事后发 postmortem 报告
故障订阅
推荐至少订阅一个：
- 状态页 RSS：
http://status.swarmixtoken.com/feed.rss - 邮件通知：在 Console → 设置 → 通知设置 勾选「故障告警」
- Webhook：订阅
system.outage.*事件
历史事故
所有 P0/P1 级事故 7 天内公布完整 postmortem（包括根因、时间线、改进措施）。 往期见 事故档案。
报告问题
有序的 bug 报告能 10 倍加速排查
请在 工单系统 提交，并至少附上：
- 请求 ID（
x-request-id响应头） - 发生时间（精确到秒）
- 使用的模型 + Key 的前 8 位（便于定位）
- 响应的完整 JSON（尤其是
detail字段） - 你预期发生什么、实际发生什么