常见的需求分析方法有：

1. 结构化分析
2. 系统建模
3. 需求加法
4. 需求减法

产品经理做需求分析主要是去定义问题。怎样去定义问题呢？主要是从有需求定义和寻找出有价值的需求去实现；或者是在已有的需求中去创新、规划出产品未来的需求。

一、如何做结构化分析

结构化的分析方法是传统的分析法，它的好处是在需求阶段可以不需要精确地定义系统，只需要根据业务框架确定系统的功能范围，以及每个功能的处理逻辑和业务规则，功能需求规格书等。
因为不需要精确描述，因此描述系统的方式比较灵活多样，可以采用图表、示例图、文字等等方式来描述系统。在系统开发以前，一般还可以采用更为直观的原型系统方式和最终用户进行交流和确认，因此对业务需求的要求会低一些，业务需求阶段的周期相对容易控制；通过业务全景图，最终用户也能了解系统的功能；通过功能活动图和业务规则的描述，也可以相对精确地描述业务系统；因为没有严格的标记语言，可以采用适当的篇幅描述适当的系统。
当然，这种方法的缺点也是明显的，分析人员和业务人员之间可能缺乏共同语言，机器不能识别业务需求书，在设计阶段还需要继续和用户确认一部分功能。

二、如何做系统建模

此方法的核心概念是实体和关系，基本工具是E-R图，其基本要素由实体、属性和联系构成。该方法的基本策略是从现实中找出实体，然后再用属性进行描述。（尤其是B端产品经理需要掌握，因为B端产品往往业务模型复杂、干系人众多）
它从数据角度对现实世界建立模型。大型软件系统较复杂；很难直接对其分析和设计，常借助模型。模型是开发中常用工具，系统包括数据处理、事务管理和决策支持。实质上，也可看成由一系列有序模型构成，其有序模型通常为功能模型、信息模型、数据模型、控制模型和决策模型。有序是指这些模型是分别在系统的不同开发阶段及开发层次一同建立的。建立系统常用的基本工具是E—R图。经过改进后称为信息建模法，后来又发展为语义数据建模方法，并引入了许多面向对象的特点。

三、需求加法

我们在需求收集时，会发现需求无法满足核心主流程的设计，无法去支撑业务的运行时。首先可能会先想到去重新收集一次需求或者是凭产品经理自身的一个能力去规划处新需求来完善产品，以使产品来满足现有的业务。这一点很考验产品经理对业务的熟悉，对整个产品设计的思想。虽然产品经理不一定产出最终的需求，但是产品经理要学会和刻意锻炼自己挖掘需求的能力，去总结和发现更加适合产品的需求。从而完善核心业务流程的所有功能。

四、需求减法

经过一轮有目的性和有针对性的初始的需求收集，会收集到大量的需求。这些需求中包含许多无意义、不可实现和很多假需求。产品经理需要去甄别那些当前不实现，与当前产品无关的需求都需要排除掉，需要产品经理不停地做减法，直到留下当前的核心需求。产品经理需要有敏锐的嗅觉去捕获到有价值的需求，围绕产品的核心业务功能进行整体的筛选。从而去掉与核心业务实现无关的需求。

总结

通过以上的几种方法，相信大家对需求分析的方法有了基本的认知，对需求分析的过程也会有个简短的了解和一些想法。产品经理的需求分析相比于开发人员的需求分析可能会相对抽象一点。因为双方关注重点不同，但是也会产生许多交集和共鸣（比如E-R图）。很多时候，需要产品经理去挖掘用户真实的需求。其实产品经理在需求分析阶段就一个定义问题的过程，如果你在定义问题的时候就已经产生了很大的偏差，那么你在给出解决方案的时候，无论解决方案多美完美和完善都是白费力气。这就好比，一个人想去北方，结果你给了他张往南方飞的机票（南辕北辙）。所以，产品经理的重要性也就不言而喻。

