下面三条是占位样例，不是真实发生过的事故。 它们写成这个样子是为了说明我们打算怎么复盘——影响面写具体百分比、时间线到分钟、根因和改动都署名。真实事故发生后会替换掉它们，并去掉「样例」角标。我们不打算把这一页做成空的：一个从不出事的复盘页只说明它没在记录。
一家上游供应商的响应延迟从中位 1.2 秒升到 9 秒以上，超过了我们首 token 超时阈值的一半。灾备按预期把请求转到了同能力组的备用模型，没有请求失败，但受影响用户感知到明显变慢。
时间线
- 14:22探测发现 frontier-a 首 token 延迟超过基线三倍，自动降权。
- 14:31延迟继续上升，熔断触发，流量全部转向 frontier-b。
- 14:38frontier-b 并发接近上限，排队延迟出现。人工介入，临时放开跨供应商配额。
- 15:09上游恢复，逐步回切并观察 20 分钟后确认稳定。
根因
我们对单个供应商的容量估计过于乐观，frontier-b 的储备并发只按日常峰值的 1.3 倍配置，不足以在另一家完全不可用时独立承载。熔断本身工作正常，问题出在储备容量不够。
我们改了什么
- 前沿推理组的储备并发从日常峰值的 1.3 倍提高到 2.5 倍，并纳入容量预测的告警口径。
- 熔断阈值从「超时」细化为「延迟超过基线 3 倍持续 60 秒」，提前约 9 分钟触发。
- 受影响时段内所有走了灾备的请求已按原能力组计费，差价由我们承担，无需申请。
用量事件的异步落库任务积压，控制台显示的已用额度低于真实值。配额扣减本身没有受影响——Redis 侧的计数是准的，限流按真实用量执行。受影响的只是明细展示。
时间线
- 03:10落库队列积压告警触发。
- 03:52定位到一条缺失索引的查询拖慢了批量写入。
- 05:22补建索引，积压清空，对账确认无数据丢失。
根因
新增的按项目筛选功能引入了一条没有覆盖索引的查询，在月末数据量下退化成全表扫描，和落库任务抢锁。
我们改了什么
- 补齐索引，并在 CI 里加了慢查询回归检查。
- 落库积压超过 5 分钟时，控制台顶部直接显示「数据延迟中」，不再让用户看到一个安静的错数字。
一次地域规则更新把一批本应可用的境内模型误判为不可用，受影响用户在选择模型时看到置灰。没有产生错误计费，也没有反向问题（即不存在应拦未拦的情况）。
时间线
- 11:05规则发布。
- 11:18用户工单反馈模型不可选，值班确认为误判。
- 11:31回滚规则，恢复正常。
根因
备案状态字段的默认值写成了「未备案」而不是「保持不变」，导致这次更新里没有显式声明的模型被一并标记为不可用。
我们改了什么
- 该字段改为必填，没有显式值的更新直接拒绝发布。
- 地域规则发布前增加一步 diff 预览，列出本次将改变可用性的模型清单。
正式上线后这一页由真实事件驱动。