决策与权衡综合实践：做一次可复盘的技术选型
TL;DR：本篇用一个完整案例串起全专栏方法——为消息队列选型做一次可复盘的技术选型。流程是：判断门类型 → 列选项与维度 → 决策矩阵权衡 → Premortem 识别风险 → 写 ADR 记录假设与退出条件 → 预设回退路径。最终产出是一页“技术选型决策记录”，让选型过程可被审阅、假设可被证伪、回退可被执行。判断选型是否合格，不看上线后是否“没问题”，看证据链是否闭合、退出条件是否预设。
概念解释
技术选型作为决策问题
技术选型（如选消息队列、数据库、框架）是软件工程最高频的决策类型。它的难点不在“哪个技术更好”，而在“在当前团队、业务约束、未来不确定性下哪个更合适”。一次选型本质是多目标决策：性能、可靠性、运维成本、团队熟悉度、生态成熟度、迁移难度等目标互相冲突，没有绝对最优。
本篇把前 4 篇的工具串成一个端到端流程，让选型从“开会拍板”变成“可复盘的工程决策”。它与系统思维专栏的 软件工程综合实践 和因果与证据专栏的 软件工程综合实践：验证一次改进是否有效 形成三段式：系统建模→因果验证→决策选择。
可复盘的含义
“可复盘”指选型决策留有足够的记录，使得：① 选错时能定位“哪个假设错了”；② 约束变化时能判断“是否该重选”；③ 新人能理解决策脉络。这要求选型过程产出三个可检查物：决策矩阵（权衡可见）、ADR（假设记录）、退出条件（信号与回退）。
目录
| 章节 | 说明 |
|---|---|
| 案例与系统边界 | 消息队列选型 |
| 串起全流程 | 从门判断到 ADR |
| 一页技术选型决策记录 | 可执行的模板 |
| 验收标准 | 怎样算选型合格 |
| 适用边界 | 本篇方法不替代什么 |
案例与系统边界
某团队订单服务的异步链路要引入消息队列，候选：Kafka、RocketMQ、RabbitMQ。朴素做法是开会凭印象选一个。按本专栏方法，先定系统边界：这个决策影响哪些范围？
| 边界 | 内容 |
|---|---|
| 目的 | 订单状态变更的异步通知（下游消费做库存、积分、通知） |
| 约束 | 峰值 5w QPS、不能丢消息、团队有 Java 但无 Kafka 运维经验 |
| 时间尺度 | 至少用 2 年，期间业务量预计增长 2-3 倍 |
| 利益相关者 | 订单团队（生产者）、下游 5 个消费团队、SRE（运维） |
目标不是“选最好的消息队列”，而是在可靠性、运维成本、团队学习曲线之间做可被审阅的取舍。
串起全流程
| 步骤 | 方法 | 产出 | 与其他步骤的关系 |
|---|---|---|---|
| ① 判断门类型 | 可逆性与双向门：降低决策的不可逆成本 | 单向门（引入后下游依赖形成，迁移极难） | 决定值得投入完整流程 |
| ② 列选项与维度 | 决策矩阵与权衡：在多目标下显式取舍 | 3 候选 × 5 维度矩阵 | 维度来自边界约束 |
| ③ 权衡与敏感性 | 决策矩阵 | 总分 + 敏感性分析 | 暴露真实权衡点 |
| ④ Premortem | Premortem 与预承诺：在行动前发现失败路径 | 失败原因清单 | 识别 ADR 的假设与退出条件 |
| ⑤ 写 ADR | 决策记录（ADR）：让技术决策可追溯可演进 | 决策记录（含假设、退出条件） | 凝结全部推理 |
| ⑥ 预设回退 | 双向门拆解 | 分阶段引入计划 | 降低不可逆成本 |
具体串联：门判断发现这是单向门（①），值得完整流程；列 3 个候选 × 5 维度矩阵（②），打分后发现 Kafka 与 RocketMQ 总分接近；敏感性分析（③）显示“运维成本”权重主导结果——本质是在“性能强但运维难”与“运维易但性能稍弱”间权衡；Premortem（④）识别“团队学不会 Kafka 运维导致故障”的高风险；据此设计预承诺“若一周内 Kafka 故障未能在 10 分钟自愈，切回原方案验证”；最终写入 ADR（⑤），并把引入拆成双写→灰度→切换的可逆步（⑥）。
一页技术选型决策记录
这是本专栏的最终交付物，一页纸，可照着执行与审阅：
| 字段 | 内容 |
|---|---|
| 决策问题 | 为订单异步链路选消息队列 |
| 门类型 | 单向门（下游依赖形成后迁移极难） |
| 候选 | Kafka / RocketMQ / RabbitMQ |
| 决策矩阵 | 5 维度加权：可靠性(0.3)、吞吐(0.25)、运维成本(0.2)、团队熟悉度(0.15)、生态(0.1) |
| 决策 | 选 RocketMQ（可靠性高、团队 Java 栈熟悉、运维成本可控） |
| 放弃了什么 | Kafka 的更高吞吐与更强生态；RabbitMQ 的更低学习曲线 |
| 假设（可证伪） | ① 业务量两年内不超 10w QPS；② 团队能在一个月内掌握 RocketMQ 运维；③ RocketMQ 社区持续活跃 |
| Premortem 风险 | 团队运维能力不足导致故障；消息积压未监控 |
| 退出条件（预承诺） | 若 QPS 超 10w 或一月内运维故障未自愈→评估迁移 Kafka；若消息积压超阈值未告警→补监控或换方案 |
| 回退设计 | 双写→影子流量→灰度切流→全量（每步可回退） |
| 复查点 | 上线 3 个月后复查假设①②③是否仍成立 |
这一页让未参与选型的人能复述推理、指出证据缺口、判断选型是否合理。它把“我们选了 RocketMQ”从结论升级为可复核的工程记录。
验收标准
选型是否合格，不看上线后是否"没问题"（那含运气），看四件事：
- 门类型已判断：明确这是单向门还是双向门，并据此分配了分析投入。
- 权衡可见：决策矩阵暴露了真实权衡点，而非总分掩盖了分歧。
- 假设可证伪：每个假设都能写出“若观察到 X，则假设不成立，需重选”。
- 退出条件预设：信号可观察、行动已预设、回退路径就绪。
满足这四条才算选型合格；只满足“上线了、没出问题”，仍属待复盘——因为没出问题可能是运气，下次约束变了就会暴露。
适用边界
- 本篇是整合方法，不替代任何单篇：跳过门判断直接做矩阵，可能把单向门当双向门草率处理。
- 小选型不必走完整流程：低风险可逆选型（如选内部工具库）用轻量判断即可，完整记录留给高影响或不可逆选型。
- 选型记录不保证选对：它让选错后能定向复盘，而非保证不选错。
- 外部效度有限：在本团队、本约束下的选型，不自动推广到其他团队，扩量前需重评。
- 选型受组织现实约束：技术禁用清单、采购流程、合规要求可能限制选项，这些约束要写进 ADR 上下文。
关联笔记
- 决策与权衡总览：从选项到可审阅的承诺（本专栏入口与三层结构）
- 决策记录（ADR）：让技术决策可追溯可演进（最终产出 ADR）
- 决策矩阵与权衡：在多目标下显式取舍（选型的权衡工具）
- 可逆性与双向门：降低决策的不可逆成本（判断选型的可逆性）
- Premortem 与预承诺：在行动前发现失败路径（选型的风险前置）
- 软件工程综合实践（系统思维专栏的端到端实践，本篇是其决策层延伸）
- 软件工程综合实践：验证一次改进是否有效（因果与证据专栏的综合实践，本篇与其衔接）
参考资料
- Architecture Decision Records — Michael Nygard
- Premortem: A Tool for Better Decision-Making — Gary Klein, HBR
- 2016 Letter to Shareholders — Jeff Bezos（单向门/双向门）
- Decision Matrix Method — Wikipedia（Pugh 矩阵）
- Accelerate — DORA（软件交付与决策能力的关系）
- 《超预测》（原著 Superforecasting）— Philip E. Tetlock & Dan Gardner（好决策 vs 好运气）
评论 (0)