大数据时代已然来临，企业的经营发展离不开对数据的收集、分析和挖掘。数据的收集一般采用以兔子动态ip代理辅助的爬虫技术，数据的分析则有科学的依据和细致个性化的方法，而数据挖掘是指从数据库的大量数据中揭示出隐含的、先前未知的并有潜在价值的信息的非平凡过程，当然也有非常重要的一些方法。

数据分析是从数据中提取有价值信息的过程，过程中需要对数据进行各种处理和归类，只有掌握了正确的数据分类方法和数据处理模式，才能起到事半功倍的效果，以下是数据分析员必备的9种数据分析思维模式：

 

1、分类

分类是一种基本的数据分析方式，数据根据其特点，可将数据对象划分为不同的部分和类型，再进一步分析，能够进一步挖掘事物的本质。

2、聚类

聚类是根据数据的内在性质将数据分成一些聚合类，每一聚合类中的元素尽可能具有相同的特性，不同聚合类之间的特性差别尽可能大的一种分类方式，其与分类分析不同，所划分的类是未知的，因此，聚类分析也称为无指导或无监督的学习。

数据聚类是对于静态数据分析的一门技术，在许多领域受到广泛应用，包括机器学习，数据挖掘，模式识别，图像分析以及生物信息。

3、回归

回归是一种运用广泛的统计分析方法，可以通过规定因变量和自变量来确定变量之间的因果关系，建立回归模型，并根据实测数据来求解模型的各参数，然后评价回归模型是否能够很好的拟合实测数据，如果能够很好的拟合，则可以根据自变量作进一步预测。

4、频繁项集

频繁项集是指事例中频繁出现的项的集合，如啤酒和尿不湿，Apriori算法是一种挖掘关联规则的频繁项集算法，其核心思想是通过候选集生成和情节的向下封闭检测两个阶段来挖掘频繁项集，目前已被广泛的应用在商业、网络安全等领域。

5、相似匹配

相似匹配是通过一定的方法，来计算两个数据的相似程度，相似程度通常会用一个是百分比来衡量。相似匹配算法被用在很多不同的计算场景，如数据清洗、用户输入纠错、推荐统计、剽窃检测系统、自动评分系统、网页搜索和DNA序列匹配等领域。

6、数据压缩

数据压缩是指在不丢失有用信息的前提下，缩减数据量以减少存储空间，提高其传输、存储和处理效率，或按照一定的算法对数据进行重新组织，减少数据的冗余和存储的空间的一种技术方法。数据压缩分为有损压缩和无损压缩。

7、链接预测

链接预测是一种预测数据之间本应存有的关系的一种方法，链接预测可分为基于节点属性的预测和基于网络结构的预测，基于节点之间属性的链接预测包括分析节点资审的属性和节点之间属性的关系等信息，利用节点信息知识集和节点相似度等方法得到节点之间隐藏的关系。与基于节点属性的链接预测相比，网络结构数据更容易获得。复杂网络领域一个主要的观点表明，网络中的个体的特质没有个体间的关系重要。因此基于网络结构的链接预测受到越来越多的关注。

8、统计描述

统计描述是根据数据的特点，用一定的统计指标和指标体系，表明数据所反馈的信息，是对数据分析的基础处理工作，主要方法包括：平均指标和变异指标的计算、资料分布形态的图形表现等。

9、因果分析

因果分析法是利用事物发展变化的因果关系来进行预测的方法，运用因果分析法进行市场预测，主要是采用回归分析方法，除此之外，计算经济模型和投人产出分析等方法也较为常用。

以上是数据分析员应熟练掌握的9种数据分析思维方法，数据分析员应根据实际情况合理运用不同的方法，才能够快速精确的挖掘出有价值的信息!

性能分析与调优如何下手，先从硬件开始，还是先从代码或数据库。从操作系统（CPU调度，内存管理，进程调度，磁盘I/O）、网络、协议（HTTP， TCP/IP ），还是从应用程序代码，数据库调优，中间件配置等方面入手。

单一个中间件又分web中间件（apache 、IIS），应用中间件（tomcat 、weblogic 、webSphere ）等，虽然都是中间件，每一样拎出来往深了学都不是一朝一夕之功。但调优对于每一项的要求又不仅仅是“知道”或“会使用”这么简单。起码要达到“如何更好的使用”。

