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

这几天算是多事之秋。本来就有几个严重的问题天天在折腾。
还是出现了各种差错。
其实对于做项目来说，就是这样，总会有紧要的事情突然冒出来。
我倒是习惯了这种状态。
只是时间不等人。

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

目标 TPS 拆分到这个业务上有 27.7，但是混合只跑到了 4 个TPS。稳定性中只有 2.5 个。
线还这么乱！
然后我就问他们这线程的比例是怎么配置的。我看到在计算的表格里，这个业务基准响应时间是 0.03s。但是我看了基准测试的结果，这个业务的响应时间是 0.4s 左右。
10倍的差距！！
一个数据的错误导致了混合、稳定性都要重跑。
多么粗心的错误。

这还不算完，还有一个系统，混合容量跑到了最大TPS 230左右，结果一看稳定性的TPS， 250？！
明显解释不通。也得重跑。

还有一个系统到现在还没混合的起来。不是这有问题就是那有问题。
结果今天这个系统的生产环境也出了问题，他们想来想去，就跑到正在做性能测试的生产环境做验证了。这也是影响了进度。

最近可能也是要到了项目快结束的时候，问题反而越来越多了。
如果是我完全能控制的项目的话，当前这种情况是真正的受不了。
但是看客户这样也能运行下去，倒也是符合大部分项目的路子。

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

项目的上线是不是可以带着问题上线？那是肯定可以的。只要不是阻塞性的问题。
而性能问题更是这样。有很多系统都是带着性能问题跑在生产上的。
但是前提是，你知不知道生产上有这样的性能问题？
如果知道还可以想办法避免，如果不知道呢？那就只能等着这个雷自己炸。

我在写最后的总结和建议时，有针对运维的建议。
比如说，这个系统能承受的最大的业务量是 600 万笔，那在这之前就要考虑维护动作了。这就是要加紧监控。

性能要想有意义，也必须和生产环境中运行的状态结合起来。所以性能人员做一段时间的生产问题支持是非常有必要的。
把自己的测试结果和生产环境做比对，看哪些场景做的有缺失。
对我这样到处做项目的，还比较难做得到。但是对在公司内部做性能的，是可以做得到的。
比如说我们设计异常场景，要考虑的就是生产上的异常是怎么出现的。像扩容这件事情，本来在生产上是很正常的事情，但是在这个项目中，扩容在开始还会导致 TPS 下降，这也是我之前没遇到的。
比如说我们设计稳定性场景，也是要计算生产上稳定运行的场景。
其实对这类的项目，还有要设计的性能场景没有做，只是也没有时间再做了。之前计划中也没考虑进去。
另外控制项目的进度，在这个项目中，我觉得我已经挺强势地在控制了。性能项目在很多地方做得都很悲凉，我只是希望能按正常的方式来做事情。

我在各场合都不夸大性能实施项目和性能测试、分析人员的价值，我觉得对生产有用就是有价值，不然就是没意义的。
而把性能做到和生产联动，到现在为止，还是在很多企业都做得不好。