基于专家知识+AI算法的性能调优、容量评估

在业务的性能调优中，我们往往会遇到下面三个方面的问题：

1）操作系统的软硬件配置过于繁杂。无论是应用内核参数、系统服务还是应用配置，都有成百上千的参数，而且参数之间相互，在调优的时候往往存在跷跷板现象，如何管理如此大量的领域知识，是非常困难的事情。

2）人力、时间成本高。做一次有效的全栈调优，往往需要把多个领域的专家集中起来进行一次1-3个月的集中攻关，在人力和时间成本上是非常大的代价。

3）专家知识难以固化复用。即使是我们在一个场景上把所有专家集中起来做了一次非常好的攻关，专家知识还是非常难以固化下来并在下个应用扩展使用起来，到了下一次调优场景，还是几乎要重头再来。

针对上述问题我们该如何求解呢？

• 如果专家知识非常难以固化，那我们为什么不建一个专家知识库平台来把专家知识固化起来呢？

• 如果我们的配置关系非常复杂，投入时间和人力非常高，那我们为什么不把AI算法引入进来，让人工智能帮我们做一些事情。



在容量评估测试中，我们也会遇到类似的问题：Benchmark的参数众多，哪些参数是需要使用的，哪些其实无关紧要？需要使用的参数，如何设置它的值才能保证给出的压力是足够的，从而不会因为压力不足而无法验证到物理机/系统真实的容量呢？

I 可行的解决途径——KeenTune的缘起

从上个部分中，我们其实可以看出求解的方式，一个是需要专家知识的固化平台，一个是可以考虑引入AI算法来解决人工无法有效探索参数取值空间的问题。这也就是KeenTune的起源，其主要完成两大部分的功能，一方面将人工的经验固化下来，形成能够在业务上一键调优的专家知识库——也就是静态调优；另一方面，在有了需要调优的参数及其取值空间的概要知识的情况下，可以使用AI算法来进行最优取值搜索。



这是KeenTune产品开始研发时最朴素的想法，后面也因为业务的实际需要，引入了参数可解释性方向的算法，来识别出来哪些参数对结果真实有影响，其最优取值范围是什么，从而指导进行人工解释和进一步研究；同时，也引入了高保真方向的算法来规避Benchmark/业务环境的波动对调优效果的准确性带来的影响；另外，也针对“在不增加时延的情况下，提升吞吐量”这样的带控制条件的实际调优需求，引入了多目标调优方向的算法。

请注意，KeenTune提供的动静态协同调优的能力，可以协助实际业务解决如下问题：

1）POC小集群调优到线上大规模集群调优，比如：POC小集群动态调优完后，调优经验固化成静态调优，直接大规模部署到线上；

2）相似场景的精细化调优，比如：调优过mysql后，使用mysql的固化出的静态专家知识库，转化成动态进行精细化调优。

在算法创新的同时，基于阿里业务自身的特点，KeenTune采用了高度模块化的分布式部署的方式，在业务端只需要部署轻量的agent（keentune-target），管控调度模块keentuned，算法模