测试、发布、灰度与事故处理

审核通过，你准备全量发布。真机测试一直使用新账号，老玩家更新后却打不开存档。为什么“审核过了”和“测试通过了”都没挡住事故？

本篇帮助你把上线视为受控的真实影响范围变化，并预先安排观察、止损与恢复。

为什么上线证据必须对应真实路径

审核检查有自己的范围，不能替你证明所有机型、旧数据和外部依赖。新账号通关也没有覆盖升级兼容。每项检查要写材料、版本、设备、操作与实际结果，才能知道没测到什么。

发布前至少同时检查四组内容：体验与质量，数据与资产，平台与材料，运营与恢复。它们相互依赖：无奖励对账的可选广告可能伤权益，无反馈入口的问题也会更晚被发现。

检查组	为什么是发布条件	证据示例
体验与质量	真实环境下仍需可玩、可恢复	真机、弱网、后台、首次与升级记录
数据与资产	结果与权益需可信	事件去重、奖励幂等、订单核对
平台与材料	允许发布不只取决于代码	后台状态、隐私、版权、实际资质
运营与恢复	出错后有人识别与处理	值守、反馈、停用与回滚演练

用 上线模板 保存证据。硬门槛未知时保持阻断，不能用一个勾掩盖尚未核验。

为什么灰度先看可靠性，再看产品提升

小范围发布限制了首次暴露的影响，让你先检查启动、存档、资产与数据链。若明细缺失，此时的完成率即使上涨也不可信。平台可用的灰度方式需按实际能力确认。

记录客户端、内容配置、资源、存档和事件版本的兼容关系。内容更新也可能改变题意与历史成绩，因此不能当作无风险的纯数据发布。观察窗口、负责人和停止条件在发布前写，阈值来自基线与可承受后果，不套无来源的行业数字。

为什么回滚代码不等于恢复产品

旧代码可能读不了新存档，客户端分发与审核也未必允许即时退回。若奖励已多发，回到旧版本并不会撤销已有状态。应提前设计能合规停用问题入口的配置、兼容和资产核对方案。

例如广告暂时关闭，玩家应怎样继续；旧客户端遇到新内容，是否能回到可用路径；修复前怎样解释未确认权益。涉及恢复时保留审计，不随意覆盖原记录。

从事故过程推导复盘内容

先控制新增影响并保全必要信息，确定受影响版本、人群、时间与状态，再修复、对账、补救和验证开放条件。给玩家说明已确认的事实、影响和进度，不把猜测当原因。

复盘分别问：什么触发、何时发现、为何没有更早发现、怎样响应、状态是否真正恢复、哪项设计能降低下次影响。只写“加强测试”没有指出缺哪一种证据，也就无法改善。

适用边界：灰度不能试探不可接受的风险

已知严重权益、隐私或合规缺陷，不能因为人数少就先放出去。灰度用于处理剩余不确定性，不代替发布前必要条件。反过来，过度追求覆盖所有可能也不现实，应明确风险、监测和可恢复范围。

练习：演练“奖励重复发放”或“升级后旧存档打不开”。写停止入口、识别范围、恢复依据和重新开放条件，再把实际缺口补进清单，进入 生命周期管理。