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 总结

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