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

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

    还是出现了各种差错。

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

    我倒是习惯了这种状态。

    只是时间不等人。

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

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

    线还这么乱！

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

    10倍的差距！！

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

    多么粗心的错误。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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