如何进行系统调研

作者: 康凯森

日期: 2018-03-11

我们公司内部进行系统选型或者方案设计的时候经常会进行系统调研，我认为系统调研一般分为两类：用户视角的系统调研（只需使用）和平台视角的系统调研（需要进行系统的维护和二次开发），下面我分别浅谈下如何进行用户视角的系统调研和平台视角的系统调研。

（目前水平和视野有限，有了新的理解后会不断更新）

个人认为我们平台侧进行系统调研时应该原理为主，测试为辅。（测试和原理一样都很重要，如同实验物理和理论物理一样，是相辅相成，不可分割的，但是在系统调研调研阶段我认为我们应该更侧重原理，调研时测试的目的应该是验证或纠正我们对系统原理的理解），理由如下：

系统是动态发展的，而且许多系统开发迭代速度很快，所以基于某个固定版本去测试意义不是很大。（比如TiDB1.1 某些场景下的OLAP查询相比1.0有几倍提升；比如Palo最新版相比我2月份测试时最多有6倍的性能提升；比如我们自己开发的Kylin精确去重查询，在多轮优化后，性能有数量级的提升）
测试环境的规模和测试场景有限，我们不可能测试出大规模集群下的性能瓶颈和扩展性问题，这只能依靠原理推导。（比如Kylin查询时加载字典导致的查询可用性下降在只有几个Cube时肯定不会暴露出来；比如Druid的Broker需要加载所有segment元数据的问题在小集群下也不会暴露；比如Clickhouse每次查询需要访问所有分区的缺陷在小规模测试也很难暴露出来）
只要我们理解了系统的架构，核心原理，我们就应该能够推测出其适用场景，固有缺陷，扩展性问题。 (比如香农定律就在理论上给出了信道编码的极限，后人只是在不断寻找无限逼近香农的理论边界，提出工程上可行的方案；比如从图灵机理论我们可以推测出目前人工智能的极限，人工智能只能解决世界上所有问题的极其微小的一部分，推理如下：

1 世界上有很多问题，其中只有一部分是数学问题；

2 在数学问题中，只有一小部分是有解的；

3 在有解的数学问题中，只有一部分是理想状态的图灵机可以解决的；

4 在后一类问题中，又只有一部分是今天实际的计算机可以解决的；

5 而人工智能可以解决的问题，又只是计算机可以解决问题的一部分。

当我们确定调研的原则是原理为主，测试为辅后，可以按照以下步骤进行系统调研

多数时候这两步已经足够，如果测试结果优秀，从原理上我们也判断该系统架构合理，可以满足我们需求，能够解决我们现有系统的不足和痛点，我们可以再进行第二次测试，第二次测试可以考虑以下几点：

经过第二次测试后，我们此时就应该判断我们是否需要上线该系统，具体可以从以下方面进行考虑：

如果我们已经决定上线该系统，我们可以再进行复杂的，详细的测试，发现该系统使用，运维，功能上的更多细节问题。

如果调研的系统官方文档，论文，公开资料已经足够详细，我们就没有必要看代码；
即使必须要看代码，也不能限于代码海洋中，纠结某些细节问题，因为调研时间有限，不可能搞清所有细节问题；
看代码时，可以通过log，测试用例，debug 来加速我们对代码结构的整体理解和把握；
看代码时，尽可能带着明确的问题和线索去看
对于某些重要的技术细节，我们可以先掌握What和Why，对于How我们可以在业余时间或者真正需要使用到这种技术时再详细调研，因为某个技术细节不会影响我们对一个系统整体架构，核心原理和未来极限的理解
调研新系统时应该和已知系统进行对比，思考为什么不同系统在解决相同或者类似问题时采用了不同方案，不同方案之间的权衡是什么

用户侧系统调研相比平台侧就会简单许多，我们不用考虑系统的维护和开发，我们也不用考虑系统都支持哪些场景。只要明确我们当前的需求场景目标系统能不能很好的Cover，一般而言我们可以从以下几点去考虑：

一般而言，在公司内部，每个需求在平台侧都会有相应的一个或者几个系统，平台侧也会给出每个系统的适用场景和特点，所以用户侧的调研就会简单许多，调研的主要工作其实都是平台侧完成。

得到专栏《吴军的谷歌方法论》的《为什么计算机不是万能的》