团队管理之性能实施团队日志1

由于各种不为人知的原因，这几日进了一个项目组。

我以为我是来打酱油的，后来发现来了几个比我还要酱油一些。

9个系统，加上我才五个性能组成员，还有三个是没类似项目的脚本编写经验的，性能分析和调优经验也很缺乏。

今天在开了一个PMO的会之后，下午在调脚本的时候一个小伙花了几个小时才搞清楚一个日志为什么打不出来的原因，是因为一个旧的jar包被放到了另一个jar包中导致被加载了两次，而旧的jar中的没有修改，jmeter在调用的时候一直在用旧的jar包，导致所有的在新jar中添加的调试语句都没有被执行。小伙很努力的折腾了几小时才发现这样的错误。可见技术不成熟还是花时间来弥补的。

下午跟性能组成员开了一个会，明确了一个思路，就是所有团队中的人都把时间放在写脚本上，在调试完所有的脚本之后的场景执行阶段。让数据中心的团队把相关的监控都部署上，要求粒度能达到OS级、DB级、JVM级等。基本上都是一些宏观的监控数据。其实在这之后还要有剖析级或调试级的，不过那些手段要在宏观的数据分析之后再确定用什么样的手段做下一步。

另外也明确了一些其他的事情，性能组的成员不要在扯皮性质的沟通上花时间。如果出现和其他团队扯皮的事情就过来找我，我来推进没效率的扯皮性质的沟通。

其实我在类似的事情上可以说是吃了很多的苦头，我也清楚在执行层面的沟通上有时因为沟通技巧不熟练，或者问题定位的不够具体导致的相互推诿。所以在这个项目中，我将依然承袭之前的吃苦头积攒的经验。在具体的技术问题上将定位到某个具体的代码或SQL或配置，再去和相关团队的人沟通。

另外，我跟团队成员说清楚一件事情，就是在对技术有任何不清楚的地方都要随时来找我。这一点其实说起来容易做起来太难。很多人都不是非常清楚自己不懂什么，所以在遇到走不下去的境况时，也不知道求助。我在之前带团队的时候，当发现有人明显有问题的时候，也是茫然不知所措，却还是花时间去不停地折腾些没意义的方向。在这个时候，我都会过去跟他聊聊生活啥的，然后顺便指导下技术的方向。

在后续的分析和调优的工作中，也在今天的小会上明确了操作的思路。就是团队成员一起分析性能问题，而不是让某个人单打独斗。对于新手来说，单打独斗太伤自尊了。

从这几天的感觉来看，这工作太像是咨询的工作了。

后面希望能多写一点工作日志，分享下性能团队的酸甜苦辣。

前几天都没写是因为出去喝酒去了。由于本地熟悉的人太多，饭约不断，大概刷脸吃一圈能吃到项目结束。