和游戏API供应商合作，怎么评估对方的应急响应能力？本文拆解4个评估维度、故障根因定位时间轴、供应商与自己的归因边界，以及停服失联时的自保动作清单，帮出海平台在合作前看清、出问题时守住。
先问一句。
你评估一家游戏API供应商的应急响应能力时，看的是什么？多半是那份SLA，上面写着可用性几个9，写着故障响应承诺。数字很漂亮。
可真出事那一刻，决定你损失大小的，从来不是合同上那几个9。是另一个东西——从故障发生，到你自己能定位根因、能动手自保的那段时间。
这段时间越长，你越被动。而它长不长，一半在供应商，一半在你自己有没有提前做功课。所以游戏API供应商应急响应能力评估这件事，得换个看法：不是读承诺，是拆时间轴。
划重点：SLA的几个9是入场券，不是安全感。真正的游戏API供应商应急响应能力评估，要落到「故障发生→你定位根因→你能自保」这条时间轴上，每一段的耗时和责任，才是该盯的账。
下面这篇，就按四个评估维度、一条根因定位时间轴、一张归因边界表、一份停服自保清单，把这笔账摊到桌面上。
合作前：评估应急响应能力的四个维度
先看这组该问的问题。合作前，大多数人只盯着报价和游戏数量，把应急能力当成"出了事再说"的事。等到真出事，才发现连找谁、多久回、怎么补都没约清楚。
评估一家供应商的应急响应能力，别只看它写了什么，要看这四个维度它能不能答得上来、答得具体。
维度一 · 响应时效。 不是问"你们多久响应"——谁都会说"7×24"。要问的是分级：什么等级的故障，多久给到初步定性？多久给到根因说明？升级路径是什么，一线扛不住时找谁？
- 可执行动作：让对方给出一张故障分级响应表，至少区分"服务不可用"和"部分降级"两档，各自的响应与升级时限分别写清。
- 安全边界（时效性）：口头承诺的响应时长若没落进合同附件，评估时只能当参考，不能当依据。
维度二 · 信息透明度。 出事时最折磨人的不是故障本身，是对方沉默。你不知道是它挂了还是你自己配错了，只能干等。透明度高的供应商，会主动同步状态页、事故进展、预计恢复窗口。
- 可执行动作：确认对方是否有独立于主服务的状态页（status page），以及历史事故复盘（postmortem）是否对客户开放。有没有这个习惯，大概率反映它的应急成熟度。
- 安全边界（风险性）：只有客服口头通知、没有任何书面或系统化同步渠道的，信息断层风险要往高里估。
维度三 · 降级预案。 一个成熟的供应商，不会指望自己永不宕机，而会准备"挂了之后怎么少疼一点"。比如部分游戏不可用时能否隔离、能否切备用节点、回调失败有没有补偿队列。
- 可执行动作：问清楚它在自己侧有哪些降级或熔断机制，以及这些机制触发时，会以什么形式通知到你这边。
- 安全边界（长期性）：降级预案会随版本迭代变化，别只在合作前问一次，要约定定期复核。
维度四 · 容灾冗余。 这是最容易被跳过的一维。单点部署的供应商，平时和多活的没差别，出事时才见真章。它的机房、链路、数据是不是单点，直接决定了最坏情况有多坏。
- 可执行动作：了解对方的部署架构是单区域还是多区域、有没有异地容灾，以及一次区域级故障它的恢复目标大致是什么量级（业界通常用RTO/RPO这类指标描述，RTO指恢复要花多久、RPO指最多丢多少数据）。
- 安全边界（风险性）：拿不到任何架构信息、只用"我们很稳定"搪塞的，要把容灾这一维标为未知，而不是默认合格。
把这四维摊开你会发现，业界确实存在多种做法——有的供应商响应快但透明度差，有的架构硬但预案糙。没有一家满分。评估的意义不是找完人，是知道对方的短板在哪，好提前替自己补位。
说白了，这四维答得越含糊，你出事后要自己扛的就越多。
出事后：把根因定位拆成一条时间轴
先看这条线。真出故障时，从发生到恢复，中间不是一团乱麻，而是一串有先后的节点。你能不能少亏，取决于你在每个节点上花了多久。
下面这张图，把一次典型的API侧故障拆成六段。图里不标具体分钟——每家平台的规模、监控、值班配置差太多，标了也是误导；重点看的是各段之间谁在等谁。
故障定位时间轴（各段时长仅示意结构，实际因规模差异极大） T0 T1 T2 T3 T4 T5 │ │ │ │ │ │ ▼ ▼ ▼ ▼ ▼ ▼ [故障发生]→[你告警]→[你初判]→[找到根因/边界]→[供应商响应]→[恢复] │ │ │ │ │ │ └自己的段──┴──────────┴───────────┘ └──供应商的段─┘ （监控灵不灵、告警快不快，全看你） （这段快不快，看它的应急能力） ▲──────────── 你的"自保窗口"────────────▲ 在供应商响应之前，你能自己定位到多少， 决定了你是干等，还是已经在切备用、留证据
这条时间轴最值钱的一段，是从「你告警」到「找到根因或边界」——也就是你能不能快速判断：这到底是它的锅，还是我自己的锅。这段越短，你的自保窗口越大。
怎么把这段做短？给几个可执行动作：
- 先分层排查，别一上来就找供应商。按"网络可达 → 鉴权签名 → 业务参数 → 回调链路"的顺序过一遍，大概率能把问题圈到某一层。签名类、沙箱到线上环境差异类的坑，往往在自己这侧，具体排查思路可以参考我们另一篇——
- 留好"对账证据"。故障期间的请求ID、时间戳、双方日志片段，第一时间截存。这既是找供应商时的凭据，也是事后归因的依据。
- 安全边界（时效性）：日志有滚动周期，出事当下不留，过后大概率就没了。- 把"该升级找谁"提前写成一张联系人梯队表，别到凌晨三点才翻合同找电话。
- 安全边界（风险性）：只有一个客服QQ、没有值班升级路径的供应商，这段时间大概率会被拉得很长。
祛魅一句：所谓"根因定位能力"，听着玄，落到实处就是——你有没有一套不依赖供应商也能先跑一遍的排查顺序。有，你就有自保窗口；没有，你就只能等。
归因边界：到底是供应商的锅，还是你自己的锅
定位之后，紧接着一个绕不开的判断：这事该谁负责。判错了，要么白白跟供应商扯皮耽误恢复，要么把自己的锅甩出去、下次接着栽。
归因不是为了甩锅，是为了下一步动作——如果是你自己的配置问题，切换供应商也没用；如果是供应商侧，那就该走升级、走索赔、走切备用。判断方向，动作才不白费。
给一张粗线条的判断参照，帮你在现场快速圈方向：
- 大概率在你自己这侧：改了配置/发了版之后才出现、只影响你一家、沙箱正常线上异常、签名或参数报错。
- 大概率在供应商侧：你什么都没动就出现、多个接入方一起报、对方状态页有异常、返回的是对方系统级错误。
- 边界模糊、需要联合排查：偶发、只在高并发时出现、回调延迟或丢失——这类往往是两边链路叠加，光靠一方日志看不全。
- 可执行动作：现场先用上面三条给故障"贴个标签"，再决定是自己继续查、还是立刻拉供应商联合排查，别在方向没定之前空耗。
- 安全边界（风险性）："你什么都没动"这个前提本身要先核实——很多"供应商的锅"复盘下来，是自己某个自动任务或第三方依赖悄悄改了东西。
有一点得说在前面：责任的最终认定，尤其涉及赔偿的，属于合同和法律范畴，本文只帮你理排查方向，不构成法律或合规意见，真到追责那一步，请以合同条款和专业意见为准。
归因的意义不在甩锅，在于让下一个动作不白费。
Q（场景判断）：如果你现在只接了一家游戏API供应商，该不该马上再上第二家做容灾？
不一定，得看你的体量和这家的短板。如果你流水还小、这家四维评估里"容灾冗余"和"降级预案"都过得去，那多接一家带来的对接、对账、成本负担，可能比它防的风险还重，此时更该先把自己的排查流程和证据留存补齐。反过来，如果你已经有一定规模、单点故障一次就伤筋动骨，而这家又恰好在容灾这一维是未知或偏弱，那提前布局第二家、哪怕只做冷备，就值得认真算这笔账了。判断标准不是"要不要"，是"这家的短板 × 你的体量"够不够疼。
最坏情况：供应商停服、失联时，你怎么自保
前面聊的是"它还在、只是慢"。更极端的一种是——它不响应了，甚至联系不上了。这时候评估、归因都退居其次，先保住自己。
自保不是等出事才想，是提前把动作备好。按"事前、事中、事后"给一份清单：
事前（合作稳定期就该做）：
- 定期导出并本地留存关键业务数据与对账记录，别把唯一副本放在对方系统里。
- 安全边界（长期性）：这类留存要形成习惯、定期做，临时抱佛脚往往抱不着。- 把"切换预案"从纸面变成可演练的动作：备用通道怎么开、DNS或路由怎么改、灰度怎么放。
- 在合同里就把停服通知义务、数据导出条款、退出机制写清楚——这部分和供应商断供的早期征兆识别高度相关，怎么提前看出苗头、怎么管控依赖度，可以参考——
事中（正在停服或失联）：
- 第一时间固定证据：故障时间、影响范围、你尝试联系的记录，全部留痕。
- 安全边界（时效性）：失联时的沟通记录是日后主张权利的关键，别只截个图就算了。- 启动切换预案，先保住能保的业务，别把所有希望押在"它一会儿就好"上。
- 按事前写好的联系人梯队逐级升级，同时通过多渠道（邮件、工单、商务）并行触达，留下书面痕迹。
事后（恢复或切换之后）：
- 做一次复盘：这次哪段时间花在了自己身上、哪段花在了等对方，对照时间轴看短板。
- 重新评估这家的应急能力评分，决定续约、加冗余、还是换人。
涉及索赔与追责的部分，仍以合同和专业法律意见为准。
说白了，自保能力就是你手里那份"就算它不接电话，我也知道下一步干什么"的清单。清单越具体，你在最坏情况下越不慌。
换个角度：把复盘时间轴倒着走，才知道合作前该问什么
多数人评估应急能力，是顺着问：你们响应多快、有没有预案、容灾怎么样。对方也顺着答，答得都挺好。然后签约、出事、傻眼。
我们做供应商对接这些年，越来越倾向于反着来——把一次假想的故障复盘时间轴，倒着走一遍，用每一段可能卡住的地方，反推合作前到底该问什么。因为顺着问，问的是它想让你看到的；倒着推，问的是它最不想被追的。
倒着走这条时间轴：
- 从最后一段「恢复」倒推：如果它恢复慢，我有没有备用通道能先顶上？→ 合作前就该问：你们的降级/切换，需不需要我这边配合？要配合什么？
- 再往前，「供应商响应」这段：如果它半天不回，我该找谁？→ 合作前就该拿到：分级联系人和升级时限，白纸黑字。
- 再往前，「找到根因」这段：如果分不清是谁的锅，谁来举证？→ 合作前就该约定：故障时双方各自提供什么日志、多久内提供。
- 最前面，「告警」这段：如果它挂了但没告诉我，我多久才能发现？→ 合作前就该确认：它有没有主动通知机制，还是全靠我自己监控。
你看，倒着走一遍，四个必问就自己冒出来了，而且每一个都卡在"出事那一刻你最需要、但事后最难补"的位置上。这套倒推法，本质上是把"选型评估"和"出事排障"接成了一条线——评估的每一维，都对应着时间轴上一个具体的卡点。
如果你连这家供应商到底要打通哪些环节、哪一环出问题会怎样都还没理清，那不妨先把整条对接链路看明白，再来倒推应急——
顺着问，问的是它的说辞；倒着推，问的是你的软肋。
常见问题
Q：如果供应商张口就说"我们SLA是99.9%"，我还有必要追问应急细节吗？
有必要，而且这恰恰是该往深里问的时候。可用性数字描述的是"平时多稳"，应急能力描述的是"出事后多快能好"，两者不是一回事——一家全年很稳但一旦出事就失联很久的供应商，和一家偶有小故障但很快就同步进展的，体验天差地别。数字漂亮时反而要多问一句：那没落在这个数字里的那部分时间，你们怎么处理？把响应分级、通知机制、举证责任问清楚，比盯着小数点后几位有意义。
Q：接口偶尔报错、返回一些看不懂的错误码，是不是供应商不行？该不该因此换人？
先别急着下结论。接口报错是对接里的常态，关键看两点：一是错误信息够不够清楚，好的供应商会给规范的错误码和文档，让你能自己对号入座；二是这些错误是不是集中在你自己能控制的环节，比如签名、参数、限流触发。很多"供应商不行"的错觉，拆开看是自己没做好重试、没处理好限流退避。真要判断是否换人，回到那四个评估维度整体打分，别被一两个错误码带偏——单次报错是技术问题，长期定位不到、对方也不配合，才是应急能力问题。
Q：合作前只签了SLA、没约定停服通知和数据导出，现在想补，来得及吗？
来得及，而且越早越好，别等出事才想起来。这是个反面教训：不少平台就是因为合同里只写了"可用性承诺"，没写"停服要提前多久通知""数据要能随时导出"，真到对方要下线某些游戏或调整服务时，自己完全被动。现在能做的是：主动发起合同补充，把通知义务、数据导出、退出机制补进去；同时不管合同谈成什么样，自己那份数据本地留存和切换预案都要先做起来——合同是事后追责的依据，自保动作才是当下能护住你的东西。涉及条款效力和追责，仍请以专业法律意见为准。
把评估落到你自己的时间轴上
说到底，游戏API供应商应急响应能力评估这件事，评的从来不只是对方，也是在评你自己：出事那一刻，你手里有没有一条清晰的时间轴、一份能照着做的自保清单。
对方的四个维度决定了故障有多频繁、多严重；你自己的根因定位和自保能力，决定了同样一场故障，落到你头上会疼多久。前者靠合作前问清楚、写进合同，后者靠平时就把排查顺序、证据留存、切换预案备好。
如果你正在评估某家游戏API供应商、或者想给现有的对接补一套更扎实的应急与自保方案，欢迎找 WG客服 聊聊——我们不替你拍板换不换供应商，而是帮你把评估维度、根因排查流程和自保清单，按你自己平台的体量捋成一条能落地的时间轴。
先做个简单的自查：拿这篇里的四个评估维度和那条故障时间轴，对着你现在合作的供应商和自己的应急流程各打一遍分——哪一维是未知、哪一段最容易卡住，答案往往就在那几个你一直没敢细想的地方。