架构演进决策能力
# 02.架构演进决策能力
# 目录介绍
- 1. 案例引入
- 2. 演进决策全景图
- 3. 渐进演进四原则
- 4. 可逆与不可逆
- 5. Trade-off 量化
- 6. 敢不做也是决策
- 7. 演进节奏拆分
- 8. 演进决策反模式
- 9. 决策沟通策略
- 10. 综合案例串讲
# 1. 案例引入
# 1.1 老板的顺便重构
张伟的支付方案通过了，团队 3 人 3 个月，正式启动。第二周周会上，老板 A 总突然发话：
A 总: "小张, 我看你这次支付重构做得不错。既然都要动订单系统了,
咱们顺便把订单、库存、履约也一起微服务化吧?"
张伟: (心里咯噔) "呃, 这个......"
A 总: "反正都要改, 一次改到位, 别一年后又来一遍。你想想,
Netflix、蚂蚁不都是这么干的?"
张伟: "但我们方案里只承诺了支付重构 3 个月......"
A 总: "方案可以调嘛。你回去评估一下, 一次性做到位需要多久?
顺便把技术债都还了。"
张伟: (被架起来) "好, 我评估一下。"
回到工位，张伟越想越不对劲：
支付重构 3 个月 (方案已过, 团队已备)
订单拆分 保守估计 4 个月 (200 张表要拆)
库存拆分 3 个月 (要处理分布式事务)
履约拆分 2 个月 (跟外部物流对接)
如果串行: 12 个月, 团队规模需要翻倍
如果并行: 6 个月, 但依赖交织, 上线风险爆炸
一周后张伟硬着头皮做出评估："顺便"意味着 6-12 个月，风险不可控。他把评估发给 A 总，A 总回一句："别怕难，去做"。
张伟慌了：做，明知道会翻车；不做，会不会显得没担当？
# 1.2 顺藤摸到根因
带着这条线往下挖：
- 假设 1：A 总的想法有没有道理？——有一定道理，技术债确实存在
- 假设 2：那就该"顺便"做吗？——不是，因为风险 × 成本 ≠ 收益
- 假设 3：为什么老板会有这种诉求？——因为架构决策的成本不由老板扛
- 假设 4：那张伟应该怎么办？——不是"扛住老板"，而是帮老板算清楚账
- 假设 5：算账的语言是什么？——决策的量化框架
- 假设 6：如果算完 A 总还是要做呢？——那也不是张伟单挑，而是让 A 总承担明确风险
- 假设 7：这些语言、框架、姿势是什么？——本篇的主线
仔细分析这次危机的根因：
表象 真实问题
────────────────────────────────────────────────────
"既然要改, 顺便..." → 顺便主义, 不区分决策独立性
"一次改到位" → 大爆炸, 不区分可逆/不可逆
"别一年后又来一遍" → 恐惧驱动, 不算成本折现
"我评估一下" → 张伟没有决策语言
"别怕难, 去做" → 没有让上级承担明确风险
根因：张伟没有"架构演进的决策语言"——他只会说"能做/不能做"，不会说"这么做代价是什么、比另一种代价高多少、谁来承担、可不可回滚"。
这一段里至少藏着 8 个原理点：
① 什么是"演进"?为什么不是"重构"? → 第 2 章
② 渐进和一次到位, 到底哪个更好?怎么选? → 第 3 章
③ 决策的可逆性怎么判断?为什么可逆比不可逆便宜 10 倍? → 第 4 章
④ "顺便一起做"到底伤在哪? → 第 4 章
⑤ Trade-off 怎么量化才能跟老板对话? → 第 5 章
⑥ 什么情况下"不做"才是最优决策? → 第 6 章
⑦ 演进的节奏怎么拆才不翻车? → 第 7 章
⑧ 面对老板压力怎么"体面地说不"? → 第 9 章
# 1.3 我们要回答什么
这个事故就是本篇的主线案例。带着上面 8 个问号往下走。
本篇路线：
决策全景图 (第 2 章)
↓
渐进演进四原则 (第 3 章) ─→ 解开"为什么小步好过大爆炸"
↓
可逆与不可逆 (第 4 章) ─→ 解开"哪些决策慎之又慎"
↓
Trade-off 量化 (第 5 章) ─→ 解开"跟老板怎么算账"
↓
敢不做也是决策 (第 6 章) ─→ 解开"什么时候拒绝"
↓
演进节奏拆分 (第 7 章) ─→ 解开"必须做怎么做"
↓
反模式 (第 8 章) + 沟通策略 (第 9 章)
↓
综合案例 (第 10 章) ─→ 张伟顶住 A 总
📌 本篇定位：这是继"方案设计力"之后的决策力升级。方案回答"做什么"，决策回答"要不要做/什么时候做/一次做多少"。能顶住"顺便一起做"的诱惑，是资深工程师的第一个分水岭。
# 2. 演进决策全景图
# 2.1 决策五要素
一次架构演进决策，包含五个要素。缺一个都会出问题：
┌────────────────────────────────────────────────────────────┐
│ 架构演进决策五要素 │
├────────────────────────────────────────────────────────────┤
│ │
│ ① 时机 (When) │
│ 现在做 / 半年后做 / 不做 │
│ │ │
│ ▼ │
│ ② 幅度 (How much) │
│ 全做 / 一部分做 / 试点做 │
│ │ │
│ ▼ │
│ ③ 可逆性 (Reversibility) │
│ Type1 不可逆 vs Type2 可逆 │
│ │ │
│ ▼ │
│ ④ 成本收益 (Trade-off) │
│ 人力/时间/风险 vs 收益/折现 │
│ │ │
│ ▼ │
│ ⑤ 责任归属 (Accountability) │
│ 谁拍板, 谁承担, 谁复盘 │
│ │
└────────────────────────────────────────────────────────────┘
五要素属性速查：
| 要素 | 关键问题 | 输出 | 张伟 V1 |
|---|---|---|---|
| 时机 | 现在最迫切吗？ | 优先级排序 | 全都现在 ❌ |
| 幅度 | 一次做多大？ | 里程碑拆分 | 全都做 ❌ |
| 可逆性 | 做错能回吗？ | Type 分类 | 没分类 ❌ |
| Trade-off | 值不值？ | 量化对比 | 没算 ❌ |
| 责任 | 谁拍谁扛？ | 决策记录 | 张伟一人扛 ❌ |
# 2.2 为什么这么切
疑惑：架构演进不就是"要做就好好做"吗？为什么要拆成五要素？
论证：
没时机决策就没优先级——所有需求都紧迫 = 没需求紧迫。张伟的 4 个改造都"应该做"，但按优先级只有支付真正 P0。不排优先级 = 每个都做不完。
没幅度决策就是赌——"全做"和"做 20%"的风险不是线性的，是指数的。大爆炸重构翻车概率 = 单个改造翻车概率 ^ 项目数。张伟 4 个改造，单个翻车 20%，全做翻车 (1-0.8^4)=59%。
没可逆性区分就要命——微服务拆分是 Type1 不可逆——一旦拆了几乎回不去。跟"换 Redis 客户端库" (Type2 可逆) 完全不是一个决策级别。Type1 决策要 10 倍谨慎。
没量化 Trade-off 就跟老板对不上话——老板说"顺便"是感性，你说"6-12 个月风险不可控"是感性。量化 = 语言 = 决策力。
没责任归属就没人认真——张伟一人扛 = 出问题只有他挨骂 = 老板下次继续"顺便"。责任归属清晰 = 决策成本对上决策收益。
反向验证：没这五要素会怎样？答案就是第 1 章——张伟被架起来做 4 个改造，一场大爆炸的种子被埋下。
结论：五要素的本质是把"架构演进"从热血冲锋变成冷静工程——时机排优先、幅度控风险、可逆定谨慎度、Trade-off 建共识、责任对齐奖惩。少一环都是赌。
# 3. 渐进演进四原则
# 3.1 小步快跑
疑惑：为什么小步比大步好？我一次做完不是省事？
论证：算一笔账：
方案 A: 一次拆 4 个服务
周期: 6 个月并行
上线: 一次性大发布
发现问题: 6 个月后
回滚代价: 数据已迁, 代码已删, 几乎不可回
单点风险: 一处翻车全盘皆输
方案 B: 半年拆 1 个 (支付先做, 剩下 3 个逐个跟)
周期: 支付 3 个月 + 单个 3 个月 × 3 = 12 个月串行, 但重叠可缩到 9 个月
上线: 每个独立灰度
发现问题: 3 个月内
回滚代价: 单个可控
单点风险: 隔离
表面周期: A 短 3 个月
真实周期: A 有 60% 概率翻车拖到 12 个月, 期望 = 6 × 0.4 + 12 × 0.6 = 9.6 月
B 稳定 9 个月
结论：期望周期 A ≈ B，但 A 有 60% 概率翻车、B 稳定 9 个月。选 B。
小步快跑的量化定义：
一步的"合适大小" =
可以在一个 sprint (2 周) 内完成、
可以独立上线、
出问题可以在 1 天内回滚。
# 3.2 一次改一件
疑惑：改支付时不能顺手改一下订单接口吗？
论证：不能。原因是变量隔离：
一次只改 A:
出问题 → 一定是 A → 排查 10 分钟
一次改 A+B:
出问题 → 可能是 A、B、或 A/B 交互 → 排查 3 小时+
一次改 A+B+C:
出问题 → 排查回天乏术, 只能整体回滚
结论：一次改一件 = 排障成本恒定。多改一件 = 排障成本翻倍。
例外：如果两件事逻辑绑定（如接口签名变了必须同步升级调用方），才是一次改一件"逻辑上的一件"。
# 3.3 保留退路
疑惑：什么叫保留退路？
论证：每一步演进都要有对应的"撤退键"：
演进动作 退路
────────────────────────────────────────────
新增支付通道 (加代码) Feature Flag 关闭
存量数据迁移新表 双写, 保留老表读
接口拆到新服务 网关灰度回切老服务
数据库拆库 保留同步链路 30 天
删除老服务 留 30 天备份 + 部署包
结论：没有退路的决策叫赌博，有退路的决策叫工程。
极端案例：删除老代码——很多人以为"完成收尾"，其实这是最不可逆的动作。老代码删了，40 天后发现新代码有边界 bug，回天乏术。规矩：老代码在新代码全量后再等 30 天再删。
# 3.4 承担明确风险
疑惑：老板说"你干"，我就干呗，风险是老板扛的吧？
论证：不是。风险的默认归属：
默认归属: 技术方案的翻车, 由技术负责人扛
特殊归属: 被上级明确要求"必须做"的翻车, 上级扛
关键动作: 你必须"明确"这个"必须做"
不明确的后果:
张伟: "我评估一下" (未明确风险)
A 总: "别怕难, 去做"
上线翻车: 张伟被追责
明确后的后果:
张伟: "评估如下, 期望翻车概率 60%, 建议不做。
如果要做, 请书面确认由技术委员会背书。"
A 总: (要么放弃, 要么书面背书)
上线翻车: A 总或技术委员会扛
结论：承担明确风险 ≠ 甩锅，而是让决策成本对上决策权力。老板要做，就让他明知代价。
# 4. 可逆与不可逆
# 4.1 决策的可逆度
疑惑：什么叫可逆？我做完了都能改吧？
论证：能改 ≠ 能低成本改。看几个例子：
决策 可逆度 改动代价
─────────────────────────────────────────────
换缓存 Key 前缀 极高 5 分钟
换 HTTP 客户端库 高 1 天
换 ORM 框架 中 2 周
拆分微服务 低 3-6 月
换数据库 (MySQL→Postgres) 极低 6-12 月
上市 零 几乎不可
结论：可逆度是梯度，不是二元。决策的谨慎程度应该与可逆度成反比。
# 4.2 Type1 与 Type2
贝索斯的分类（简化版）：
Type1 决策 (不可逆):
- 影响面大、代价高、几乎回不去
- 例: 微服务拆分、更换数据库、组织架构调整
- 处理: 慢决策, 收集尽可能多信息
Type2 决策 (可逆):
- 局部、可撤、回滚便宜
- 例: 接口重命名、加一个字段、改个配置
- 处理: 快决策, 试错成本低
关键洞察：大多数人把 Type2 当 Type1 决策（开一大堆会），把 Type1 当 Type2 决策（拍脑袋就干）。两个错误一样严重。
对照 A 总的诉求：
A 总: "顺便微服务化吧"
性质: 4 个 Type1 决策同时启动
处理: 应该收集 6-12 个月信息, 而不是"顺便"
# 4.3 决策优先级矩阵
四象限图：
可逆度
▲
高 │ 低
┌──────────────┼──────────────┐
│ │ │
高 │ Type2 高频 │ Type1 关键 │
收益│ 快速试错 │ 慎重决策 │
│ (加缓存) │ (拆微服务) │
│ │ │
├──────────────┼──────────────┤
│ │ │
低 │ Type2 低频 │ Type1 无意义 │
收益│ 可做可不做 │ 别碰 │
│ │ │
└──────────────┴──────────────┘
(换 DB 但没痛点)
决策口诀：Type1 高收益慢决策、Type2 高收益快决策、Type1 低收益不做。
回头看 A 总的诉求：4 个改造中，只有支付是"Type1 高收益"，其他 3 个都是"Type1 中收益"——应该慢决策，不该"顺便"。
# 5. Trade-off 量化
# 5.1 三轴决策图
疑惑：怎么把"值不值"讲给老板听？
论证：用三轴决策图——时间、风险、收益：
收益
▲
│
│ ┌─────┐ ★理想区
│ │ 支付 │
│ └─────┘
│
│ ┌──────┐
│ │ 订单 │ 中等区
│ └──────┘
│
│ ┌──────┐
│ │ 履约 │ 不划算区
│ └──────┘
│
└──────────────────────────→
低 时间×风险 高
坐标定义：
X 轴 (时间×风险): 完成所需人月 × 翻车概率
Y 轴 (收益): 3 年内累积业务/技术价值
决策规则：Y/X 比值最高的做，其他等下一个决策窗口。
举例（数字为示意）：
| 项目 | 人月 | 翻车概率 | X = 时间×风险 | 3 年收益 | Y/X |
|---|---|---|---|---|---|
| 支付重构 | 9 | 15% | 10.4 | 500 万 | 48 |
| 订单拆分 | 20 | 40% | 28 | 400 万 | 14 |
| 库存拆分 | 15 | 45% | 21.8 | 300 万 | 14 |
| 履约拆分 | 10 | 50% | 15 | 200 万 | 13 |
结论：支付 Y/X = 48，是订单的 3 倍。四个项目全做 = 稀释支付这个高 ROI 项目。
# 5.2 成本估算法
疑惑：怎么估人月和翻车概率？
论证：三点估算法：
乐观估计 (最顺): O
最可能估计: M
悲观估计 (翻车): P
期望人月 = (O + 4M + P) / 6
标准差 = (P - O) / 6
翻车概率 ≈ 标准差 / 期望人月
举例（订单拆分）：
O = 12 人月 (什么都顺利)
M = 20 人月 (常规)
P = 40 人月 (中大等级翻车)
期望 = (12 + 80 + 40) / 6 = 22 人月
标准差 = (40 - 12) / 6 = 4.7
翻车概率(粗略) = 4.7 / 22 ≈ 21% → 保守取 40%
结论：估算不是精确, 是把"我觉得"变成"我的量化直觉"。
# 5.3 收益折现法
疑惑：3 年 500 万收益怎么算？
论证：未来的钱不如现在的钱值钱，要折现：
折现率 (r) 一般取 15%-25% (软件行业风险高)
现值 (NPV) = 收益₁/(1+r)^1 + 收益₂/(1+r)^2 + 收益₃/(1+r)^3
举例 (r=20%):
年 1 收益 200 万 → 现值 167 万
年 2 收益 200 万 → 现值 139 万
年 3 收益 100 万 → 现值 58 万
NPV 合计 = 364 万 (而不是 500 万)
结论：长远收益要打折——这就是为什么老板"3 年 500 万"要按 NPV 算 = 别被大数字忽悠。
# 6. 敢不做也是决策
# 6.1 不做的三种情形
疑惑：什么时候"不做"是最优？
论证：三种典型情形：
① 边际收益递减:
已经做了 80%, 剩下 20% 成本占 60%, 收益占 10%
→ 停
② 决策窗口未到:
信息不足, 现在决策错误概率高
→ 等 (但明确"等到什么信号")
③ 机会成本更高:
同样资源投别处收益 3 倍
→ 转向
对照 A 总诉求：
订单/库存/履约 拆分:
边际收益递减? 否
决策窗口未到? 是, 支付都还没验证
机会成本更高? 是, 支付 ROI 是它们 3 倍
→ 结论: 不做 (现在)
# 6.2 拒绝的表达法
疑惑：直接跟老板说"不做"？会不会被认为没担当？
论证：拒绝有姿势。错误姿势：
❌ 硬顶: "这不可能, 太难了"
❌ 甩锅: "这是 A 总您的意思, 我做不了主"
❌ 拖延: "我评估一下" (然后无限期评估)
❌ 妥协: "好吧我试试" (然后翻车)
正确姿势 (三段式)：
① 承认价值 "顺便一起做的目标我完全认同"
② 摆出数据 "但按 NPV 折现算, 支付 Y/X 是订单的 3 倍,
全做 = 稀释支付, 期望翻车 60%"
③ 给出选项 "所以有三种路径:
A. 只做支付 (推荐), 支付完再评估
B. 支付 + 订单 (次推荐), 但周期延长 3 月
C. 全做, 需要团队翻倍 + 明确风险背书
请您选择"
关键：给出选项而不是给出拒绝。老板要的是决策权，你要的是决策依据。
# 6.3 让子弹飞一会
疑惑：如果老板还是要"顺便"呢？
论证：技术决策不是最后一刻拍板——争取一个决策窗口：
拖字诀 (正当版):
"A 总, 支付重构 3 个月后完成, 我们能拿到一个关键数据:
微服务的运维成本、开发效率、故障率。
带着这些数据再决策订单要不要拆, 决策质量会高 10 倍。
现在决策, 我们缺关键信息。"
心理原理:
老板要的是"事情往前走"
你给的是"事情往前走 + 决策会更准"
→ 双赢
结论：让子弹飞 = 用"决策质量"换"决策时机"。这不是拖延，是决策成熟度。
# 7. 演进节奏拆分
# 7.1 里程碑拆法
疑惑：假设支付重构必须做，怎么拆里程碑才不翻车？
论证：拆分原则：每个里程碑独立上线、独立回滚、独立验收。
支付重构 3 个月拆法：
M1 (Week 1-3): 网关框架 + 单个新渠道接入 (Stripe)
独立上线: ✅ (新流量走新网关, 老流量继续走)
独立回滚: ✅ (关 Feature Flag)
验收: 5% 灰度 Stripe 支付成功率 > 99%
M2 (Week 4-6): 老渠道 Alipay/WeChatPay 迁入网关
独立上线: ✅
独立回滚: ✅ (切回老代码)
验收: 30% 灰度, 老渠道成功率不劣化
M3 (Week 7-9): 剩余渠道接入 (PayPal/Union)
独立上线: ✅
独立回滚: ✅
验收: 全渠道 60% 灰度
M4 (Week 10-12): 全量 + 老代码下线
独立上线: ✅
独立回滚: ✅ (回滚窗口 30 天)
验收: 100% 全量运行 30 天无异常
结论：4 个里程碑，每 3 周一个节奏——每一个都是"完整的胜利"，翻车最多回退到上一个里程碑。
# 7.2 依赖排序
疑惑：怎么决定里程碑的顺序？
论证：按"技术依赖 + 业务价值 + 风险验证"三重排序：
① 技术依赖: A 依赖 B, B 必须先做
② 业务价值: 高价值先做 (提前验证 ROI)
③ 风险验证: 高风险先做 (提前暴露问题)
支付重构里的应用：
M1 先做 Stripe:
技术依赖: Stripe 是新渠道, 可独立
业务价值: 海外业务 Q3 上线, 最急
风险验证: Stripe 网络最不确定, 早验早稳
M2 才做老渠道迁移:
技术依赖: 网关框架已经过 Stripe 验证
业务价值: 老渠道流量大, 但已有稳态
风险验证: 迁老渠道风险是"切换风险", M1 已扫清框架风险
结论："新且不重要"的最先做——用最低成本验证框架。这是 Netflix、亚马逊的默认做法。
# 7.3 每步都能上线
疑惑：里程碑必须都能上线吗？做一半的成果不能留着？
论证：做一半的代码 = 技术债 = 后续必然翻车：
❌ 里程碑不上线:
M1: 网关框架 (代码 4000 行, 未上线)
M2: Stripe 接入 (基于 M1, 未上线)
M3: 全量迁老渠道 (基于 M2, 未上线)
M4: 大爆炸一次上线
风险:
M1-M3 的代码 3 个月没在生产跑, bug 累积
M4 上线 = 12000 行新代码同时接管流量
翻车必然
正确做法：Feature Flag + 灰度——即使功能没做完，代码也在生产运行（关着）。上线不等于放量。
结论："每一步都能上线"是渐进演进的底线。做了不上 = 大爆炸的前奏。
# 8. 演进决策反模式
# 8.1 大爆炸重构
症状：一次性推翻旧架构，全新写。
危害：翻车概率高（多个变量同时变）、周期不可控、无法回滚。
修复：绞杀者模式 (Strangler Fig)——新旧共存，逐步替换。
# 8.2 顺便主义
症状："既然都改了，顺便把 X 也改了吧"。
危害：每次"顺便"都是一次未评估的 Type1 决策，风险叠加。
修复：一次改一件——顺便的诱惑，一律先算 Y/X 再决定。
# 8.3 技术洁癖
症状："这段老代码太丑了，我不忍受，重写！"
危害：丑但稳 > 美但险。老代码活了 5 年 = 已经踩过 5 年的坑。
修复：修一处 = 一处收益，别追求整体美观。
# 8.4 过度设计
症状：为一年后"可能"的需求做架构。
危害：为不确定的未来付出确定的现在。
修复：YAGNI (You Aren't Gonna Need It)——今天的需求满足，未来的需求未来再说。留扩展点（接口、抽象），但别提前实现。
# 8.5 只做不停
症状：架构演进一直在做，从不复盘"要不要继续"。
危害：沉没成本谬误——为了不浪费已投入的，继续投入更多。
修复：每个里程碑结束都要做 GO/NO-GO 复盘——继续、暂停、终止 三选一。
# 9. 决策沟通策略
# 9.1 向上说不的姿势
疑惑：向老板说"不"是不是很危险？
论证：说不的核心是"帮他做出更好的决策"——他的诉求你没否，你只是给了更好的路径。
三个姿势：
姿势 1 - 数据说话:
"按 NPV 折现算, 全做的期望 ROI 是 X, 只做支付的期望 ROI 是 3X。
建议先做支付。"
姿势 2 - 风险摊开:
"全做的翻车概率是 60%, 翻车后损失预计 500 万。
您愿意承担这个风险吗?"
姿势 3 - 选项摊开:
"有三种路径, 我推荐 A, 但决策权在您。
请您选择, 我会全力执行。"
结论："说不"不是对抗，是共谋更好的决策。
# 9.2 用数据代替嘴硬
疑惑：老板不相信我的数据怎么办？
论证：准备三层数据支撑：
① 内部经验数据:
"我们上次拆用户中心, 计划 3 月, 实际 6 月, 翻车概率 33%"
② 行业标杆数据:
"Netflix 微服务拆分平均 18 月, Uber 微服务改造 24 月"
③ 反例警示数据:
"Segment 从微服务回退到单体, Amazon Prime Video 从微服务回退到单体"
结论：内部数据 + 外部标杆 + 反例 = 无法被"你太保守"反驳的组合拳。
# 9.3 让对方选择
疑惑：为什么要让老板选，不能直接告诉他答案吗？
论证：选择权 = 尊严 = 支持。
❌ 独裁式:
"我们只做支付, 其他都不做"
老板感受: 你在挑战我的决策权
✅ 引导式:
"有 A/B/C 三个选项, 我建议 A, 但请您拍板"
老板感受: 我在决策, 你在辅助 → 他会更认真看数据 → 更可能选 A
结论：让老板选择 = 你赢。你的目标不是"我说了算"，是"最终决策是正确的"。
# 10. 综合案例串讲
# 10.1 张伟顶住老板
回到张伟。他花了 2 天做完量化分析，然后约 A 总 1v1：
张伟: "A 总, 关于'顺便微服务化'的评估, 我想跟您对一下数据。"
A 总: "行, 说吧。"
张伟: "我用 NPV 折现算了四个项目的 3 年 ROI:
支付重构: Y/X = 48
订单拆分: Y/X = 14
库存拆分: Y/X = 14
履约拆分: Y/X = 13
支付的 ROI 是其他三个的 3 倍。"
A 总: "嗯, 数字挺清晰。"
张伟: "如果四个全做, 期望周期从支付的 9 个月变成 18-24 个月,
翻车概率从 15% 升到 60%。
翻车成本估算: 300-500 万。
所以我准备了三个方案:
方案 A (强烈推荐): 只做支付
- 3 个月, 团队 3 人
- 完成后评估订单/库存要不要拆
- Q3 海外业务如期上线
方案 B (次选): 支付 + 订单
- 6 个月, 团队 5 人
- 需要多 200 万预算
- Q3 海外业务上线延期 2 周
方案 C (最激进): 全做
- 18-24 个月, 团队 10 人
- 翻车概率 60%, 需要技术委员会背书
- Q3 海外业务上线延期 6 个月+
请您拍板。"
A 总: (看了 30 秒数据) "......行, 就 A 方案。等支付跑稳了,
Q4 再启动订单。"
关键动作复盘：
① 张伟没有"硬顶", 用数据说话
② 三个方案给了 A 总"决策权"
③ 明确"如果要激进方案, 需要技术委员会背书"——把责任摊开
④ 每个方案都有 GO 后果和 NO-GO 后果
⑤ 结果: A 总选了张伟推荐的方案, 并且是他自己选的
# 10.2 一次成功演进
方案 A 落地后，张伟严格按照本篇原则执行：
M1 (Week 1-3): 网关 + Stripe
✅ 5% 灰度成功率 99.2%
✅ 老代码 0 改动
M2 (Week 4-6): 老渠道迁移
⚠️ 灰度 30% 时发现 WeChat 回调签名兼容问题
✅ Feature Flag 关闭, 5 分钟回到老代码
✅ 修复后重新放量
M3 (Week 7-9): PayPal/Union
✅ Stripe 经验复用, 顺利
M4 (Week 10-12): 全量 + 老代码保留 30 天
✅ 全量运行 30 天 0 事故
✅ Day 42 老代码下线
总耗时: 计划 12 周, 实际 13 周 (含 M2 的 1 周回滚重来)
翻车指标: 灰度阶段 1 次可控回滚, 生产 0 事故
业务成果: Q3 海外业务如期上线, 3 个月内新增 3 个渠道
M2 那次回滚成为团队的经典案例——因为有 Feature Flag，一次可能酿成 P0 事故的兼容问题被 5 分钟化解。团队从此把"Feature Flag + 灰度"写进研发规范。
# 10.3 决策哲学回扣
回望张伟这次决策过程，架构演进决策能力的本质是：
初级: 被诉求驱动 (老板要啥做啥)
中级: 会评估成本 (敢说"这个太贵")
高级: 会算 Trade-off (用数据讲清楚 ROI)
资深: 会保留可逆性 (即使做, 也留退路)
大师: 敢让子弹飞 (敢说"现在信息不足, 3 月后再决定")
演进决策的四个心法：
① "现在做" 不等于 "现在做完" → 拆里程碑
② "都要做" 不等于 "一起做" → 排优先级
③ "老板要" 不等于 "你扛" → 明确风险
④ "做" 有时不如 "先不做" → 让子弹飞
结论：架构演进决策能力 = 帮组织在不确定性中做出最好的一步——不是最激进、不是最保守，是当前信息下最合理。
# 10.4 演进决策速查
演进决策速查表：
| 场景 | 动作 |
|---|---|
| 老板说"顺便做" | 先算 Y/X，用三方案回应 |
| 拆微服务 | Type1 决策，慢决策，收集尽可能多信息 |
| 加缓存/换库 | Type2 决策，快决策，试错成本低 |
| 一次改多件 | 拆开，一次改一件 |
| 大爆炸重构 | 拒绝，改用绞杀者模式 |
| 老代码丑但稳 | 别碰，改增量重构 |
| 已投入很多想收手 | GO/NO-GO 复盘，别陷入沉没成本 |
| 未来可能用到 | YAGNI，只留扩展点不实现 |
| 上级坚持做 | 让子弹飞 or 要求书面背书 |
| 说服上级 | 数据 + 选项 + 决策权在他 |
三轴决策图：
决策时思考:
X 轴: 时间 × 风险 (成本)
Y 轴: NPV 折现后收益
Z 轴: 可逆度 (Type1/Type2)
Y/X 高 + Type2 → 立刻做
Y/X 高 + Type1 → 慢决策做
Y/X 低 + Type2 → 有空做
Y/X 低 + Type1 → 别碰
下一集预告：张伟支付项目大获成功。M3 阶段部门要拉一场技术方案讨论——是自研 API 网关还是买商业方案？会议室里同事 B 声音大、逻辑却混乱，把讨论带偏了两小时。张伟想插话却被打断三次。**第 03 篇《技术讨论表达能力》**告诉他"结构化压过嗓门大"。
本篇速查表：
| 领域 | 核心工具 |
|---|---|
| 决策语言 | 五要素、三轴决策图、NPV 折现 |
| 演进原则 | 小步、一次一件、留退路、明确风险 |
| 可逆分类 | Type1 慢决策 / Type2 快决策 |
| 拒绝姿势 | 承认价值 + 数据 + 三方案 |
| 里程碑 | 独立上线 / 独立回滚 / 独立验收 |
| 反模式 | 大爆炸/顺便/洁癖/过度/只做不停 |
| 沟通策略 | 数据说话 + 让老板选择 |
