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

zuozewei 发表于 2022/01/26 22:35:17 2022/01/26
【摘要】 团队管理之性能实施团队日志12

几天算是多事之秋。本来就有几个严重的问题天天在折腾。

    还是出现了各种差错。

    其实对于做项目来说,就是这样,总会有紧要的事情突然冒出来。

    我倒是习惯了这种状态。

    只是时间不等人。

    这两天在写各系统的最终报告。结果写到某个系统的时候发现,咦,业务量怎么这么低。

图片

    目标TPS拆分到这个业务上有27.7,但是混合只跑到了4个TPS。稳定性中只有2.5个。

    线还这么乱!

    然后我就问他们这线程的比例是怎么配置的。我看到在计算的表格里,这个业务基准响应时间是0.03s。但是我看了基准测试的结果,这个业务的响应时间是0.4s左右。

    10倍的差距!!

    一个数据的错误导致了混合、稳定性都要重跑。

    多么粗心的错误。


    这还不算完,还有一个系统,混合容量跑到了最大TPS 230左右,结果一看稳定性的TPS, 250?!

    明显解释不通。也得重跑。

    

    还有一个系统到现在还没混合得起来。不是这有问题就是那有问题。

    结果今天这个系统的生产环境也出了问题,他们想来想去,就跑到正在做性能测试的准生产环境做验证了。这也是影响了进度。

    

    最近可能也是要到了项目快结束的时候,问题反而越来越多了。

    如果是我完全能控制的项目的话,当前这种情况是真真的受不了。

    但是看客户这样也能运行下去,倒也是符合大部分项目的路子。

    

    最近在写分析报告的时候,又在异常中发现了一个启动业务实例TPS反而下降的情况。分析到最后是因为启动顺序的原因。感觉上问题不是特别严重。但是也不能忽视。因为不止是重启时会出现,在实例扩展时也会出现问题。

    所以让每个出现这个问题的系统都提了一个问题做记录。

    

    项目的上线是不是可以带着问题上线?那是肯定可以的。只要不是阻塞性的问题。

    而性能问题更是这样。有很多系统都是带着性能问题跑在生产上的。

    但是前提是,你知不知道生产上有这样的性能问题?

    如果知道还可以想办法避免,如果不知道呢?那就只能等着这个雷自己炸。


    我在写最后的总结和建议时,有针对运维的建议。

    比如说,这个系统能承受的最大的业务量是600万笔,那在这之前就要考虑维护动作了。这就是要加紧监控。

    

    性能要想有意义,也必须和生产环境中运行的状态结合起来。所以性能人员做一段时间的生产问题支持是非常有必要的。

    把自己的测试结果和生产环境做比对,看哪些场景做得有缺失。

    对我这样到处做项目的,还比较难做得到。但是对在公司内部做性能的,是可以做得到的。

    比如说我们设计异常场景,要考虑的就是生产上的异常是怎么出现的。像扩容这件事情,本来在生产上是很正常的事情,但是在这个项目中,扩容在开始还会导致tps下降,这也是我之前没遇到的。

    比如说我们设计稳定性场景,也是要计算生产上稳定运行的场景。

    其实对这类的项目,还有要设计的性能场景没有做,只是也没有时间再做了。之前计划中也没考虑进去。

    另外控制项目的进度,在这个项目中,我觉得我已经挺强势的在控制了。性能项目在很多地方做得都很悲凉,我只是希望能按正常的方式来做事情。


    我在各场合都不夸大性能实施项目和性能测试、分析人员的价值,我觉得对生产有用就是有价值,不然就是没意义的。

    而把性能做到和生产联动,到现在为止,还是在很多企业都做得不好。

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

评论(0

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

全部回复

上滑加载中

设置昵称

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

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

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