一张大促清单有二十个绿勾仍可能没人知道其中“容量充足”到底测过什么。绿勾应是证据的索引不能是证据本身。对小团队来说最有价值的清单往往不是长而是每项都能找到人和回退动作。从风险倒推不从模板倒抄Google SRE 发布章节提供检查清单的组织经验。不同团队的依赖、目标和承受能力不同不能把别人的流量阈值搬来当安全线。下面是构造的订单与 AI 客服联合准备表既不是今年实际排期也不是已完成验收。风险应收集的指标或证据负责人角色可撤回动作客服模型供应商失败隔离故障注入记录、降级文案与任务状态客服后端切换到已审查的只读 FAQ 与人工入口预算预占服务不可用拒绝策略测试、剩余额度一致性计费后端暂停新的付费调用订单预占迟迟未核销过期记录数量、订单回查结果订单后端停新预占并执行幂等对账配置回退依赖已变旧配置回放结果和权限检查发布负责人恢复已验证快照或停止入口这些角色必须在实际验收时填成当班个人及替补。没有测试记录的行保持“待验证”不能因为服务现在没报错就改成通过。阈值要有来历错误率、排队时长和预算敞口应由业务目标、正常基线、依赖约束和演练结果推导。比如“等待超过两秒就降级”可能对聊天合理对生成视频却毫无意义。阈值还必须说明统计窗口、样本量和低流量处理否则一个失败请求就能触发全站切换。每条告警至少关联一个动作谁先确认影响谁有权限拒绝新请求执行后看什么信号。若只能通知某个群却没有人负责判断告警再灵敏也不能算准备完成。把十月变化纳入差异评审模型别名、缓存策略和搜索计费的公告可能影响原先的预算与验收依据。清单应记录“自上次演练后变了什么”而不是只保留上次的绿勾。未生效公告写为待复核不能预填未来实绩。这篇没有压测结果也没有真实值班人员名单。交付的是一种可执行清单的填写方法发布前由团队补齐证据、人员和窗口无法补齐的风险要明确交给负责人决定。