技术方案的思考方法

0 背景

最近在公司技术晋升中担任评委工作，算上这次总共参加了两次晋升评审，看到了一些技术人员晋升中的问题，稍微掌握了一些规律。

借着这次评审，谈谈在技术方案思考中的一些方法。

技术人员晋升时，最容易出现的问题就是罗列成绩，自己以前也是这种思路。今天谈到的思考方法，并不是为了晋升而做，而是在日常开发工作中也非常有用。

经常有人的技术方案被批评过度设计。这次晋升评审中，也有一个开发同学被批评是这种思路。这个同学先是讲了中台架构的技术方案，当时的对话大致如下：

评委：这个架构分层的依据是什么？
开发：这个分层方案遵循了阿里的中台架构方案。
评委：这个分层方案一定是对的吗，很好的解决了所面对的问题吗？
开发：阿里作为业界领头羊，具有很大的业务量，这种分层没什么问题。
评委：你才用了这种分层方案之后，有遇到什么问题吗？
开发：（2分钟的思考），遇到了，xxxxx

这个开发之前已经晋升评审过两次，都失败了，之前的评委给到的评语都是过度设计。通过这番话，也不能就直接说这个研发就是过度设计了，因为无从判断；但至少知道这个开发对技术方的选型是有问题的，也许这个技术方案选型对了，但这个结果只能看概率。

1 问题推导解决方案

从上面的案例来看，方案选型的重要前提是 问题是什么 ，因为只有把问题解释清楚了，才知道具体要做什么，解决什么，否则没有问题，所有的解决方案都是无本之木。

为了更好的解释，我们举个例子：

线上有个对外（公网）http接口性能较差，需要做性能优化

之前在与很多研发说类似性能问题时，他们第一个念头是加redis缓存。但只要问为什么要加缓存，有什么必要性，他们一般给到的回答是：大家都这么做。再简单问一下为什么选择redis而不是memchace或其他cache？回答也都是：一般行业做法，或者redis可以持久化等表面回答。

这个选型过程之所以经不起推敲，最大的原因在于不知道要解决什么，也就是有两点没有清楚：

• 定义问题
• 分析问题

1.1 定义问题

简单来说，就是问题到底是什么。比如例子中的性能问题，这个大的方面是http接口性能不好，那这个是因为依赖接口性能不达标，还是接口调用顺序有问题，还是请求的数据量大？因为性能问题是个很大的问题，需要精确的定位。

按上面的分析来看，如果是请求数据量大，可能会导致网络传输时间较长，而且对底层数据库的压力较大；如果是依赖接口调用顺序问题，http接口可能依赖了10多个接口，每个接口响应时间都在10ms，但都是串形调用；这两种问题，对应的解决方案是有很大差异的。

1.2 分析问题

定义问题和分析问题应该是个循环往复的过程，在清晰认知问题之前，会不断的分析问题，定义问题。分析问题，就是把面对的问题，拆解并深入。比如例子中，如果是请求数据量大，这种数据量是真实需求吗，数据量是否不可避免，如果不可避免，那是否可以拆分多个接口实现；数据量大，对数据库有多大影响；这两种影响对问题的占比是多少等等。

分析问题把问题拆解深入，就像庖丁解牛一般，之后再进行合并同类项。

2 方案的衡量指标

对问题定义及分析完毕之后，怎样才算是解决了这个问题，或者衡量问题解决程度。

比如性能问题，最终目标是什么，如 avg<50ms,99线 <100ms 999线 <150ms。再细化下去，没有long-sql，没有long-service等指标，数据一致性高，数据实时性要求ms级。

衡量指标，不单单检验解决方案有效性，也能够指导方案的实施。比如没有long-sql，这点就要求方案要关注到对db的印象，数据实时性要求高，在方案上就不会使用缓存了。

制定衡量指标，有以下关键点：

• 指标数据化
• 指标的优先级
• 指标的阶段性目标

问题的解决方案一般会有多种，要选出最优（合适）解决方案，就需要根据衡量指标做判断。在方案实施上线后，才能根据衡量指标确认问题是否已经解决，如果没有解决还有哪些指标需要完成。

3 总结

解决问题过程中，都会集中在解决方案上，但分析并定义问题、并制定合理的衡量指标，整个解决方案就已经完成了一半以上。清晰认知问题，解决方案就已经呼之欲出了。剩下的一半工作量就是方案推进执行，这涉及到项目管理，在之后的文章里再做阐述。