技术决策

很多时候讨论方案，“这个改起来简单”，然后就没有人说话了。简单没有错，问题是简单就是指这一次改动的简单呢？那运维的简单性、扩展的简单性、稳定的简单性、排查的简单性呢？ 现象 很多时候讨论方案，“这个改起来简单”，然后就没有人说话了。 因为这东西真有点无从反驳。 改起来简单，风险就低，你怎么反驳，又不是你改，又不是你背锅。 包括网络上有一些图，基本表达是"能跑就别动"。 但是这玩意真的对吗？ 有些时候不是跑的问题，是业务发展、竞品拼杀、商业博弈，必须有做一些特性和功能，这个时候是必须要动。 简单不是唯一标准 动不是问题，问题是怎么动，衡量标准是什么。 简单没有错，问题是简单就是指这一次改动的简单呢？ 那运维的简单性呢？扩展的简单性呢？稳定的简单性呢？排查的简单性呢？这些都不谈？ 比如要对接第三方备份厂商，居然有其他厂商入侵到我们计算节点，并且到我们计算节点删除 img 的操作方案。 可能这次是简单了，那下次呢？下个备份厂商呢？ 包括备份对接 s3 接口，多好的需求，符合生态，非常标准化。 结果硬是做成了非标能力，绑定存储，绑定各种特定流程，非得模仿老功能，依赖中转节点。 难道就不能从计算节点直接上传 s3？ 数不胜数的例子，这类问题，基本都是当时评审的时候"这个方案改动小"导致的。 这类问题真无解 这类问题其实真无解，就看 leader 的品味。 因为其他队员发言是没有权威的，文无第一。 尤其是"改动小"，比如你的方案实现了从计算节点直接上传备份到 s3，并且是标准 s3 接口，以后不做改动对接任何备份厂商。 很好吧，所有人都知道这是对的，但是不会有人主动去赞同，因为改动大，得背锅。 这类问题短期没有人在意，但是时间长了，赚钱的部门、商业线第一个跳出来： “你们写的代码怎么这么多限制，为什么别人支持，我们不支持，很奇怪。为什么这个支持 s3，那个不支持，很奇怪。” 不过到这依然没有结论，依然看 leader 的品味，看老板的品味。 小结 简单是唯一标准吗？不是； 简单没有错，问题是简单就是指这一次改动的简单呢； 还要考虑运维的简单性、扩展的简单性、稳定的简单性、排查的简单性； 这类问题真无解，就看 leader 的品味； 所有人都知道是对的，但不会有人主动去赞同，因为改动大，得背锅。