ADR 评审流程
一个轻量门控，让 ADR 得到真正的技术审视，而非橡皮图章。
为什么
没人评审的 ADR 只是一个人 checked into git 的意见。ADR 的价值来自对决策的集体压力测试：我们考虑过失败模式吗？这和现有 ADR 冲突吗？后果对值班团队能接受吗？定义好的评审流程能抓住局部最优但全局不一致的决策。没有它，你会得到 40 条各自看着没问题、但互相矛盾（比如一致性模型）的 ADR。
何时使用
每条 Proposed ADR 在变成 Accepted 之前。预算每次 30 分钟，每周 1-2 次评审。仅对琐碎、完全可逆的决策可跳过。
如何做
1. 作者设 Status=Proposed 并请求 2 名指定评审人： - 一名直属团队外的高级工程师（横切视角） - 一名值班/运维代表（后果落在他们头上） 2. 评审人在 PR 评论里检查： - 备选方案和否决理由是否真实？ - 是否和任何现有 Accepted ADR 冲突？（grep docs/adr） - 负面后果是否被承认且可接受？ 3. 作者处理评论；评审人留明确的 "LGTM" 评论 4. 2 个批准后作者把 Status 改为 Accepted；合并 PR 5. 在每周架构同步会上记一行决策（带 ADR 链接）
示例
ADR-0013（Proposed）："服务间消息采用 Kafka" 评审人：@diana（平台）、@carlos（值班） @diana："Context 没提 ADR-0009 我们选了 RabbitMQ。 为什么换？另外：谁运维 Kafka 集群？" @carlos："负面后果漏了告警负载——Kafka 再均衡会让消费者卡 30 秒， 那是值班事故。" 作者更新 Context（链接 ADR-0009、解释吞吐变化）， 加后 果"- 再均衡期间值班可能遇到 30 秒消费者卡顿"。 两人 LGTM → Accepted。
常见问题
- ⚠每次都指派同样两名评审人——他们变成瓶颈且失去新鲜视角；每季度轮换横切评审人。
- ⚠只评审 Decision 句而不评审 Consequences——后果是运维痛点所在，跳过它必致未来事故。
最佳实践
- ✓在 CI 里持续跑"ADR 冲突"检查，grep 矛盾决策（如两条 ADR 选了不同主存储）。
- ✓评审限时 30 分钟；如果需要更多，说明决策太大，应拆成多条 ADR。
- ✓把 Accepted 的 ADR 发到内部 wiki，让非工程师（产品、安全）能看到架构理由。