全链路压测(12):生产压测必不可少的环节

本文涉及的产品
性能测试 PTS,5000VUM额度
简介: 在生产环境开展全链路压测,相对于测试环境来说风险和成本都是比较大的。因此需要一套严格的流程管控和响应机制,以及高效的团队协同体系。

前言


全链路压测系列到这里,已经是第十二篇文章了,整个系列大概有14篇的样子,预计这个月会更新完毕。前面的文章,我用了很多的篇幅介绍了在事前调研和准备阶段要做的事情,为什么要花这么多篇幅介绍前期的准备工作呢?因为全链路压测严格来讲,并不是一个单纯的测试手段,而是一整套团队协作和稳定性保障的技术体系。


当然,这个系列文章叫做叫做生产全链路压测,那肯定少不了在线上生产环境的压测实践。这篇文章,为大家介绍下在生产环境都是如何开展压测的,以及压测过程要注意哪些事项。


在生产环境开展全链路压测,相对于测试环境来说风险和成本都是比较大的。因此需要一套严格的流程管控和响应机制,以及高效的团队协同体系。


当然,由于成本和风险问题,全链路压测本身只适合部分企业,而非一个放之全行业通用的技术银弹。即使在少部分落地了生产全链路压测的企业来说,常态化的全链路压测也是很难的。


下面是一个在电商企业双11大促时候的生产全链路压测实施过程,仅做示例参考。


执行压测和问题处理


生产压测其实和我们日常的压测没有太多区别,也是需要经过多轮的压测实施和问题分析定位优化才能完成。在生产执行压测阶段,一般会根据业务活动情况倒序排期,制定压测轮次和每个轮次的主要目标及TODO项。


下面是我之前某次大促的压测计划排期:


640.png


瓶颈定位和优化验证


瓶颈定位和优化验证是性能优化和稳定性保障之中很重要的环节。


由于生产压测大多是在流量低峰的夜间进行,压测实施时间有限,一般比较复杂的性能问题都是在事后线下环境进行优化验证。而且涉及到比较复杂的业务场景和系统调用关系时,也很难快速的找到性能瓶颈。


遇到这个问题时,常用的临时解决办法是将影响性能的链路进行mock处理,待线下环境优化验证后,再次合并到链路中进行压测验证。生产压测会暴露很多问题,下面列举一些常见问题:


  1. 数据准备不足和数据预热问题;
  2. 各团队资源投入度和信息同步问题;
  3. 基础的技术平台支撑问题(快速发布、紧急扩容、监控告警);
  4. 前期的技术准备和梳理不足(如链路依赖及限流降级熔断措施);
  5. 线上操作流程和权限管控问题(临时发布、业务变更及push等);


每日复盘和事项跟进


由于生产压测的时间窗口有限,一般都会将压测过程遇到的问题全部进行记录,便于事后组织复盘和跟进,在记录相关信息时,重点需要关注如下几点:


  1. 问题暴露时间(便于事后复盘和排查问题时,查看对应时间段的监控和日志);
  2. 问题归属团队(由于生产压测涉及的业务和团队较多,需要明确拆分工作,各自跟进);
  3. 问题归属人员(确定问题主要归属人员,主要是便于能投入全部精力来跟进解决问题);
  4. 问题影响范围(根据影响范围来评估问题的优先级和严重性,并做好信息同步,避免问题扩大);
  5. 问题deadline(需要明确问题的最后解决时间,避免某个环节的block影响全局的压测目标达成);


下面是之前我在某次大促复盘时整理的问题以及TODOList,仅供参考。


问题风险


640.png


TODOList


640.png


PS:复盘的目的是更明确问题的影响面和快速解决,需要聚焦问题,而不是甩锅指责!


发布上线和封版值班


在类似双11大促这种大型业务营销活动的稳定性保障时,需要注意如下几个方面:


  1. 原则上除了和大促相关的变更,其他需求变更或者配置变更都需要顺延;
  2. 活动开始前和业务产品明确封版时间,避免版本发布导致链路依赖的变化;
  3. 在最终的性能优化版本发布后,线上的值班和oncall需要有专门的排班机制;
  4. 紧急发布和临时变更需要有审批流程和实时oncall及回滚机制,避免发布导致问题扩大;


预案执行和监控响应


在上一篇文章中,我们提到了稳定性预案的作用,到这个阶段,就需要针对线上的部分预案进行执行和oncall响应。类似双11这种大型的业务营销活动,预案也会分前置预案和活动预案以及紧急预案。


预案执行


在执行前置预案时,我的实践经验主要有如下三点:


  1. 制定具体的预案执行时间和执行人以及验证人;
  2. 执行预案和线上验证及观察阶段,相关人员最好集中在一起;
  3. 前置预案需要分批执行,避免同时执行多个预案(假设出现问题,也能快速定位问题原因);