常看到性能测试书中说，性能测试不单单是性能测试工程师一个人的事儿。需要DBA 、开发人员、运维人员的配合完成。但是在不少情况下性能测试是由性能测试人员独立完成的，退一步就算由其它人员的协助，了解系统架构的的各个模块对于自身的提高也有很大帮助，同时也更能得到别人的尊重。

再说性能调优之前，我们有必要再提一下进行测试的目的，或者我们进行性能测试的初衷是什么？

能力验证：验证某系统在一定条件具有什么样的能力。

能力规划：如何使系统达到我们要求的性能能力。

应用程序诊断：比如内存泄漏，通过功能测试很难发现，但通过性能测试却很容易发现。

性能调优：满足用户需求，进一步进行系统分析找出瓶颈，优化瓶颈，提高系统整体性能。

一般系统的瓶颈

性能测试调优需要先发现瓶颈，那么系统一般会存在哪些瓶颈：

硬件上的性能瓶颈：

一般指的是CPU、内存、磁盘I/O 方面的问题，分为服务器硬件瓶颈、网络瓶颈（对局域网可以不考虑）、服务器操作系统瓶颈（参数配置）、中间件瓶颈（参数配置、数据库、web服务器等）、应用瓶颈（SQL 语句、数据库设计、业务逻辑、算法等）。

应用软件上的性能瓶颈：

一般指的是应用服务器、web 服务器等应用软件，还包括数据库系统。

例如：中间件weblogic 平台上配置的JDBC连接池的参数设置不合理，造成的瓶颈。

应用程序上的性能瓶颈：

一般指的是开发人员新开发出来的应用程序。

例如，程序架构规划不合理，程序本身设计有问题（串行处理、请求的处理线程不够），造成系统在大量用户访问时性能低下而造成的瓶颈。

操作系统上的性能瓶颈：

一般指的是windows、UNIX、Linux等操作系统。

例如，在进行性能测试，出现物理内存不足时，虚拟内存设置也不合理，虚拟内存的交换效率就会大大降低，从而导致行为的响应时间大大增加，这时认为操作系统上出现性能瓶颈。

网络设备上的性能瓶颈：

一般指的是防火墙、动态负载均衡器、交换机等设备。

例如，在动态负载均衡器上设置了动态分发负载的机制，当发现某个应用服务器上的硬件资源已经到达极限时，动态负载均衡器将后续的交易请求发送到其他负载较轻的应用服务器上。在测试时发现，动态负载均衡器没有起到相应的作用，这时可以认为网络瓶颈。

性能测试出现的原因及其定位十分复杂，这里只是简单介绍常见的几种瓶颈类型和特征，而性能测试所需要做的就是根据各种情况因素综合考虑，然后协助开发人员\DBA\运维人员一起定位性能瓶颈。

一般性能问题调优的步骤：

步骤一：确定问题

应用程序代码：在通常情况下，很多程序的性能问题都是写出来的，因此对于发现瓶颈的模块，应该首先检查一下代码。

数据库配置：经常引起整个系统运行缓慢，一些诸如oracle 的大型数据库都是需要DBA进行正确的参数调整才能投产的。

操作系统配置：不合理就可能引起系统瓶颈。

硬件设置：硬盘速度、内存大小等都是容易引起瓶颈的原因，因此这些都是分析的重点。

网络：网络负载过重导致网络冲突和网络延迟。

步骤二：确定问题

当确定了问题之后，我们要明确这个问题影响的是响应时间吞吐量，还是其他问题？是多数用户还是少数用户遇到了问题？如果是少数用户，这几个用户与其它用户的操作有什么不用？系统资源监控的结果是否正常？CPU的使用是否到达极限？I/O 情况如何？问题是否集中在某一类模块中？ 是客户端还是服务器出现问题？ 系统硬件配置是否够用？实际负载是否超过了系统的负载能力？ 是否未对系统进行优化？

通过这些分析及一些与系统相关的问题，可以对系统瓶颈有更深入的了解，进而分析出真正的原因。

