《游戏服务端架构·核心系统与契约》附录 C 核心系统故障模式清单

这份清单怎么用

卷二每一章都给了单个系统的失败模式。真正出事时，问题很少只停在一个系统里：登录超时会触发重试，重试会放大网关压力，网关摘除节点又会让房间分配失败，最后表现为“玩家进不去游戏”。

这份附录做三件事：

1. 统一失败模式的描述格式，避免“偶发”“不稳定”这类无法行动的措辞；
2. 按系统列出高频失败模式，给出可探测信号与兜底动作；
3. 给出跨系统故障链和最小可观测集，供评审与演练直接使用。

清单不是事故预案的全部。预案还需要联系人、升级路径和对外话术，那些属于运维与组织流程，不在本书范围内。

一、统一的描述格式

每个失败模式至少写清六件事：

不合格写法：“偶发登录失败，重试即可。”它没有说明触发条件、影响面和责任方，也无法判断重试会不会放大故障。

二、按系统的失败模式

2.1 账号与身份

2.2 登录与网关

2.3 匹配与房间

2.4 场景与世界

2.5 战斗与结算

2.6 经济与交易

2.7 成长与任务

2.8 社交与公会

2.9 排行榜与赛季

2.10 邮件与奖励

2.11 支付与合规

2.12 平台服务

三、跨系统故障链

单点失败不可怕，可怕的是它沿着依赖链放大。下面几条是游戏服务端最常见的链路。

3.1 登录雪崩

票据服务变慢
  → 客户端超时重试
  → 网关连接数上涨
  → 账号服务被打满
  → 更多超时与重试

断链点在两处：客户端必须指数退避，网关必须限制单位时间的新建连接。只加机器通常追不上重试的放大速度。

3.2 重复发奖

结算任务超时
  → 调度器重跑
  → 发奖接口未做幂等
  → 同一玩家收到多份奖励
  → 经济指标异常

断链点只有一个：发奖接口的幂等键与唯一约束。下游对账只能发现，不能阻止。

3.3 补偿风暴

事故公告
  → 运营触发全服补偿
  → 邮件系统批量写入
  → 邮件库与推送过载
  → 其他系统延迟上升

断链点：补偿必须走审批与批次幂等，并且限速；不要用“再发一次”解决“可能没发到”。

3.4 赛季边界错位

赛季截止任务延迟
  → 旧榜仍在写入
  → 结算读到截止后的数据
  → 排名与奖励争议

断链点：截止时刻先冻结写入，再结算；冻结与结算都要幂等。

3.5 时区重置错误

重置任务按 UTC 执行
  → 与玩家所在时区不一致
  → 部分玩家日常提前/延后
  → 客诉与重复领取

断链点：重置窗口按产品规则显式计算，并在执行前校验时区配置。

四、最小可观测集

每个核心系统至少暴露下面六类信号，缺一项就意味着故障只能靠客诉发现。

指标要带租户、游戏、分区维度，否则多游戏共用平台时无法判断影响面。

五、演练与复盘

5.1 演练的最小场景

不需要一上来就做混沌工程。先做三个可控实验：

1. 依赖超时：给账号或支付接口注入固定延迟，观察重试与排队是否放大；
2. 实例摘除：手动下线一个网关或房间节点，观察归属表与重连；
3. 重复投递：把同一条结算或支付回调投递两次，验证幂等。

三个实验都能在测试环境完成，且能覆盖大部分高频故障。

5.2 复盘要回答的问题

• 故障是如何被发现的？如果是客诉，说明可观测性有缺口；
• 影响面为什么是这么大？是故障域设计问题，还是隔离失效；
• 哪个环节本可以自动兜底，却没有；
• 哪个契约没有被遵守，导致问题跨系统放大；
• 下一次同类故障，系统应该有哪些不同。

复盘结论要落到具体改动：代码、配置、监控、流程，至少有一项。只写“加强监控”“提高意识”的复盘，下次还会发生。

六、常见错误

七、一页纸模板

故障编号：INC-____
发现方式：监控 / 客诉 / 巡检        发现时间：____
影响面：____ 个玩家 / ____ 个房间 / ____ 个分片 / ____ 款游戏
直接原因：____
放大链路：____ → ____ → ____
断链点（本应生效的契约）：____
临时处置：____（时间，负责人）
永久改动：____（代码 / 配置 / 监控 / 流程）
新增或修改的失败模式：____（回填本清单）
复审日期：____

清单到这里结束。它的价值不在于列全所有故障，而在于让团队在事故发生前，就把“怎么发现、影响多大、谁来兜底”写成可执行的条目，而不是等到会议上才第一次讨论。