监控响应


监控响应实际上更多的是一种工作流机制,即针对不同信息,由不同的人在预定的时间范围内响应处理。监控方面,除了我们常见的基础资源监控(CPU/内存/网络/磁盘)、应用监控(QPS/JVM/threadgroup)、链路追踪监控(trace)之外,还有业务监控大盘、核心链路监控大盘等。


因为技术方面的监控,除了及时的告警通知之外,监控的及时性和准确性以及噪音,有时候会影响我们判断。这个时候业务监控大盘的作用就体现了出来。


业务监控大盘的目的在于:无论技术侧是否发现了问题,只要业务指标的变化数据存在异常,就需要及时介入观察。


如上就是生产压测比较重要的一些环节要做的事情以及注意事项。


后面应该还有2篇文章,为大家介绍一些性能优化的实践和原则,尽请关注。

相关实践学习
通过性能测试PTS对云服务器ECS进行规格选择与性能压测
本文为您介绍如何利用性能测试PTS对云服务器ECS进行规格选择与性能压测。
相关文章
|
7月前
|
负载均衡 NoSQL 关系型数据库
性能基础之全链路压测知识整理
【2月更文挑战第16天】性能基础之全链路压测知识整理
321 11
|
7月前
|
存储 缓存 中间件
高可用之全链路压测
【2月更文挑战第30天】全链路压测是提升系统可用性的关键方法,它模拟真实流量和业务场景在生产环境中测试,确保性能、容量和稳定性。
|
监控 测试技术 UED
《云上业务稳定性保障实践白皮书》——五.行业客户稳定性保障实践——5.3 平台网站业务稳定性保障——5.3.2 全链路压测与容量评估(1)
《云上业务稳定性保障实践白皮书》——五.行业客户稳定性保障实践——5.3 平台网站业务稳定性保障——5.3.2 全链路压测与容量评估(1)
304 0
|
域名解析 网络协议 数据可视化
《云上业务稳定性保障实践白皮书》——五.行业客户稳定性保障实践——5.3 平台网站业务稳定性保障——5.3.2 全链路压测与容量评估(2)
《云上业务稳定性保障实践白皮书》——五.行业客户稳定性保障实践——5.3 平台网站业务稳定性保障——5.3.2 全链路压测与容量评估(2)
215 0
|
SQL 监控 关系型数据库
《云上业务稳定性保障实践白皮书》——五.行业客户稳定性保障实践——5.3 平台网站业务稳定性保障——5.3.2 全链路压测与容量评估(3)
《云上业务稳定性保障实践白皮书》——五.行业客户稳定性保障实践——5.3 平台网站业务稳定性保障——5.3.2 全链路压测与容量评估(3)
207 0
|
数据可视化 测试技术 定位技术
全链路压测(14):生产全链路压测SOP
从实践经验的角度出发,生产全链路压测在技术实现上没有太多新花样,但要在不同的业务和企业落地,就各有各的实践路径。对于没有太多经验的同学来说,全链路压测的落地,大多还是基于个人的经验和熟悉的领域,即都是在局部作战,缺乏全局的视角和可视化地图。从全局来讲,缺少适用于自己的全链路压测最佳实践。
全链路压测(14):生产全链路压测SOP
|
存储 SQL 缓存
全链路压测(13):高可用和性能优化
业务场景复杂化、海量数据冲击下,发现并解决业务系统的可用性、扩展性以及容错性问题。
全链路压测(13):高可用和性能优化
|
2月前
|
测试技术 持续交付 Apache
Python性能测试新风尚:JMeter遇上Locust,性能分析不再难🧐
【10月更文挑战第1天】Python性能测试新风尚:JMeter遇上Locust,性能分析不再难🧐
170 3
|
3月前
|
测试技术 数据库 UED
Python 性能测试进阶之路:JMeter 与 Locust 的强强联合,解锁性能极限
【9月更文挑战第9天】在数字化时代,确保软件系统在高并发场景下的稳定性至关重要。Python 为此提供了丰富的性能测试工具,如 JMeter 和 Locust。JMeter 可模拟复杂请求场景,而 Locust 则能更灵活地模拟真实用户行为。结合两者优势,可全面评估系统性能并优化瓶颈。例如,在电商网站促销期间,通过 JMeter 模拟大量登录请求并用 Locust 模拟用户浏览和购物行为,可有效识别并解决性能问题,从而提升系统稳定性和用户体验。这种组合为性能测试开辟了新道路,助力应对复杂挑战。
124 2
|
1月前
|
测试技术 持续交付 Apache
Python性能测试新风尚:JMeter遇上Locust,性能分析不再难🧐
Python性能测试新风尚:JMeter遇上Locust,性能分析不再难🧐
79 3