性能场景之业务模型中使用二八原则的不负责任

今天在第一期培训的微信群中，有人讨论性能场景设计中的业务模型的28原则是否适用的问题。他把QQ群里的聊天截过来了。

问我的问题是，二八原则是否适用于性能场景中的业务模型设计。我问他：二八原则从哪个方面可以说明适用于性能场景？有没有出处？有没有证据和数据可以证明？

然后就是搜索了一阵。但是也没有确切的出处的结论。

之所以写这个文章的原因也是因为，我觉得很多人把理论和实际场景弄混淆了，并且在具体的场景中不做细节就直接套用某些以为正确的理论。

看下28原则的来源（以下引自搜索引擎）：

巴莱多定律（也叫二八定律）是19世纪末20世纪初意大利经济学家巴莱多发现的。他认为，在任何一组东西中，最重要的只占其中一小部分，约20%，其余80%尽管是多数，却是次要的，因此又称二八定律。

1897年，意大利经济学家帕列托在对19世纪英国社会各阶层的财富和收益统计分析时发现：80%的社会财富集中在20%的人手里，而80%的人只拥有社会财富的20%，这就是“二八法则”。

在WiKi中有如下解释：

The Pareto principle (also known as the 80/20 rule, the law of the vital few, or the principle of factor sparsity)[1][2] states that, for many events, roughly 80% of the effects come from 20% of the causes.[3] Management consultant Joseph M. Juran suggested the principle and named it after Italian economist Vilfredo Pareto, who noted the 80/20 connection while at the University of Lausanne in 1896, as published in his first paper, "Cours d'économie politique". Essentially, Pareto showed that approximately 80% of the land in Italy was owned by 20% of the population.（我删了一部分，因为我觉得太啰嗦了。）

另外，不管是百度还是google，我都搜索过性能测试和二八原则的关系，关键字我也换了好几个。基本上都是笼统的一带而过，即没有一个实例的数据说明，也没有具体的模型推导过程和数学支撑。

其实在我看来巴莱多定律只是一个统计分析过程，并不需要什么复杂的数学模型支撑（如果我理解有误，也欢迎指正）。

题外话说一句：我个人感觉老外特别喜欢干这类的research，然后总结总结，再有个头衔，写个论文，就可以称为XX定律XX理论了，留名青史。

在这个前提下，我想说的是：在一个具体的业务场景中，性能场景中的业务模型和二八原则并没有什么关系！

即使从宏观上来说有关系，也是很牵强的，至少至今为止，我没看到任何有数据支撑的证明。

先巴莱多定律（二八原则）来源于经济学，从宏观经济上来说，经过了调查取样统计之后，才说二八的。但是放到一个特定的场景中，那不一定适用。

特别是对于性能场景设计这样的比较具体的应用示例中，就更不适用。

从我多年的性能测试和性能分析的项目中来统计来看，大部分场景都是不符合二八原则的。看两个例子（图来源于7DGroup群友，并征得同意后使用的）：

例一：从下面这个系统的某业务统计（天）来看，不符合二八原则（二八原则是幂律分布，与之对应的是正态分布，（不知道正态分布长什么样的，自行搜索））。

例二：地铁系统对一卡通上班族做的统计（天），显然也不符合二八原则。

一个比较认真的小伙还找出了有书上写到性能场景是按二八原则来算的，并且说明是为了测试出系统的容量。而“书上写的能是错的吗“？

像这种不认真追究就写在书上的，我表示严厉批判（虽说我批判也没啥用）！

那怎么才是对的方式来设计得到业务模型呢？

两种方式：1. 对有生产历史数据的系统，肯定是从生产历史数据来分析，进而推断业务模型；2. 对没有生产历史数据的，首先是根据有经验的业务人员给出来，如果没有，可以拿同行业的数据来借鉴。换句话说，拍脑袋都比二八原则来得靠谱点。

有人说，我们没有历史数据，公司中也没有人做过类似的系统，也拿不到同行业的数据。那我只能祝你好运了。

在我每次讲课的时候，都提到用生产历史数据来分析，但是还是看到有很多人即使有历史数据也不这样做，断章取义的比比皆是。

拿业务统计数据来说，

首先，要有长时间的业务统计数据。如下图所示，取近一个月的数据，这个数据越长越好，最关键的是要覆盖足够的业务场景日。

是不是看这些就已经觉得挺麻烦的了？其实这个图已经是经过日志抽取、按秒/分/时/天汇总、计算百分比、排序之后的结果了。

我们放大下最后的百分比来看看。

只看最后一列即可，按业务百分比取较高的，这里我们取到业务5，这五个业务就已经点总业务量的94%了。做为普通日的业务场景，已经足够了。

其实，根据统计取出业务量比较大的一天的前五个业务（这句话我偷换了概念，但是不影响本文的合理性，请大家自行脑补并平衡好心态

）。做如下统计：

再做个图例：

以上数据得到的过程是：

1. 先取出业务量最大的一天中所有的数据。
2. 以小时为单位合并（这里我又埋个坑，因为如此来做会减少掉很多毛刺数据，可能会漏掉某些特殊的场景，这里不做完美主义了，先把主要的逻辑说清楚）。

我们也来算算是否符合二八原则。来按百分比统计下，为了方便，这里我先排个序，前面的小时只要数个数就可以，所以不用考虑顺序：

截止到我选择的4.66%，总共是79.11%。从时间上来算是12个小时，而这个业务系统一天提供服务的时间总共是20个小时。所以这个统计数据得到的结果是80%的业务在60%的时间内完成的。（如果看到这里有人问60%是从哪来的，我能气吐血。

）

这显然就不是二八原则了，这是不是说六四原则呢？！

所以对一个特定的业务场景来说，如果根据统计数据得到的结果是二八，那我尚能接受。如果什么也没干，就根据二八来做业务模型统计的基础了，那明显是不负责任的。

既然都写到这里了，就顺带手再延伸一下。

1. 根据上图取出某个小时内的业务比例。
2. 得到如下结果：

到这里就可以设置脚本中的线程或用户比例了。

从这个场景的逻辑上来说，以上描述就够完整了。

但是......上面其实只是一个普通日性能场景的业务模型。

对一个完整的系统的性能场景设计来说，还是不够的。

我们还要做其他的统计分析，才能得到其他的性能场景，而这些都是要有根有据，有礼有节，有前有后的。

我们还要接着和不负责任的做法斗争下去。

人生漫漫.....那个啥，说得有点远了。