关于作者
尹国高,腾讯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 ==> 上报性能数据以在云驭前端展示
-
程序员开发效率神器汇总!
腾讯设计师告诉你,如何从用户体验角度将文案与视觉融合
“我有故事,你要听吗?” | 18个案例全盘解析中国跨文化传播创