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

举报
zuozewei 发表于 2022/01/22 18:25:21 2022/01/22
【摘要】 团队管理之性能实施团队日志8

带这个团队快有一个月了,我觉得内部磨合以及外部沟通基本上形成了固定的策略。

    性能实施有两个重要的worker阶段。

  1. 写脚本、做参数、定场景;

  2. 分析、调优。

    我觉得第一个阶段整体感觉上没有问题了,除了还出现一些服务配置、数据之类的问题之外,压力上除了有两个系统还没有压起来过之外,其他的都基本上把性能问题在慢慢的暴露了。

    那这最关键的分析调优的阶段就必然要跟上节奏了。

    分析调优要做到什么程度呢?如果能有下面这样的响应时间对比图,那就明显不过了;

   还是要说调优的思路,因为这几天我在跟8个项目组沟通。而有些项目组中基本上是靠蒙的。突然之间就想到要改某个参数。如果能蒙一次对了、蒙两次也对了,我绝对相信这是个巨牛逼的人了。但是一次两次的失望,我觉得有点承受不了。

    在我们这个临时拼凑出来的小团队中,我也是这样要求的,跟别的团队的沟通,要证据确凿!没证据,跟人说瓶颈在哪儿,那太不像是专业的性能分析团队该干的事了。

    今天我看一个项目组说,要把jdbc从40改到1000。可是据我所知,这个数据库根本没几个忙的线程。我就不理解为什么要调jdbc?就问他们为什么要调,他们说:从日志里看到取不到线程池,所以试试。我说,那你们把证据发给我看看,我想知道你们分析的思路。结果也没给我发出有力的证据。我只能怀疑这个又是蒙的。而这个项目组,我已经眼睁睁着他们的方向性错误,好几天了。

    而PM还要关注的是整体的状态,昨天我看了一下问题。问题出现率还是挺高的。总问题已经记到141个了。其中也有功能问题,但是70%以上是性能问题。对8个系统来说,一个系统十几个性能问题,从经验上来说,似乎差不多了。但是真正的测试还没有开始。

(之前有78个问题没放到jira中,所以在jira中只能看到63个。)

    预计这个项目中出现的问题,会走过两百了,至少。对一个性能团队来说,能发现这么多问题。也已经算是多的了。

    从8个系统的各进度来看,整体上来说,有一个团队的进度非常有风险,其他的还尚在可控范围之内。

    这两天因为有一个培训,所以又要离开项目组两天。走之前我安排的本周工作目标是:每个系统都能把混合场景跑起来,要是跑不起来,那就加班。把相应的开发组拉着加班。

    今天是6月15日了,从上次移了两次项目计划来看,我们的整体计划还是非常有可能推迟到7月中旬,如果那样的话,我觉得就非常危险了。从我带性能项目的经验上来看,项目推迟半个月,从PM的角度上来说已经是失败的项目了。

   

    可是性能项目就是这样,它不仅依赖着开发团队、基础设施(或数据中心)等团队,还依赖着领导层的重视力度,这个领导层的含义不仅仅是最上层的领导,还有中层的领导以及中低层的领导。

    有些小leader的技术和思路还没有那么完整,问题的理解和团队的沟通都不够深入。经常出现你说你的,我说我的情况。

    中间总是有那么一小段双方都不送过去。就像前几天出现一个写Cache之后取不到的问题。基础架构那边说,你业务方写进去了成没成功是有返回判断的呀?业务方说,我写成功了呀,但是你cache取不到,当然是你cache的问题了。这一段车轱辘话说了两天,两方都仍然不往前走。最后在我开会的时候又说了一遍。实在忍不了这种的沟通方式。

    从我的经验上来看,我觉得沟通比技术难题耗费的时间多得多。技术不行,还能上网查查,再不济还能找人问问。

    但是沟通产生的时间消耗是和每个人的处事方法、思维能力、说话能力、品质都有关系。同一件事情,不同的两个人沟通,可能是1:10的差距。

    然而悲催的是性能项目(其他项目也应该类似)需要的沟通尤其的多。

    上次开PMO会的时候有三个项目组的人迟到大概10分钟左右,房间里有20多个人等着。我想这种情况应该比较常见。但是如果太常见了那就不正常了。

    鉴于前几次开会总是有人迟到的情况,于是会上我说,后面我们会发正式的meeting request(之前是约定俗成的时间,开会前在微信群里喊一声),每周的固定时间开会,同时我也把开会的时间从之前的一个小时缩减到30-40分钟。会议分成三个阶段:1. Brief;2. 过问题列表,但是一个问题如果讨论超过两分钟的就停止,移到会后或另开会讨论;3. 各项目组对性能实施的意见或建议;这一句我每次开会都问,但是没看到有人提出异议。

    并且如果以后还有人开会迟到导致有些事情没有听到就讨论完了,那也只能按讨论的结果来做。这就可以默默的给人安排活了呀。哈哈。

    前面提了好几次,我觉得有问题的点,我看到有人觉得我小题大做了。比如说,我提到没有完整的系统架构图和overall架构文档。他们一直告诉我,有的呀。之前每个团队都有画呀。我说我要看到物理拓扑架构图和逻辑架构图。而之前各团队画的都是简单的几个机器的简单的物理拓扑图,也没有系统间的connection、数据流转说明之类的。而逻辑架构图就更不用说了,我就没看到过。  

    难道现在做项目连架构图都可以不用画了吗?还是说我落伍了,这种overview picture是不需要的?

    后来他们问我,你说的架构图是啥样的哩?我默默地搜索了一个linux的内核架构图给他们看了一眼。看,就这样的。

    带团队还要注意的是团队的能力结构,可以拆分的事情尽量拆分。但是要注意拆分之后的前后衔接,这个衔接的动作要PM来完成。 如果明显觉得团队能力不够了,那就要想着迅速提升,或者让他们知道一些常规的判断问题的手段,能取出数据来也好。

    如果实在带不起来,也只能认命了。毕竟人生苦短。

    带团队有辛苦,也有乐趣,关键是团队要有成长。

【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

举报
请填写举报理由
0/200