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

由于前面发现了一个应用 IO 高的问题是由于 jbd2 引起的，跟团队的人员说了一下，把相关的图发给他们，并且告诉他们如果看不懂我发的图就过来找我。

今天一早，团队里的一个姑娘就过来找我了，表示看不懂。这样的态度就挺好。我就把其他人也叫过来解释了一下原理和发现问题的方法，以及判断问题的思路。

那个姑娘说，为什么不用 jconsole 之类的工具来监控？而是用操作系统级别的命令来监控？她说，她的领导告诉她的是监控JVM。然后我就说明了下，性能监控的分层策略和性能分析的分层分析，也告诉了他们不同的工具的使用限制和使用场景。有经验的人看到这里应该就知道这个团队不好带了吧，时间紧，任务重，能力还不强。

今天的工作进展的不是特别的好。到下午压力机才到位，上午两个人只能用一个压力机。还好有一个人请假了，也就是四个编辑脚本的，只有一个人是没压力机可用。于是我就告诉他在本机调脚本。但是由于交互过程中会用到内网的地址，所以本机也只能调试脚本的第一步。也就是发数据发出去。然后截取服务端的日志来看是不是后续调用也成功了。不得已的资源不到位，只能想折中的办法。

另外今天找了开发团队的负责人和基础设施保障的同事，把发现的IO的问题解决掉。我们性能团队其实是有能力解决这样的问题。但是还是要把事情分清楚。不能因为会而去动手做。要把相应的其他团队的人拉进来一起做。并且把分析的过程和原理跟他们说清楚。

大家都很配合，所以很快就有了明显的TPS的增加。之前是200TPS左右，在调优了之后能达到400TPS了，但是效果还是没有达到我想要的程度。所以后续还要接着分析调优。这些都是后话了。

今天监控配置也没到位，只能自己手动上去一个个去看，很费时间。性能分析在宏观数据的收集上，不应该是现在这种状态。所以跟监控组的人说明白，今天一定要把监控配置好发给我。

在这第一周的工作中，也就是只能熟悉下环境了。没有正式的工作状态。

但是这个时候要做的是准备周报和数据收集的模板了，以便后续其它人在执行的时候知道要做哪些事情。

在性能执行还没开始的时候，就要考虑最终的结果是个什么样子。

并且需要把以后可能遇到的技术难点列出来，免得手忙脚乱。

管理的工作也不能落下，后面还要确定团队内和团队间的沟通方式。微信可以沟通，但是过程材料不能保存。

所以昨天我去找了git管理员，开了一个project。从下周起开始用，以免出现工作失误导致的文件丢失或文件混乱。

每个团队的资料整理和保存都是团队生存的核心工作之一。而我看到的是好多做项目的人，都不是很关注资料的收集保存。这就像公司内部的知识库系统一样。很多公司都知道知识库的重要性，但是也是很多公司在日常的工作中都不怎么关注的一环。这就像是一个人明知道自己的技能不足，但是就是不花时间学习，接着还是每天暴露出来自己的技能不足。不止是可悲。

其他的管理工作，像计划、风险、人员、依赖条件、资源冲突等都一一在monitor的范围之内。

项目状态看似和大部分的项目类似的状态了。不能按计划实施的风险也都摆在那里了，我想这也是大部分项目的计划都是个摆设的原因了。

前天以前就在项目中做过性能的团队成员聊天，也说了只给了测试的时间没有给调优时间的事情。

我觉得性能项目有两种可能出现这种情况。第一种就是领导根本不是那么重视，只是觉得性能嘛，录个脚本压一下就行了；第二种就是团队没能力做导致耗费了很多时间，让其他人没有了耐心，所以也就觉得性能测试就是这个样子了，从而不报希望，缩短性能实施窗口。

但是我来不就是改变这个现状嘛，所以我跟他们说，我们一定会做到调优的。一个瓶颈只要出现，肯定会找到具体的原因，并且我把定位瓶颈的手段一一跟他们说，让他们现在就开始储备起基本的技能。让大家对我们现在要做的性能调优有更多的信心，做调优，还是要专业一些。

我并没有期望现在这些没什么经验的人可以通过一两个星期就做到定位瓶颈的程度。现在只是要告诉他们如何收集需要的数据，当然我也跟他们讲如何看数据。能不能迅速掌握和融会贯通就要看个人的悟性了。

有很多人都觉得做性能要求的技术知识太多了。事实情况就是项目中需要用到的就是这么多。我觉得如果有好的引导，在项目中锻炼，再加上个人的努力。一年之内基本上就可以完全掌握对一类特定项目的性能分析能力。两到三年可以完全具备对任何项目的性能分析能力。

今天日志先记到这儿。