关键问题清单
Category
production / retro 子树。节点定位：设计评审清单——权威与一致性、容量与性能、失败降级恢复、发布回滚兼容四类，每个问题都要求证据而不是表态。
Definition
评审里的清单很多人都有，真正起作用的很少。差别通常不在覆盖面，而在问题的质量：一份清单如果问的是“你们考虑过性能吗”，得到的回答几乎一定是“考虑了”，评审就在一团和气里放行了一个没人验证过的方案。设计一份不会被敷衍的清单，核心是让每个问题都要求证据、数字或明确的未知项，而不是要求一个态度。
Problem
清单的价值取决于问题质量：「考虑过性能吗」得到的一定是「考虑了」，评审在一团和气里放行没人验证过的方案。好问题要求证据、数字或明确的未知项；清单按阶段拆开才用得起来（立项、设计、上线前各问各的）。
清单的价值取决于问题质量
能把评审问穿的问题，通常有三个特征：
- 要求证据而不是表态：不问有没有考虑，问依据是什么、数据在哪里。
- 落到具体场景：不问会不会出问题，问高峰期哪一个环节先到顶。
- 允许诚实的未知：回答“不知道”是被接受的，但要配套“谁在什么时间去弄清楚”。
反过来，容易被打发掉的问题往往又大又空，比如“可靠性怎么保证”“扩展性如何”。这类问题既没有场景也没有验收标准，回答者随口一句“目前没问题”就能结束。清单的设计者要清楚一件事：问题的宽泛程度，直接决定了回答的敷衍程度。
好问题要求证据而不是表态
把同一类关切改写成要求证据的形式，评审效果通常完全不同：
- 不问“性能够不够”，问“单机实测承载是多少、哪次压测得出的、余量按多少算”。
- 不问“数据会不会丢”，问“权威数据在哪个存储、写路径失败时会发生什么、谁来补偿”。
- 不问“出事怎么办”，问“最可能的第一故障是什么、发现它需要多久、止损动作是什么”。
- 不问“能不能扩展”，问“在线翻倍时第一个顶不住的组件是哪个、扩容要动哪些东西”。
这种问法的妙处在于它同时完成两件事：如果对方有准备，问题会引出扎实的推演；如果对方没准备，问题会当场暴露盲区，而不是留到线上才暴露。评审里最有价值的时刻，往往就是某个问题让方案作者第一次意识到自己没想过。
清单按阶段拆开才用得起来
一份贯通所有阶段的巨型清单几乎注定失效，因为多数问题在特定阶段根本没有意义。常见的拆法是按里程碑分册：
- 立项期：主导问题域是什么、最贵的故障会是什么、哪些决策不可逆、用什么原型验证。
- 方案评审期：状态归属、权威边界、容量推演、失败降级、发布与回滚。
- 上线前：压测结论、监控覆盖、应急预案、回滚演练、灰度与放量节奏。
- 复盘期：哪些问题被提前问到了、哪些漏了、漏的问题该补进哪一册。
分册的好处是每次评审只面对十几个相关问题，每个都有当下的意义。清单长度本身也是成本，一个两百条的全量清单会让评审变成走过场的打钩仪式。
权威与一致性类的问题
这一类问题针对的是状态边界，也是最容易在设计阶段含糊过去的地方：
- 每一类关键状态的权威源是哪一个，有没有双写或派生被当成事实的情况。
- 客户端上报的哪些数据会被直接信任，信任的边界在哪里。
- 两个系统同时修改同一份数据时，按什么规则裁决。
- 定时任务、异步消息和玩家操作并发到达时，顺序由什么保证。
这类问题被敷衍的代价极高，因为权威边界一旦上线就很难理清，补数、对账和追责都会长期为此付费。
容量与性能类的问题
容量问题最容易被“应该够用”带过，值得逐项追问：
- 从业务指标到系统负载的换算链是什么，每一环的依据是什么。
- 单机能力的数字来自实测还是估算，实测环境像不像生产。
- 第一个瓶颈预期出现在哪个组件，出现时的表现是什么。
- 开服、活动、版本更新这三个峰值场景分别按什么规模准备。
- 超过预期的应急预案是什么，是限流、排队还是降级。
容量类问题如果答不出数字，通常说明推演没做过，而不是真的没问题。这组问题的价值就在于把“感觉”逼成“数字”。
失败、降级与恢复类的问题
方案评审最常缺失的一块，是系统坏掉时的行为定义：
- 依赖的外部服务超时或不可用时，本系统进入什么状态。
- 哪些功能可以降级，降级是自动触发还是人工开关，开关放在哪里。
- 玩家侧的可见表现是什么，会不会出现卡死、重复扣费或状态错乱。
- 故障恢复后，中间态数据怎么处理，需不需要对账和补偿。
- 恢复时间的目标是多少，由什么手段保证。
这类问题的回答质量，往往直接预示了上线后第一次故障的混乱程度。回答里出现“应该不会挂”字样的方案，值得格外仔细地问下去。
发布、回滚与兼容类的问题
变更引入的风险有自己的问题集：
- 这次变更涉及哪些共存版本，旧版本客户端会遇到什么。
- 出问题时的回滚步骤是什么，回滚会不会带来数据层面不可逆的后果。
- 配置和数据的变更与代码变更是否需要同步发布，谁保证顺序。
- 灰度范围怎么定，观察哪些指标判断继续或停止。
很多团队回滚预案停留在“可以回滚”一句话上，真到出事时才发现回滚本身会触发新的故障。把回滚步骤问到可执行的程度，是这个清单分支的核心目的。
让评审不被敷衍的机制
问题清单只是工具，还需要配套的评审机制来兑现：
- 每个悬而未决的问题当场记下责任人和期限，没有期限的问题等于没有问。
- 允许回答“不知道”，但要求转化为验证任务，验证结果回流到下一次评审。
- 评审记录归档，包括被否掉的方案和否掉的理由。
- 复盘时回看评审记录，把漏问的问题补进清单，清单本身也在迭代。
清单的生命力来自这个闭环：评审发现盲区，盲区变成任务，任务的结果又反过来修订清单。只把清单当模板填的团队，通常用不了两个版本就会放弃它。
常见误区
- 问题又大又空，回答者一句“考虑过了”就能带过，评审沦为确认仪式。
- 一份巨型清单贯穿所有阶段，评审变成两百条的打钩表演。
- 只问有没有方案，不问依据和数据，让估算伪装成结论。
- 不允许“不知道”，逼得所有人现场编答案，盲区反而被藏得更深。
- 问题没有责任人和期限，评审记录写完就没人再看。
- 清单一成不变，同类问题重复暴露却从不修订。
问题清单的本质，是把上一批人踩过的坑变成下一批人要回答的问题。它防不住所有事故，但能让“没想到”这三种字在方案阶段就现出原形，而不是在故障报告里才出现。
Used By
设计评审与上线评审的清单定制；评审机制设计（怎么不被敷衍）；新人带教（用问题清单传递工程判断）。
Related
关系链：问题质量 → 证据要求 → 阶段拆分 → 四类清单 → 评审机制。上游：retro/01（选型决策的评审面）。下游：retro/04（失败案例转清单）。
Reference
本页为工程经验归纳。