全链路压测系列到这里,已经是第十二篇文章了,整个系列大概有14篇的样子,预计这个月会更新完毕。前面的文章,我用了很多的篇幅介绍了在事前调研和准备阶段要做的事情,为什么要花这么多篇幅介绍前期的准备工作呢?因为全链路压测严格来讲,并不是一个单纯的测试手段,而是一整套团队协作和稳定性保障的技术体系。
当然,这个系列文章叫做叫做生产全链路压测,那肯定少不了在线上生产环境的压测实践。这篇文章,为大家介绍下在生产环境都是如何开展压测的,以及压测过程要注意哪些事项。
在生产环境开展全链路压测,相对于测试环境来说风险和成本都是比较大的。因此需要一套严格的流程管控和响应机制,以及高效的团队协同体系。
当然,由于成本和风险问题,全链路压测本身只适合部分企业,而非一个放之全行业通用的技术银弹。即使在少部分落地了生产全链路压测的企业来说,常态化的全链路压测也是很难的。
下面是一个在电商企业双11大促时候的生产全链路压测实施过程,仅做示例参考。
生产压测其实和我们日常的压测没有太多区别,也是需要经过多轮的压测实施和问题分析定位优化才能完成。在生产执行压测阶段,一般会根据业务活动情况倒序排期,制定压测轮次和每个轮次的主要目标及TODO项。
下面是我之前某次大促的压测计划排期:
瓶颈定位和优化验证是性能优化和稳定性保障之中很重要的环节。
由于生产压测大多是在流量低峰的夜间进行,压测实施时间有限,一般比较复杂的性能问题都是在事后线下环境进行优化验证。而且涉及到比较复杂的业务场景和系统调用关系时,也很难快速的找到性能瓶颈。
遇到这个问题时,常用的临时解决办法是将影响性能的链路进行mock处理,待线下环境优化验证后,再次合并到链路中进行压测验证。生产压测会暴露很多问题,下面列举一些常见问题:
由于生产压测的时间窗口有限,一般都会将压测过程遇到的问题全部进行记录,便于事后组织复盘和跟进,在记录相关信息时,重点需要关注如下几点:
下面是之前我在某次大促复盘时整理的问题以及TODOList,仅供参考。
PS:复盘的目的是更明确问题的影响面和快速解决,需要聚焦问题,而不是甩锅指责!
在类似双11大促这种大型业务营销活动的稳定性保障时,需要注意如下几个方面:
在上一篇文章中,我们提到了稳定性预案的作用,到这个阶段,就需要针对线上的部分预案进行执行和oncall响应。类似双11这种大型的业务营销活动,预案也会分前置预案和活动预案以及紧急预案。
在执行前置预案时,我的实践经验主要有如下三点:
监控响应实际上更多的是一种工作流机制,即针对不同信息,由不同的人在预定的时间范围内响应处理。监控方面,除了我们常见的基础资源监控(CPU/内存/网络/磁盘)、应用监控(QPS/JVM/threadgroup)、链路追踪监控(trace)之外,还有业务监控大盘、核心链路监控大盘等。
因为技术方面的监控,除了及时的告警通知之外,监控的及时性和准确性以及噪音,有时候会影响我们判断。这个时候业务监控大盘的作用就体现了出来。
业务监控大盘的目的在于:无论技术侧是否发现了问题,只要业务指标的变化数据存在异常,就需要及时介入观察。
如上就是生产压测比较重要的一些环节要做的事情以及注意事项。
后面应该还有2篇文章,为大家介绍一些性能优化的实践和原则,尽请关注。