共用一把 key 时谁来报障：五个人用同一账号，问题怎么描述才有效

为什么五个人报障等于没报障

共用一把 key 的团队经常出现这种场景：A 说“刚才全挂了”，B 说“我这边一直好好的”，C 补一句“是不是欠费了”，D 又开一条新对话问同一个问题。对支持方来说，这不是五份信息，而是五个互不对齐的时间点、五种口径各异的描述，以及一段无法复现的空白。

聚合站同时代理多个模型厂商，一个请求要经过网关、路由、上游供应商几层。缺少请求 ID 和时间戳，支持方只能猜是路由问题、上游波动还是客户端配置问题。报障的质量，取决于信息能否对齐到同一个请求、同一段时间。

第一步：指定单一报告人

在团队内部先约定一个规则：共用 key 期间，对外报障只由一个人发出。

• 报告人通常由 key 的持有者或主要维护者担任，因为他能看到用量、余额和 key 状态。
• 其他人不直接联系支持方，而是把各自观察到的现象汇总给报告人。
• 报告人对信息做去重和合并，再发出唯一一份报告。

这样做的直接好处是：支持方只需要和一个上下文完整的人对话，不会被多路并行的追问打断，也不会因为不同人给出不同结论而反复确认。

第二步：先统一时间线，再写现象

多人描述的“刚才”往往指不同时刻。让报告人先做一次时间对齐：

• 统一用同一个时区记录时间，最好直接记 UTC 或标明时区偏移。
• 让每个人给出“第一次出现”“最后一次出现”的具体时间，而不是“几分钟前”。
• 把现象按时间顺序排列，标明哪些是并发发生、哪些是先后发生。

一份好的时间线读起来像这样：某时刻起某类请求开始失败，持续了多长时间，期间是否有人成功过。是否有成功案例非常关键——它能帮助判断是全量故障还是特定模型、特定参数、特定客户端的问题。

第三步：每条失败都带上请求 ID 与时间戳

这是最容易做、也最容易被忽略的一步。聚合站的响应头和错误体里通常会带有请求标识，客户端日志里也能找到。

报障时按这个格式给出原始证据：

• 请求时间（含时区）
• 请求 ID（或响应头中的追踪标识）
• 使用的模型名称
• HTTP 状态码与返回的错误类型
• 客户端与 SDK 版本

不要只贴一句“报错了”。一段可检索的请求 ID，比十句现象描述更有用。如果错误信息里包含上游返回的原始文案，原样保留，不要自己改写或翻译。

第四步：区分事实、推测和诉求

把报告内容分成三层写，支持方读起来会快很多：

1. 事实：观察到的时间、请求 ID、状态码、影响范围（几个人、哪些模型、哪些客户端）。
2. 推测：例如“我们怀疑是某个上游波动，因为同一时间另一模型正常”，明确标注为推测。
3. 诉求：需要对方确认什么、是否需要调整路由、是否涉及计费核对。

推测混进事实里，会让排查方向被误导；只给现象不给诉求，则容易来回拉扯。

第五步：把这条报告固定在同一处

五个人各发一份的根源，是信息没有落点。用一处固定位置承载整个事件：

• 团队内部建一个事件记录，把现象、请求 ID、时间线追加在同一处。
• 对外只发一条主报告，补充信息以回复形式追加在原对话下，而不是新开话题。
• 问题缓解后，在同一处写清结论和后续动作，避免下次重复排查。

常见误区

• 同时开多条对话：支持方无法判断哪条是主报告，容易重复处理。
• 只描述感受不提供证据：“特别慢”“完全不能用”无法定位，补上请求 ID 和时延数据才有意义。
• 把客户端问题当成服务端问题：先在团队内部确认 key 是否有效、余额是否充足、客户端配置是否一致，再对外报障。
• 多人各自改配置试错：排查期间随意更换模型或参数，会让后续请求的证据与故障期不可比。

一份可直接套用的模板

报告人：X（共用 key 维护者）

影响范围：N 人，涉及模型 A / B，客户端为 C

时间线（UTC+8）：某时某分起失败，某时某分后恢复

证据：请求 ID + 时间戳 + 状态码 + 错误原文（逐条列出）

已排除：余额、key 状态、本地网络

诉求：确认是否为上游波动，以及是否影响计费

把这套流程固化成团队习惯后，共用一把 key 并不会让报障变复杂——因为对外永远只有一条线索清晰的报告。