关于作者

尹国高，腾讯CSIG质量部\专项测试技术中心\专项测试三组员工

导语I竞品评测是一件对产品很有帮助的事情，知己知彼，百战不殆。尤其在云计算服务上的竞品，在2B的大背景下，显得更为重要。但云时代的竞品并没那么好做，而且做不好容易劳民伤财，付出人力并为友商财报做贡献。

背景

竞品评测是一件对产品很有帮助的事情，知己知彼，百战不殆。尤其在云计算服务上的竞品，在2B的大背景下，显得更为重要。但云时代的竞品并没那么好做，而且做不好容易劳民伤财，付出人力并为友商财报做贡献。

竞品测评中的问题

回顾了一下以前做竞品评测的路程，发现主要会存在3个问题：

只关注性能，而忽略了价格
很多时候容易只盯着性能看，忘记了价格。尤其是云服务，价格是非常重要的一点。往往我们无法对齐所有配置（比如cvm使用的os，硬件参数），所以性价比成了客户考量云服务非常重要的一点。
冰冷的数据，如何变得鲜活
我们很容易变成只是为了做竞品而去做竞品，或来自老板的诉求，得到一堆数字，比较了一下大小，似乎就完成“任务”了。单纯的测量数据非常冰冷，是否可以考虑某些方式来直观的呈现差距？另外，如何佐证测量的指标是可靠的？比如测出来A>B，那为什么呢？能下钻到更微观的角度进行测评来辅助分析？能有其他的测试数据作为支撑？单纯就竞品这个事情，我们是不是可以再思考多一点点？
游击战？持久战？
一时兴起的竞品，它的价值是有限的，当你的邮件报告渐渐埋没于茫茫“邮海”中，大家便也忘记了这件事情。而且这个现象还有可能周而复始的发生。竞品是场”持久战“，价值最大化就需要自动化、数据库存储以及前端展示。可能很多人都比较喜欢邮件报告的方式，因为它确实可以做到图文并茂重点突出。但正如前面所说，价值容易丢失，也不能日后来做对比分析。

基于这三点，下面给出了在竞品上的一些思考和实践。

我们的竞品思路

此方案对于各种云服务无差别，适合任何对象。比如IaaS层的CVM，PaaS层的数据库服务，甚至SaaS的人脸识别服务。简单来说，这种方案基于两种维度：分层评测 * 特征评测

分层评测

顶层为服务的总体得分，下层可以用来辅助分析上一层。或者说上层为宏观维度，下层为微观维度。下面以评测CVM服务举例：

第1层，我们可以用一个总体得分来给人直观的感受，并量化差距。这总体得分依据下层的得分进行计算。
第2层，我们可以用业务基准来评测CVM。比如Kafka、nginx在CVM上的表现，同样我们用一个分数来量化这个表现，这个分数由基准工具得分转换计算后得到。
第3层，我们可以用微基准工具来评测CVM。比如SPECCPU for cpu、stream for内存、netperf for网络等。同样我们可以用一个分数来量化这些工具的得分。这个得分用基准工具测出来的数值，用某种算法转化一下便可得到。

这样分层评测，不仅直观，而且相互佐证。当我们对某服务在不同产商中的性能差距感到疑惑时，进一步可以去看下一层的数据。不仅知道差距是多少，我们还有途径去分析导致差距的可能原因。比如，假设kafka在阿里云的云服务器上表现较好？我们就可以去下一层的微基准查看fio和netperf工具的表现，来初步分析是磁盘性能差距还是网络性能差距导致Kafka得分差距。

特征评测

被评测的对象，要取哪些特征来进行打分呢？吞吐量和时延是衡量系统性能的最常用的特征了，别忘了我们在说云计算，服务的稳定性和价格也是非常重要的。总结一下就是，每一层的评测对象都可以从这4个特征去打分：

吞吐量
时延
稳定性
价格

画个图的话：

打分方式

打分主要会遇到两个问题：

