1.问题分析前的工作---保障不盲目
当前问题现象具体是怎样的？——作为分析者的你，真的了解清楚了吗？
当前功能的内部实现逻辑是怎样的？——代码逻辑流程是否了然于胸？
问题分析的思路是什么，可能的怀疑点有哪些呢？
2.收集分析日志等材料---一次性把需要的用来分析问题的日志拿到手
以SNMP的一个操作耗时问题为例，需要收集操作具体的日志包括界面日志以及开发能看的更细节的运行日志，另外一定要抓取SNMP报文。如果是一个新老系统的性能实现有差别的场景，那么我们就需要分别在新老系统进行日志获取和抓包进行对比分析。其他实际问题，可以根据各自的情况来便宜行事。
3.按照思路去分析---跟日志深入对话，从中了解事实的真相是什么
统计软件与设备的SNMP交互总耗时：
抓包的时候，查看第一条报文的时间，而后查看最后一条报文的时间，做差值得到交互总耗时。
关键性疑问有2个：如何知道哪条是当前功能涉及的第一条报文，如何知道哪条是当前功能涉及的最后一条报文。通过看源码来判断。
统计设备的SNMP响应总耗时：
通过wireshark软件来辅助得到，SNMP包通常是应用软件下发一个request请求（例如：get-request），设备再返回一个get-response，他们一般都是成对出现，你来我往的方式。因此，我们在wireshark软件打开抓包文件的时候，选择一下：
步骤1.“视图”---“时间显示格式”---“自上一个显示分组经过的秒数”
步骤2：导出wireshark计算后的耗时到csv文件中，wireshark软件选择“文件”---“导出分组解析结果”---“为CSV”
步骤3：用excel软件打开csv文件，将info列进行过滤，只过滤包含“response”的条目，这些条目的时间总和即为设备响应报文到达应用软件的耗时总和。（******特别注意一下，有的时候，抓包的时间会比较长就算正好那个时间段抓包，可能也会抓取到了其他非本功能的抓包，特别是超出本功能操作之外的时间段的报文，需要通过时间排除一下，比如：我们功能是17:00:00操作开始，18:00:00结束的，那么我们可以找到，排除掉这个时间段以外的条目）?
按照这种方式可以分别得到正常情况下的response耗时T1和功能总耗时很长的环境的response耗时T2，如果T2明显大于T1，可以判断当前环境网络耗时较多，进一步分析忘网络耗时。否则，可以认为当前环境下，应用软件耗时较长，需要重点分析应用软件的实现差异，查看代码的时候同样需要代码和抓包结合进行分析。
查看典型的几个包交互耗时是否存在异常：
挑选典型的几个报文的交互，分析一下2方面，一方面是response的耗时怎样，另外一方面看下应用下发request的间隔时间。
总之，分析的过程就是不断发掘蛛丝马迹的过程，不断假设和验证。