评审流程与安全氛围：允许说"不知道"的评审才安全

评审会上有人问"提交超时是不是已经扣款"——这不是细枝末节，而是成功语义与幂等的核心。本页定义评审的流程边界、角色分工、分歧处理与心理安全的真实含义。

材料先行，会议解决分歧

评审材料应尽早共享，使相关团队可以异步检查数据模型、接口、故障恢复、安全、容量和运维方案。会议用于解决分歧和未决风险，不应首次让评审者看到设计。评审角色要明确决策者、领域专家、运维、安全和数据负责人。谁批准不可逆数据迁移、谁值班、谁拥有回滚，都需落在真实职责上。

建设性评审质疑方案和证据，不评价个人能力。技术债务、约束与未决问题可以公开记录，避免团队为了显得完整而隐藏不确定性。

让评审发现问题，而非确认权威

提交者提前给题设、硬约束、候选和最薄弱证据；评审者分工看正确性、容量、运维和迁移。先独立读材料再讨论，减少最先发言者锚定。允许指出"不知道"和需要试验，不能把承认未知惩罚成能力不足，否则团队会掩盖最危险边界。

记录问题、依据和决定，区别必须阻止发布的关键错误与可延期的改进，避免所有问题同等级造成无限返工。

有界流程和分歧处理

30分钟可分为5分钟问题/变化、10分钟硬约束与失败、10分钟候选和证据、5分钟决定与行动。时间分配是练习约定，不是普遍标准；复杂高风险系统需更多独立验证。无法定夺的分歧转成最小实验及责任人，不用投票替代缺失事实。

方案A全部变更集中委员会，统一但易排队；方案B局部自治加风险触发评审，快但需契约和例外治理。按真实等待、漏检与事故复盘比较，不把审批数量当质量。

桌面练习与验收

给出一个漂亮但缺旧主隔离的多区图，评审必须找出分区时双写风险；再给一个简洁单区方案，允许它在满足当前硬约束时通过。评价是否尊重证据、能准确复述对方方案、是否形成可检验行动，而不是谁用了更多术语。

心理安全与工程责任同时存在：关键风险需明确主责和发布门槛，不能以"无责"解释为无人处理。运行事故后的组织原则参见无责复盘，本页将其用于评审氛围而非照搬所有流程。

评审发现分级与处置时限

本页讲了 30 分钟流程与分歧处理，但没有规定发现怎么分级。所有问题同等级会造成两种失败：小问题拖住发布，大问题被淹没。评审发现应分三级：阻断（不修复不能发布）、重要（限期内修复，可带风险发布）、次要（记录并排期）。

分级标准要可执行：阻断 = 违反硬约束（不变量、安全、恢复目标）或无法证明；重要 = 有量化风险但可缓解（如成本模型漏项、监控缺口）；次要 = 文档、命名、可读性。每条发现必须带责任人、处置动作与复验方式——复验方式可以是测试、演练或下一次评审的检查项，不能是"已知悉"。

反例：把"旧主切换时无 fencing"定为次要，理由是"发生概率低"。这违反硬约束（可能双写），必须是阻断；概率低不改变违反不变量的性质。另一个反例是把"图上标签过时"定为阻断，导致发布无限延期——它应记录并排期。

分级还要有时限：阻断项在发布前复验；重要项在约定日期前修复并复验；次要项进入技术债清单，随季度复查。没有时限的分级只是标签。

执行 python3 labs/review_models.py review_severity：预期输出三条发现（1 阻断、1 重要、1 次要）、阻断项列表与规则"只有阻断项停止发布，其余带责任人与复验方式"。脚本只做分级检查，不评价真实评审。

两个合理选择：A 所有发现一律阻断，安全但发布停滞；B 三级分级加时限与复验。本例选 B，并规定阻断项的判定必须引用具体硬约束条款，不能只写"风险高"。

架构师变化条件

高风险变更增加独立验证环节：评审从 30 分钟扩为"会前独立验证+会中决策"，验证耗时计入交付预算而不是变成隐性排队。跨时区团队用书面异步评审为主、会议只裁决分歧，记录需更完整。若评审发现相同错误反复出现，改进项是把该类检查固化为自动护栏（见架构治理与交付效能）。每次变化检查漏检率与等待时间是否同向改善。

闭卷验收

本页 8 道闭卷题收进了下方自测面板：先回忆，再展开参考答案与评分点，最后给三档自评。