务虚：创建团队的性能文化

 以前的性能测试博客大多都是介绍性能测试的方法、思路以及测试工具的使用，能够称之为“务实”。这篇博客，聊聊“务虚”——如何创建团队的性能文化。。。

首先来看看团队中不一样角色，他们对性能的关注点都是什么？而后拆分开，从不一样视角聊聊如何针对性的创建团队的性能文化。。。

不一样视角的性能关注点

角色视角	性能关注点
产品	用户数、使用时间、使用场景
开发	系统架构、代码设计、内存使用、通讯方式
测试	系统性能表现是否知足性能需求指标：TPS/RT/CPU%/Memory%/Success%
运维	资源使用率、系统容量、扩展性、稳定性

 

1、产品

对于产品童鞋而言，不会直接考虑到系统性能，而更多的是须要关注有多少用户数，他们在什么时间段使用个人产品，使用频次最高的场景是哪些等因素。

一、用户数

已有用户数：即系统已有的用户数，一般意义上性能测试中所谓的模拟用户数（并发）都是经过已有用户的数量，按照二八原则来进行预估。

所谓的“二八原则”，即80%的用户在20%的时间访问系统，进行业务场景的交互操做。

活跃用户数：若是要更进一步的划分用户类型的话，DAU（日活）是个很好的维度，经过监控，能够看出有多少用户在什么时间段进行了哪些业务操做，

各个不一样的业务场景，在系统使用高峰时，各自的占比时长等。

潜在用户数：有时候因为业务快速发展或者用户引流渠道的拓展，会带来短时间内的用户注册和使用频次的激增，这个时候，激增的用户数和对系统的高频使用，

会给系统带来巨大的负担，对相似这样的状况作到心中有数，作好应对方案，能够很大程度上避免系统出错甚至服务不可用的尴尬局面。

二、使用时间

高峰时间：即用户使用系统最频繁的时间段，以及使用系统的用户量较大的时间。这种时间维度的划分须要一些定量的指标来区分，能够根据具体的业务场景来对待。

平缓时间：即用户平常使用时间段，这个能够从使用频次和使用人数上来设定一个阈值，进而针对性的划分时间区间。

特殊时间：好比双十一，好比一些特卖或者秒杀活动，短期内的用户数和使用频次的激增，会对系统形成很大的负担，若是不提早作好应对措施，极可能会形成一些很差的影响。

三、使用场景

高频业务场景：以电商网站举例，首页、搜索、商品明细页，这些场景能够说是用户高频访问的场景。

基础业务场景：一样以电商网站举例，用户注册、登陆、搜索、商品分类能够算做基础业务场景，即用户使用产品所必须涉及到的业务场景（固然，和其余类型的场景存在重叠）。

核心业务场景：同上，购物车，支付，能够看作电商网站的核心业务场景。

特殊业务场景：好比某个促销或者秒杀业务场景，属于短时间的有时效性但访问频次较高的，均可划归到特殊业务场景。

PS：上面的几种产品视角的关注点，更多的是从产品分析、需求分析的角度去看待和分类，若是能从产品设计或者需求阶段就考虑到这些因素带来的影响，

那么产品（或者说业务）更多的做为需求发起方，就能够在后续的开发测试运维阶段，让参与的童鞋都尽量考虑到这些因素从技术角度该如何应对，

从而下降系统上线后所面对的性能风险，或者说有针对性的应对方案。

 

2、开发

一、系统架构

根据业务需求，用户场景以及将来可能的业务变化，系统架构设计要考虑到系统的稳定性、扩展性以及可迁移性。

好比是否采用集群/分布式，是否须要考虑多级缓存，数据库是否须要读写分离、主从热备等方式。

二、代码设计

在项目的开始阶段，一件必不可少的的事情就是就是肯定代码的分层和架构，它在必定程度上决定了将来整个项目的代码风格。下面列举一些代码设计的目的和须要遵循的原则：

目的	原则
提供更好的可读性	经济原则
提升可维护性	最小可用原则
下降代码冗余	代码复用原则
高内聚低耦合	奥卡姆剃刀原则

关于代码设计须要遵循的原则，详细内容可参考这里：美团技术团队-性能优化模式

PS：固然，良好的代码设计，还包括开发规范、良好的命名方式、review、静态代码扫描等多种方式。

三、内存使用

这里的内存使用包括内存分配是否合理、代码运行是否会致使OOM、线程锁之类的问题。

四、通讯方式

根据具体的业务需求，通讯方式采用同步仍是异步？同步和异步各自的优缺点是什么？若是采用异步，框架选型如何考虑？举个例子：

好比最多见也最重要的支付场景，对数据一致性和实时性要求很高，那么同步通讯方式相比于异步，就更适合业务需求。

 

3、测试

一、性能测试指标

常见的性能测试指标包括TPS、RT、ART、CPU使用率、事务成功率、Memory使用率，指标的存在目的是为了对系统的性能表现有一个直观的衡量依据。

二、性能测试场景

场景，一句话归纳的话就是：什么人（用户）在什么时间（峰值/平缓/异常）进行了哪些操做（好比支付、搜索）。

三、性能测试目的

进行性能测试的目的是什么？新系统上线投产前的容量测试？已有系统迭代的性能变化验证？性能基线的肯定？异常流量下的容错处理和灾难恢复速率？

四、性能测试结果

系统性能表现是否知足需求？是否达到预期？存在什么风险，可能形成的影响是什么，解决方案/容灾策略是什么？

 

4、运维

一、资源使用率

CPU、内存使用占比是否合理？资源报警阈值如何设定？峰值流量时磁盘IO速率、日志占比等。

通常来讲，应用日志占比不要超过磁盘的30%，CPU、内存达到75%就须要重点关注，超过85%，就须要针对性的进行扩容或者降级处理。

二、系统容量

在当前的系统服务配置下，单台服务在阈值下所能提供的最大处理能力。

举例：某个特定业务场景，在2C4G的配置下，CPU使用率为90%，TPS最大值为10笔/秒，RT为0.2S，事务成功率100%。

三、扩展性

随着用户数、使用频次的增长，系统可否及时的进行服务扩展，扩展的速率、利用率等。

四、稳定性

系统稳定性，简单来讲就是：系统在性能阈值范围内长时间运行的性能表现。即系统长时间运行，各项指标相对平稳，不会有很大的波动或者突刺。

更多关于系统稳定性保障的策略，能够看这里：系统稳定性

 

最后，如何创建团队文化是个很抽象的问题，不一样的研发流程、业务模式、工程师素养都是须要考虑的因素。

我的认为，能够经过设定统一的目标，明确每一个岗位的职责，应该重点关注哪些方面，这样作有哪些价值，是否有正向的激励机制，提高沟通质量等手段，

久而久之，所谓的“团队文化”，也许就有了最适合本身的文化。。。