步骤三： 确定调整目标和解决方案

提高系统吞吐量，缩短响应时间，更好地支持并发。

步骤四：测试解决方案

对通过解决方案调优后的系统进行基准测试。（基准测试是指通过设计科学的测试方法、测试工具和测试系统，实现对一类测试对象的某项性能指标进行定量的和可对比的测试）

步骤五：分析调优结果

系统调优是否达到或者超出了预定目标？系统是整体性能得到了改善，还是以系统某部分性能来解决其他问题。调优是否可以结束了。

最后，如果达到了预期目标，调优工作就基本可以结束了。

下面算是一个技巧，如面试官问到一个性能问题假设，我不知道性能问题出在哪儿时，可以按照这个思路回答^_

• 查找瓶颈时按以下顺序，由易到难。
服务器硬件瓶颈—〉网络瓶颈（对局域网，可以不考虑）—〉服务器操作系统瓶颈（参数配置）—〉中间件瓶颈（参数配置，数据库，web服务器等）—〉应用瓶颈（SQL语句、数据库设计、业务逻辑、算法等）
注：以上过程并不是每个分析中都需要的，要根据测试目的和要求来确定分析的深度。对一些要求低的，我们分析到应用系统在将来大的负载压力（并发用户数、数据量）下，系统的硬件瓶颈在哪儿就够了。
• 分段排除法 很有效

性能测试调优应该注意的要点：

• 要点1： 在应用系统的设计开发过程中，应始终把性能放在考虑的范围内。

• 要点2：确定清晰明确的性能目标是关键。

• 要点3： 必须保证调优后的程序运行正确。

• 要点4： 系统的性能更大程度上取决于良好的设计，调优技巧只是一个辅助手段。

• 要点5： 调优过程是迭代渐进的过程，每一次调优的结果都要反馈到后续的代码开发中去。

• 要点6： 性能调优不能以牺牲代码的可读性和可维护性为代码。

下面让我们来聊聊性能测试过程中的一些注意事项，以及常见的一些性能缺陷表现及如何进行定位分析并且调优。。。

一、注意事项

1、断言

在压测时，为了判断发送的请求是否成功，一般会通过对请求添加断言来实现。使用断言时，建议遵循如下规范：

①、断言内容尽量以status/code、msg/message来判断（当然前提是接口设计遵循Restful规范）
Jmeter示例：

阿里云PTS：
如果使用的是PTS压测，则断言设置中，以code/status、msg/message等于对应的值为准；

②、尽可能不要将所有的Response Body内容作为断言判断的内容，这样很可能会导致大量的“断言”失败；

PS：然后很遗憾的是，见过很多做压测的童鞋，断言内容以整个响应参数内容做断言，导致大量的报错。

2、成功率

一般在性能测试中，我们都追求99.99%的成功率，但在实际的测试过程中，为了尽可能覆盖代码逻辑，在准备阶段会尽可能的准备较多的热点数据去做到覆盖。

这样的话，我们所关注的成功率指标，就要分为如下两种：

①、事务成功率

事务成功率在某些时候也可以视为请求成功率，在断言判断时以code/status等内容来作为请求是否成功的衡量依据；

②、业务成功率

实际的业务场景中，所谓的成功率，并不能仅根据返回的code/status来判断。比如：一个查询请求，无论是返回正确的查询结果还是由于对应数据返回空，这个请求都是成功的。

对应的响应参数可能是：{"status":"200","message":"success"}；也可能是：{"status":"200","message":"暂无对应结果"}。

PS：在性能测试过程中，考虑到业务成功率和请求成功率的不同指标，结合断言内容，需要灵活设置断言的方式（当然，我依然建议遵循如上的2点断言规范）！

二、常见性能瓶颈解析及调优方案

在性能测试中，导致性能出现瓶颈的原因很多，但通过直观的监控图表现出来的样子，根据出现的频次，大概有如下几种：

性能瓶颈出现频次	具体表现
高	TPS波动较大
高	高并发下大量报错
中	集群类系统，各服务节点负载不均衡
中	并发数不断增加，TPS上不去，CPU耗用不高
低	压测过程中TPS不断下降，CPU使用率不断降低

