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

    项目经过了，8 个业务系统和 7 个基础架构系统的测试之后，又完成了全链路的两个域的测试，终于进入了尾声。

    过程中发现了 257 个问题（只统计了 8 个业务系统），平均每个系统 32.125 个。问题age达到 861.77 天，平均每个 3.35 天。

    当然还有系统细分和类型细分。

    这些内容不仅只是一个数据的罗列，如果企业领导层有sense的话，

    对于一个系统来说，这个结果明显是系统的初始阶段。所以也是合理的。

    还好从结果来看，还是满足当前的业务需求。但是有些问题就必须要解决了，不然存在上线风险。

    这些也都在最后的报告中标识出来了。

    并且业务系统可支持的最大TPS也在报告中有标识。有些可以超过几十倍，有些有 1 倍多。举例如下（有几个系统的TPS删掉了，因为会把其他系统的全都压扁）：

    性能调优的目标是满足生产的业务压力。对一些风险点能把控得了。

    有人可能觉得最大TPS只比目标TPS多了那么一点，是不够的，还需要做优化。

    如果项目周期允许，对一些系统还是可以再做优化的，可是周期内，人精力有限，只能告诉客户以后哪些系统要做哪些优化方向，希望他们能持续提高能力。

    所以在我的PPT和word版本的报告中会提到后续各系统的优化目标，以及性能优化后续要做的事情和整体的目标，以及架构级的调整方向。

    能不能把握得了就要看这客户的执行力度了。    

    今天在整理报告的时候，发现不知不觉写了好多内容。

    PPT的报告有92个slides。word版本的性能实施报告有245页。性能优化整理的word报告有190页。

    经过一轮轮的查看，内容都是有价值的。

    两个多月的项目，交付出来这样的结果，从我自己的经验上来说，算是比较满意的了。

    从项目的一开始觉得风险很高，到过程的折磨，折腾，到最后满意的结果，这个过程只有经历过的才知道。

    项目组的各同事也都比较努力，加班加点的时候也没有报怨。

    昨天小团队内部一块吃晚饭，还有一个安徽怀远土特产。吃得挺开心。

    这周末不加班，打算租个车带项目组的同事出去旅个游。

    只是祖国大地都是热，想来想去，也不知道哪里好玩，估计只有树比较多的大山深处才能凉快点了吧。

    结果聊来聊去，觉得出去玩还是不够有吸引力，毕竟景点嘛，都是那个样子。

    于是换了个玩法。

    组织活动如下：

    12：00 茶馆玩狼人杀  

    16：50 看电影《大护法》 

    18：30 看完去吃饭  

    19：50 KTV    

    接近尾声的时间还有件事情是必须要做的，那就是归档文件。

    昨天到今天，我一直在整理文件。把每个项目的脚本、场景、结果、报告分别归档。最后终于把文件目录整理得像样子了。共15个G的内容。

    每个项目的结束，我都会做这样的事情。

    我自持不是脑力惊人的，有些自己做的事情都会忘掉。只有回去查自己写的东西。

    有时上网搜索资料，都能搜到自己之前写过的东西。想想也是自伤。

    项目的整理，其实都是为了自己。而不是为了交差。

    自毕业工作到现在以来，我自己做过的项目都有保存。还有多年前做过的客户问我要当时的报告的。

    对企业内部来说，不止是这样的归档可以留下项目资产。更重要的是要可持续地提高团队能力。

    而我看到的、经历的企业很少有做知识积累做得好的，基本上项目结束，除了个报告，其他东西都扔掉了。

    知识是随着人走的，而归档后，才是公司资产的累积。

    下周一是对客户领导层和相关团队负责人做报告的时间，前前后后的话也想了一圈了，最后能说出来的不知道有几分。