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

项目经过了,8 个业务系统和 7 个基础架构系统的测试之后,又完成了全链路的两个域的测试,终于进入了尾声。
过程中发现了 257 个问题(只统计了 8 个业务系统),平均每个系统 32.125 个。问题 age 达到 861.77 天,平均每个 3.35 天。
当然还有系统细分和类型细分。
这些内容不仅只是一个数据的罗列,如果企业领导层有 sense 的话,
对于一个系统来说,这个结果明显是系统的初始阶段。所以也是合理的。
还好从结果来看,还是满足当前的业务需求。但是有些问题就必须要解决了,不然存在上线风险。
这些也都在最后的报告中标识出来了。
并且业务系统可支持的最大 TPS 也在报告中有标识。有些可以超过几十倍,有些有 1 倍多。举例如下(有几个系统的 TPS 删掉了,因为会把其他系统的全都压扁):
团队管理之性能实施团队日志13_第1张图片

性能调优的目标是满足生产的业务压力。对一些风险点能把控得了。
有人可能觉得最大 TPS 只比目标 TPS 多了那么一点,是不够的,还需要做优化。
如果项目周期允许,对一些系统还是可以再做优化的,可是周期内,人精力有限,只能告诉客户以后哪些系统要做哪些优化方向,希望他们能持续提高能力。
所以在我的 PPT 和 word 版本的报告中会提到后续各系统的优化目标,以及性能优化后续要做的事情和整体的目标,以及架构级的调整方向。
能不能把握得了就要看这客户的执行力度了。

今天在整理报告的时候,发现不知不觉写了好多内容。
PPT的报告有 92 个 slides。word 版本的性能实施报告有 245 页。性能优化整理的 word 报告有 190 页。
经过一轮轮的查看,内容都是有价值的。
两个多月的项目,交付出来这样的结果,从我自己的经验上来说,算是比较满意的了。
从项目的一开始觉得风险很高,到过程的折磨,折腾,到最后满意的结果,这个过程只有经历过的才知道。
项目组的各同事也都比较努力,加班加点的时候也没有报怨。

昨天小团队内部一块吃晚饭,还有一个安徽怀远土特产。吃得挺开心。
团队管理之性能实施团队日志13_第2张图片

这周末不加班,打算租个车带项目组的同事出去旅个游。
只是祖国大地都是热,想来想去,也不知道哪里好玩,估计只有树比较多的大山深处才能凉快点了吧。
结果聊来聊去,觉得出去玩还是不够有吸引力,毕竟景点嘛,都是那个样子。
于是换了个玩法。

组织活动如下:

  • 12:00 茶馆玩狼人杀
  • 16:50 看电影《大护法》
  • 18:30 看完去吃饭
  • 19:50 KTV

接近尾声的时间还有件事情是必须要做的,那就是归档文件。
昨天到今天,我一直在整理文件。把每个项目的脚本、场景、结果、报告分别归档。最后终于把文件目录整理得像样子了。共 15 个G的内容。
每个项目的结束,我都会做这样的事情。
我自持不是脑力惊人的,有些自己做的事情都会忘掉。只有回去查自己写的东西。
有时上网搜索资料,都能搜到自己之前写过的东西。想想也是自伤。

项目的整理,其实都是为了自己。而不是为了交差。
自毕业工作到现在以来,我自己做过的项目都有保存。还有多年前做过的客户问我要当时的报告的。

对企业内部来说,不止是这样的归档可以留下项目资产。更重要的是要可持续地提高团队能力。
而我看到的、经历的企业很少有做知识积累做得好的,基本上项目结束,除了个报告,其他东西都扔掉了。
知识是随着人走的,而归档后,才是公司资产的累积。

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

你可能感兴趣的:(管理,性能测试,性能分析)