下面对常见的几种性能瓶颈原因进行解析，并说说常见的一些调优方案：

1、TPS波动较大

原因解析：出现TPS波动较大问题的原因一般有网络波动、其他服务资源竞争以及垃圾回收问题这三种。

性能测试环境一般都是在内网或者压测机和服务在同一网段，可通过监控网络的出入流量来排查；

其他服务资源竞争也可能造成这一问题，可以通过Top命令或服务梳理方式来排查在压测时是否有其他服务运行导致资源竞争；

垃圾回收问题相对来说是最常见的导致TPS波动的一种原因，可以通过GC监控命令来排查，命令如下：

1 # 实时打印到屏幕
2 jstat -gc PID 300 10
3 jstat -gcutil PID 300 10
4 # GC信息输出到文件
5 jstat -gc PID 1000 120 >>/path/gc.txt
6 jstat -gcutil PID 1000 120 >>/path/gc.txt

调优方案：

网络波动问题，可以让运维同事协助解决（比如切换网段或选择内网压测），或者等到网络较为稳定时候进行压测验证；

资源竞争问题：通过命令监控和服务梳理，找出压测时正在运行的其他服务，通过沟通协调停止该服务（或者换个没资源竞争的服务节点重新压测也可以）；

垃圾回收问题：通过GC文件分析，如果发现有频繁的FGC，可以通过修改JVM的堆内存参数Xmx，然后再次压测验证（Xmx最大值不要超过服务节点内存的50%！）

2、高并发下大量报错

原因解析：出现该类问题，常见的原因有短连接导致的端口被完全占用以及线程池最大线程数配置较小及超时时间较短导致。

调优方案：

短连接问题：修改服务节点的tcp_tw_reuse参数为1，释放TIME_WAIT scoket用于新的连接；

线程池问题：修改服务节点中容器的server.xml文件中的配置参数，主要修改如下几个参数：

# 最大线程数，即服务端可以同时响应处理的最大请求数
maxThreads="200"                        
#  Tomcat的最大连接线程数，即超过设定的阈值，Tomcat会关闭不再需要的socket线程       
maxSpareThreads="200"               
#  所有可用线程耗尽时，可放在请求等待队列中的请求数，超过该阈值的请求将不予处理，返回Connection refused错误
acceptCount="200"                 
#  等待超时的阈值，单位为毫秒，设置为0时表示永不超时
connectionTimeout="20000"         

3、集群类系统，各服务节点负载不均衡

原因解析：出现这类问题的原因一般是SLB服务设置了会话保持，会导致请求只分发到其中一个节点。

调优方案：如果确认是如上原因，可通过修改SLB服务（F5/HA/Nginx）的会话保持参数为None，然后再次压测验证；

4、并发数不断增加，TPS上不去，CPU使用率较低

原因解析：出现该类问题，常见的原因有：SQL没有创建索引/SQL语句筛选条件不明确、代码中设有同步锁，高并发时出现锁等待；

调优方案：

SQL问题：没有索引就创建索引，SQL语句筛选条件不明确就优化SQL和业务逻辑；

同步锁问题：是否去掉同步锁，有时候不仅仅是技术问题，还涉及到业务逻辑的各种判断，是否去掉同步锁，建议和开发产品同事沟通确认；

5、压测过程中TPS不断下降，CPU使用率不断降低

原因解析：一般来说，出现这种问题的原因是因为线程block导致，当然不排除其他可能；

调优方案：如果是线程阻塞问题，修改线程策略，然后重新验证即可；

6、其他

除了上述的五种常见性能瓶颈，还有其他，比如：connection reset、服务重启、timeout等，当然，分析定位后，你会发现，我们常见的性能瓶颈，

导致其的原因大多都是因为参数配置、服务策略、阻塞及各种锁导致。。。

性能瓶颈分析参考准则：从上至下、从局部到整体！

以上分析及调优方案仅供参考，具体定位还需要根据日志监控等手段来分析调优。。。