关于在项目组中实施性能技术赋能的思考

前言

赋能，顾名思义是指赋予某项能力或能量，对于本次服务端性能测试技术赋能来说，旨在增强研发人员对于性能的意识及主观能动性，提高代码质量，提高研发效能。

现状

在日常工作中我们发现了如下问题：

1、性能成为盲点：有些同事并不清楚性能测试的工作内容是什么，以及性能测试意义

2、遗漏性能问题：有些同事不清楚怎样的系统表现或处理结果表示出现了性能问题，遇到时可能会直接忽视

3、遗漏性能需求：有些同事不确定哪些新需求需要提前进行性能测试，可能会导致上线后暴露性能问题

4、性能问题类型集中：很多性能缺陷属于同一类编程方式造成的，甚至是相当明显的问题引起（比如循环调用、线程池写死或设置过小、limit设置过大），导致整个研发进度低效。

低效的原因分析：木桶效应，一个系统能提供多大的性能，取决于最短的那块板。所以性能测试有个特点是，解决了一个性能问题后，可能才会暴露出另一个问题。

常见流程是：提出性能需求->压测执行->发现性能问题->开发优化->功能验证->性能回归->发现性能问题->开发优化->功能验证->性能回归->……

如果存在多个低级问题，这个流程需要经过多次迭代才能结束，效率极低。

那么为什么不从编码阶段开始规避这些显而易见的问题呢？

5、人力有限：性能组目前面向多个产品，新需求、系统重构、技术优化每天都在进行，谁都不能保证没有遗漏的性能风险。

从根本上提高产品质量才是最可靠的方法。

赋能的意义

1、提高全员性能意识，从架构设计、编码阶段开始控制系统性能及稳定性风险，提高主观能动性（有意识地自觉地想问题、办事情）、提高效能。

2、提高产品质量，避免因性能意识不够或性能测试点的遗漏引起的线上问题。每年都是新人一茬又一茬，培训不到位，问题也会是一茬又一茬。

3、提升项目组成员个人能力，学到了就是你的。

预期效果

1、项目组成员了解性能测试的意义、工作模式及工作内容

2、项目组成员了解哪些编码方式对性能、稳定性造成影响

3、项目组成员了解如何用更简单的方式发起并发压力、进行故障演练、分析简单的性能问题等。

也许日常工作中不会经常用到，但是当你需要用的时候，至少能够知道怎么做。比如：

• 验证并发锁
• 观察单笔业务操作耗时特别久的问题是否由后端接口引起
• 验证某次优化是否有效（有效与生效是两个概念，有效是指正确性，生效指起了作用）

出现过这种情况：某个性能问题回归时发现因为缺少代码配置或未提交成功导致优化未生效。那么功能提测前有开发自测，性能问题回归前为什么没有？

 

如何赋能

核心是注重项目组的实际痛点。--讨论点：了解各位大佬对于性能工作的关注点、盲点及疑问。

宗旨是化繁为简、突出重点、能够让新人快速上手。

执行计划：

1）性能基础知识宣讲

性能基础概念、流程规范、指标评估标准、当前产品的性能覆盖情况

2）工具类宣讲

压力发起工具，监控工具，分析工具

3）方法论宣讲

介绍常见性能问题的分析方法

落地方式：

1、研发流程中增加研发性能自测

2、新人入职培训（新人大礼包，本文不展开）

评估标准：

提测打回率、bug数及bug质量环比

 

性能QA需要输出的内容

规范

方法论

自动化工具及平台