前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >竞品分析很关键,云时代如何科学地做竞品?

竞品分析很关键,云时代如何科学地做竞品?

作者头像
腾讯大讲堂
发布2019-12-03 20:42:06
1.3K0
发布2019-12-03 20:42:06
举报
文章被收录于专栏:腾讯大讲堂的专栏

关于作者

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

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

背景

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

竞品测评中的问题

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

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

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

我们的竞品思路

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

分层评测

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

  1. 第1层,我们可以用一个总体得分来给人直观的感受,并量化差距。这总体得分依据下层的得分进行计算。
  2. 第2层,我们可以用业务基准来评测CVM。比如Kafka、nginx在CVM上的表现,同样我们用一个分数来量化这个表现,这个分数由基准工具得分转换计算后得到。
  3. 第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个案例全盘解析中国跨文化传播创

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2019-12-02,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 腾讯大讲堂 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 背景
  • 竞品评测是一件对产品很有帮助的事情,知己知彼,百战不殆。尤其在云计算服务上的竞品,在2B的大背景下,显得更为重要。但云时代的竞品并没那么好做,而且做不好容易劳民伤财,付出人力并为友商财报做贡献。
  • 竞品测评中的问题
    • 分层评测
    • 打分方式
    相关产品与服务
    云服务器
    云服务器(Cloud Virtual Machine,CVM)提供安全可靠的弹性计算服务。 您可以实时扩展或缩减计算资源,适应变化的业务需求,并只需按实际使用的资源计费。使用 CVM 可以极大降低您的软硬件采购成本,简化 IT 运维工作。
    领券
    问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档