给定层级给定特征，有多个决定因素
这多个决定因素的计量单位可能不一样

我们主要用平均值和百分等比缩放方法来解决这些问题。

平均值
对于给定层级给定特征，如果有多个决定因素，暂时假设这些决定因素的权重都是相等的，我们可以通过平均值来计算该层级该特征的分数。这里有两种情况：
1）一个工具可能有多个指标来衡量一个对象的某个特征。比如netperf的PPS和bandwidth都是衡量网络的吞吐量，磁盘的iops和带宽也都是衡量磁盘的吞吐量，再上到Kafka业务基准，RPS和带宽，producer和consumer性能，等等等等。这类情况，我们可以将工具测量的值进行百分等比缩放（参考下面）后，求平均值即可
2）一个对象可能有多个工具来评测，比如unixbench、speccpu都可以测评cpu。同样，我们算出unixbench工具得分，speccpu工具得分后，可以通过平均值来得出该对象得分。
百分等比缩放
benchmark工具测出来的数值是抽象的，对于没有接触过这个工具的人而言，只是冷冰冰的数字没有意义。而转换为分数后这个数据就是鲜活的了，可以非常直观感受到差距。那怎么进行这个转换？假设2个产商的ServiceA用ToolO测得指标MericR的值分别为1.2, 2.4。则百分等比缩放后，MetricR的得分分别为50分，100分

觉得很抽象？没关系，我们来看个例子。

例子

我们要对ServiceA在产商CloudX，CloudY进行竞品，包括：

ServiceA的吞吐量
ServiceA的时延
ServiceA的稳定性
ServiceA的性价比

这里我们仅举例吞吐量分数的计算方式。其他类似。
假设用两个工具来衡量ServiceA的吞吐量的工具（你也可以只用一个，这里只是举例），分别是ToolM, ToolN。另外ToolM描述吞吐量的指标有：TM1, TM2；ToolN描述吞吐量的指标有TN1，TN2
于是ServiceA的吞吐量得分便可以这样算：算出每个产商在每个工具上的得分，然后将这两个工具的得分求平均值，即可得到产商在ServiceA上的吞吐量得分。
怎么算产商在某工具上得分呢？对该工具的每个指标上的值进行百分等比转换得出分数，再对所有指标得分求平均值。具体是：
1）假设CloudX，CloudY在TM1指标上的值分别为3、6，则转换后的分数为50、100分；在TM2指标上的值分别为2、5，则归一化后的分数40、100；于是CloudX的ServiceA的吞吐量在工具ToolM上的得分就是ave(50, 40) = 45分，CloudY便是ave(100, 100) = 100分
2）用同样方式我们可以算出CloudX、CloudY的ServiceA在工具ToolN上的得分，假设分别为
10分、90分，于是CloudX的ServiceA的吞吐量得分便为：ave(30,10)=20, CloudY的得分是：ave(70,90)=80分

硬广

有了这样一个思路，结合我们现有成熟好用的云驭前后端，大家可以快速地将一个云服务的竞品测评接入到云驭竞品系统中来。接入过程非常简单，你只需要提供一份清单，分多少层，用什么工具来衡量服务的什么特征，用工具中的哪些指标来参与计算特征，即可

云驭竞品系统的优点：

对应竞品方案的分层展示，清晰直观全面地展现它在各产商上的表现
我们集成自动获取云产商服务的按量价格，定期更新
前端采用流行的开源Grafana前端
数据库存储，保留历史测评数据，可以观察趋势，也可以方便各维度对比

当然了，我们还有其他好用的产品：

云驭 ==> 大而全的腾讯云IaaS性能数据平台
PerfTuner ==> 面向工具的服务器性能自动化测试框架，集成Intel的VTune和perf的分析能力，自动参数调优，数据配置存储到数据库并可在云驭展示。现已经有接近30个涵盖CVM各场景性能（计算网络存储等）的benchmark工具的封装
云驭SDK ==> 上报性能数据以在云驭前端展示