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

    在这一周中基本上遇到了性能实施过程中应该遇得到的复杂的问题。

    像堆外内存引发OOM Killer，C++ coredump，负载该均衡不均衡，主机资源不够用，数据引发TPS抖动，IO引发TPS抖动之类的。

    在这个项目中几乎碰到了我之前遇到的问题中的80%以上，至少从现象上来说是这样的。

    同时团队中关于测试的策略也有一些探讨。因为我们要回答两个关键的问题。

    1. 能不能支持目标TPS?

    2. 能支持的最大的TPS是多少？

    在测试的过程中，像下面的这几个图。压力过程中在21：24的时候就已经达到了TPS最大值。这时候线程数在200旁边，响应时间较前一个采样点有所上升，但还在1秒以下。

    在这几张图中，团队内部有一些争论。因为之前我说过要压到系统的瓶颈点之后的一个梯度，这样才能知道瓶颈点之后的性能表现。并且我也说过压到系统有问题为止。

    团队成员A是这个场景的执行人员。他的理由是因为我之前说过压到系统有问题。所以他就一直压，但是除了时间有点长之外，没有出现错误，资源也没用完，应该一直压下去，直到系统出问题为止。

    听起来顺理成章，理由充分，并且还是按我的思路往下走的。

    那我们就得来说一下，什么是性能问题？是出错？还是资源用满？还是其他的什么？

    在项目中，我经常讲东西给他们听。关于测试策略的，我就反复讲。记得五六年前在招行的时候就因为测试策略有问题导致该反应出来的性能问题反应不出来。    

    在这个项目中，又有这样讲策略的机会了。在上面的图中，问题不在于出现错误和资源用完，而在于响应时间在成倍的增加。在这种情况下，不应该往上加用户，而应该往下减用户，让响应时间的增加趋势显示出来。

    在性能分析中，趋势是非常重要的一个点。线程也不是一下子从高并发开始，如果一个用户执行的时候需要100ms，10个用户到了200ms，这是不是问题呢？那肯定是问题。

    就在刚才，另一个团队成员测试另一个系统的时候说，响应时间没增加，TPS没增加，资源也没增加，也没出错。我一听，就明显是不合理的。让他们折腾了几个小时再告诉我问题在哪。后来还是没给告诉我问题在哪，我过去翻了下，发现响应时间在10个用户的时候是100ms，40个用户的时候是500ms。这还不叫问题？顿时有种想拿呼啦汤砸人的感觉。

    最近上海多雨，而团队中成员又比较负责，有人问了，这有啥关系？憋急，听我慢慢道来。

    昨天晚上一个同事为了跑稳定性，一直折腾到11点，我一直陪着。而其他人看我没走，也都没走。（是不是我太有魅力了？嗯，很有可能。）

    其实之前我是跟他们说，今天的事情做完了就先走。

    一向带项目，我都是事情驱动，耗时间，我非常不赞同。所以事情排下去了，就个人负责个人的事情，但是对一些没有责任感的人来说，就得多盯着点。

    回来说为啥说下雨，那个同事一直捣鼓，到了11点还没走，而我带项目又有个原则，来的最早，走得最晚。如果一个PM经常自己不加班，而让成员老加班，那肯定会心里不顺。所以为了让他们心里平衡，在我带小团队的时候，基本上是最晚的一个。哈哈，这是不是可以称为苦肉计？

    昨晚我们一出门，发现正在下雨，并且还有越下越大的趋势。几个人找了几个自行车，往酒店骑，结果越骑越大。这一路也是骑着车，唱着歌，好不热闹。哈哈。

    回去发现都淋湿了。

    多年后，回想起来这一段，那也是很有触感的。

    昨天我跟他们说，初入道的加入这个项目真是太划算了，因为这个项目中遇到的问题，可以说是性能问题的教科书。