技术选型的「3 年视角」：你们团队到底用「当前够用」还是「3 年不重构」做标准？冲突时谁赢？

【背景】

做了 15 年技术产品，见过两种极端，都栽过跟头：

• 某次大促前，团队用「当前 5 万 QPS 够用」为由选了单机 Redis，结果半年后业务翻 10 倍，迁移集群版花了 3 周，期间线上出了 2 次缓存雪崩。
• 另一次，一个内部工具为了「架构先进」上了 K8s + Service Mesh + gRPC，团队 5 个人，运维成本直接吃掉 40% 开发时间，工具本身反而没人维护了。

两个故事都指向同一个问题：技术选型时，「够用」和「不重构」到底谁说了算？

【我踩过的坑 / 常见分歧】

我发现团队里通常存在两种隐含假设，而且很少被显性讨论：

1. 「够用派」：当前业务规模 + 1 个数量级的增长空间，够 12–18 个月就行，剩下的交给技术债预算。代表话术：「先跑起来再说，真不够了再换。」
2. 「架构派」：选型就要撑 3 年，否则「重构成本是选型成本的 5–10 倍」。代表话术：「这个框架 3 年后社区肯定没人维护了，不能选。」

我的经验是：两派都错在对「3 年」的定义上。 3 年对核心交易链路和 3 年对一个内部运营后台，含义完全不同。但很少有人把「这条链路的 3 年」和「那个工具页的 3 年」分开算。

【我的倾向：用「变更半径」而非「时间」做标准】

我后来在团队里推了一个简单的决策框架（不完美，但比「拍脑袋」强）：

| 维度 | 问自己什么 | 怎么影响选型 | |---|---|---| | 变更半径 | 换掉这个组件，要动几个服务、几条数据管道、几个团队？ | 半径 ≥ 3 个团队 → 倾向「3 年不重构」；半径 ≤ 1 个服务 → 「够用就行」 | | 数据迁移成本 | 换掉后数据能不能直接迁？还是要做格式转换 / 双跑？ | 有不可逆数据格式 → 提前留升级路径 | | 团队规模 | 维护这个组件需要几个人？ | 团队 ≤ 5 人 → 优先选「运维成本低」的，哪怕性能差一档 | | 替换窗口 | 能不能在业务低峰期做 2 周灰度切换？ | 不能（如金融结算）→ 必须选「3 年稳」的 |

关键原则：不是所有东西都值得「3 年视角」，也不是所有东西都「够用就行」。变更半径越大、数据越不可逆、团队越小，越该往「3 年」靠；反之亦然。

【想听大家在什么场景下怎么选】

特别想收集几类真实案例：

1. 你们团队有没有一个显性的选型决策标准（文档 / 评审 checklist / 决策记录）？还是每次都是架构师拍板？
2. 有没有「当初选了 3 年架构，结果 1 年就业务方向变了，白搭」的案例？反过来「当初够用就行，结果 6 个月就撑不住」的案例？
3. 当「3 年视角」和「本季度交付 deadline」冲突时，你们的 PM / 技术负责人怎么仲裁？有没有一个可复用的仲裁规则？
4. 对于内部工具 / 脚手架（不是核心链路），你们有没有一个「降级选型」的底线？比如「内部工具可以不用 K8s，但日志必须能查」这类规则？

欢迎拍砖，也欢迎贴你们团队的选型决策文档（脱敏后）——我特别好奇不同规模团队的「够用线」到底差多少。