拒做背锅侠!如何利用网站性能优化驱动产品体验提升

本文涉及的产品
应用实时监控服务-应用监控,每月50GB免费额度
应用实时监控服务-用户体验监控,每月100OCU免费额度
可观测可视化 Grafana 版,10个用户账号 1个月
简介: 对于运维工程师而言,如果要票选五大最抓狂运维支撑场景,花样繁多的各种促销活动一定榜上有名。每个促销季上线都是忐忑不安的不眠夜。大量内容更新、大量客户涌入,大量数据读写,虽有着各种技术方案或工具服务保障着大促顺利进行。但仍有可能收到譬如“商品图片加载不出来”、“页面打开缓慢”、“无法完成订单支付”等诸多各地用户投诉。这些由于用户体验与网站性能造成的用户转化低、业务增长缓慢等糟糕结果,最终都会让运维工程师成为“众望所归”的背锅侠。

白屿


对于运维工程师而言,如果要票选五大最抓狂运维支撑场景,花样繁多的各种促销活动一定榜上有名。每个促销季上线都是忐忑不安的不眠夜。大量内容更新、大量客户涌入,大量数据读写,虽有着各种技术方案或工具服务保障着大促顺利进行。但仍有可能收到譬如“商品图片加载不出来”、“页面打开缓慢”、“无法完成订单支付”等诸多各地用户投诉。这些由于用户体验与网站性能造成的用户转化低、业务增长缓慢等糟糕结果,最终都会让运维工程师成为“众望所归”的背锅侠。


针对「用户体验与网站性能」问题,我们与众多企业运维工程师以及独立站长展开访谈,发现大家的观点集中在以下方面:


(一)「产品与用户体验之间的差距」带来的性能与体验问题


由于互联网红利消退,产品功能与用户体验设计越发内卷。产品功能逻辑设计与用户使用时的理解存在差距,大量秒杀活动、推广活动、UGC内容让产品逻辑愈发复杂,哪怕提供了各种引导与说明文档,用户仍然需要时间理解并培养使用习惯。与此同时,为了让功能模块进一步丰富,大量富媒体、第三方组件、客户广告不断被添加进来,对外合作内容过多且不合理,加重系统负载,拖累产品性能。既要、又要、还要,最终的代价就是不得不牺牲一定的网站性能与用户体验。


8fe1b33073c24c118165a4ef6745a651.png

(二)「错综复杂的网络环境」带来的性能与体验问题

众所周知,全国各地充斥着各种各样一级、二级运营商,这大幅提升了全国网络环境复杂度,由于运营商基础架构更新慢、突发性人为问题多,造成会经常性的IDC故障,企业只能安抚用户并躺平等待修复,而这些问题的排查耗时都只能听天由命。与此同时,广阔的地域分布、零散的用户分布及个性化入网方式造成接入网络复杂,企业对于用户使用环境无法有效估量。哪怕借助广泛分布的数据中心以及多线BGP接入,想要解决网络环境问题仍旧捉襟见肘,这进一步加剧了网络环境的优化难度,让真实用户的实际使用体验更加难以预测。



416efc3fa12a4267aa1a794b4168798e.png

(三)「差异明显的PC端环境」差异带来的性能与体验问题

作为世界上拥有最大网民规模的国家,我国这些海量用户规模背后是巨大的用户端硬件配置差异,可能有人使用着 i9-11900K+RTX3080 Ti 在 bilibili 上看 4K 高清直播视频,也有人用着千禧年发布的 Pentium 4 与集成显卡在门户网站浏览文字新闻。这造成不同浏览器版本、自身渲染机制、本地主机性能差异的不同群体,存在譬如访问异常、慢速、本地资源消耗等用户体验差异。面对这一状况,如何去了解广大用户实际体验情况,平衡或评估用户端体验差异,在其中进行取舍成了每个网站运维与研发必须面对的难题。


61e9f717ad2745cabe49945885a5b05f.png

(四)「追求迭代速度的后遗症」带来的系统可用性保障问题

由于互联网竞争疯狂内卷,产品在功能窗口期与精细调优这道选择题上,不得不选择性忽视产品架构与稳定性。架构不严谨、业务发展超越架构支撑能力造成系统负载过载、导致系统崩溃、响应超时等问题,造成这一问题的因素很多:

首先,业务迭代速度非常快,侵入式监控手段无法在短时间落地,但业务系统出现故障时需要快速感知;

其次,开发资源紧张或不配合,基础设施相关监控又不能直接反应业务问题,应用监控实施成本太高。

最后,自身应用调用第三方API接口,第三方API接口的可用性无法保障,出故障了无法及时响应和处理。

拆解来看,我们会觉得这些都是单点问题,但业务上量后出现连锁反应,就会将这些问题叠加放大,直接影响用户体验。



a057b5dd12cc42c0acf7094957820fa2.png

(五)「缺乏用户视角的监控手段」导致应对客诉比较被动

虽然产品功能在上线时会经过各种测试,运营团队也持续关注用户使用情况。但对运维团队而言,只有客户投诉后才知道系统发生了问题,应对起来十分被动,甚至异常复现、定位问题可能就要花费一天时间,严重影响NPS;常见监控手段也大多从自身视角出发,无法直观反映用户的问题。


1e1b4f1052944154a49aac274155b182.png


那么,面对这么多的影响因素,我们到底该如何以真实用户视角去对自己网站进行测试,量化网站用户体验,定位网站性能瓶颈?这里,我们以电商行业营销活动举例。随着竞争越发激烈,双十一、618 等促销活动成为电商等泛交易行业的年度重要营销活动。但大量用户的短时间涌入,会造成网站加载延迟,或业务服务卡顿等影响用户体验的问题。


ecb6295dd9e64eeb9cb07d599bb0f7a8.png

具体问题包括:

上线前,无法模拟真实用户,测试峰值用户高并发访问时的产品实际体验情况。

对于用户实际的浏览路径路程没有准确评估,无法定位转化瓶颈环节,不知道如何优化。

大促阶段商品信息更新较频繁,更新后经常收到各地用户投诉“商品图片加载不出来”、“页面打开缓慢”等投诉。

同业竞品活动性能情况无法获取,没法了解竞品营销态势变化。

在过往,以上问题都难以解决,具体难以解决的原因包括:

虽然有任务墙等方式,但运维团队无法找到足够多且符合实际需求的真实流量进行产品用户体验测试,采购相关流量又耗时又昂贵。

营销大促普遍产品上线窗口期十分紧迫,留给研发团队的交付时间相对有限。想要加入相关侵入式探针来进行监测,既拖慢产品交付速度又可能影响产品稳定性。

运维团队无法主动测试相关,导致问题只能在实际用户体验过程中发现,只能被动排障。但问题复现以及故障定位,可能就会拖住整个运维团队,导致修复时间无限期拖长。

因此,运营团队与运维团队需要一个能够解决上述问题的产品或者解决方案。云拨测作为面向业务的非侵入式云原生监测产品,成为最佳的选择。通过阿里云遍布全球的服务网络,模拟真实用户行为,全天候持续监测网站及其网络、服务、API端口可用性与性能。实现页面元素级、网络请求级、网络链路级细颗粒度问题定位。丰富的监测关联项与分析模型,帮助企业及时发现与定位性能瓶颈与体验暗点,压降运营风险,提升服务体验与效能。


8c84e468cddd49d68cf73cad9e0ad741.png

(一)全球监测节点覆盖


全球超过20万LM,500余个IDC终端监测节点,海内外400+运营商以及数十万量级注册会员,确保监测规模满足日益庞大的业务规模。


(二)无需嵌码,开箱即用


零侵入式监测,只需输入URL并进行简单配置即可,无需研发支持。数分钟即可获得完整的网站性能数据分析报告。资源包&按量付费多种购买模式,满足运维测试需求。


(三)面向业务,预置多种分析模型


监测周期精细至分钟级别,7大类20余项监测关联参数设置、支持多种主流协议,为站点和业务端口等提供7×24小时细颗粒度故障实时监测、告警及性能分析服务。以最终客户视角,通过地域、运营商等多维度组合分析,下钻分析单样本详情,利用丰富的指标体系与图表类型,直观定位问题、受影响范围及其根因,压降分析时间,提升运维效率。真正做到精细化监测。


(四)智能告警,精准定位


针对首屏用时、整体性能、可用性实现实时告警,丰富的告警策略设置,与阿里云告警中心深度集成,有效缩短MTTR。支持发现页面元素级错误,问题归因精准定位至单次网络请求过程,提升问题定位效率。


以某电商企业的营销大促举例,该网站月活用户数超百万,用户群体主要分布在全国三四五线城市,每年网站运营维护支出费用超过200万元。但由于大促阶段商品信息更新较频繁,更新后经常收到各地用户投诉“商品图片加载不出来”、“页面打开缓慢”,造成用户转化低,也导致运维团队被投诉。


面对这一困境,我们通过云拨测产品完成解决这一问题并进一步优化网站性能,以便支撑业务大促。


(一)压力测试

在企业的营销活动或新系统上线前,使用云拨测选取全国不同城市运营商的监测点,设定浏览和网络任务,即时获取第一线的真实用户访问体验数据,精准定位出现问题的页面元素,帮助技术团队及时修复问题。模拟峰值用户高并发访问,通过增加峰值压力,观察主要性能指标变化情况,挖掘性能瓶颈。


(二)用户体验优化

通过首屏监测以及即时监测功能可以立刻进行问题验证和故障复现,对网站性能进行评估与优化。并通过事务流分析,了解用户真实体验流程,优化浏览路径,挖掘转化瓶颈环节,提升转化率。


(三)竞品分析迭代

借助零侵入特性,收集分析同行业竞品营销活动性能情况,了解竞品营销态势变化以及应对方案,并针对进行针对性IT投入以及调优迭代,弥补营销短板,稳固领先地位。

经过以上相关措施,网站性能大幅提高,用户体验相关量化指标提升30%以上,有效驱动业务增长。除上述场景外,云拨测还可广泛应用于网络接口、服务可用性监测、CDN服务监控与选型、DNS解析状态、劫持分析等众多场景。


为了满足更多企业与独立站长的拨测需求,云拨测上线发布不同规格的月资源包,并开展限时优惠活动。新购用户将获得九折优惠。


68ec02708163480c90285a237a10c998.png

相关实践学习
通过云拨测对指定服务器进行Ping/DNS监测
本实验将通过云拨测对指定服务器进行Ping/DNS监测,评估网站服务质量和用户体验。
相关文章
|
3月前
|
前端开发 安全 JavaScript
官网构建不再难:全方位解析高效解决方案,让企业形象在线上‘大放异彩’
【8月更文挑战第29天】企业门户网站是展示品牌和传递信息的重要窗口,其构建需综合考虑技术选型、内容管理和用户交互等。本文从内容管理系统(CMS)、前端框架、响应式设计、SEO优化及安全防护等方面,评估高效构建方案。WordPress适合快速搭建内容丰富的网站,而Drupal则适用于复杂内容管理和定制化需求;React和Vue提高前端开发效率,Bootstrap助力响应式布局;SEO技术和工具提升搜索引擎排名;SSL/TLS证书和Web应用防火墙保障安全。通过综合应用这些技术,企业可构建功能全面、体验优秀的门户网站。
40 1
|
10天前
|
监控 安全 测试技术
构建高效精准测试平台:设计与实现全攻略
在软件开发过程中,精准测试是确保产品质量的关键环节。一个高效、精准的测试平台能够自动化测试流程,提高测试覆盖率,缩短测试周期。本文将分享如何设计和实现一个精准测试平台,从需求分析到技术选型,再到具体的实现步骤。
31 0
|
1月前
|
SQL 缓存 Java
揭秘物联网性能优化的终极攻略!提升系统效率的七大法宝
小米在物联网项目中遇到了性能优化问题,他从数据库、集群、硬件、代码、并行处理、JVM及操作系统等多个层面分享了优化经验。包括SQL优化、分库分表、缓存使用、水平扩容、分布式调度、硬件升级、代码分析、并行处理、GC调优及操作系统参数调整等。小米强调性能优化需结合实际情况,逐步提升系统响应速度与稳定性。欢迎留言交流,共同进步。关注他的微信公众号“软件求生”,获取更多技术干货。
51 0
|
4月前
|
域名解析 存储 弹性计算
在体验高效构建企业门户网站解决方案的过程中
在体验高效构建企业门户网站解决方案的过程中
60 3
提升直播软件源码开发平台性能关键利器功能
直播软件源码平台缓存功能的示例用法 cache = LiveStreamCache() cache.add_to_cache("stream1", "直播内容1") cache.add_to_cache("stream2", "直播内容2") content1 = cache.get_from_cache("stream1") print(content1) cache.remove_from_cache("stream2") content2 = cache.get_from_cache("stream2") print(content2)
|
监控 前端开发 机器人
开发一个高效的电商网站系统,这几点你必须懂!
随着互联网技术的迅速进步,电商网站已经成为商家们进行在线交易的首选平台。然而,创建一个高效的电商网站系统并非易事,需要有经验丰富的开发人员和周密的规划。
|
存储 移动开发 PHP
如何搭建一个高效稳定的体育直播系统?通用架构源码分享
分享一套东莞梦幻网络科技研发体育直播系统通用架构源码,该系统涵盖多个平台,包括Android、iOS、PC和H5。
|
人工智能 监控 算法
打造算法在线服务领域极致开发体验与性能 — 阿里TPP图化框架技术实践
TPP图化致力于打造一个算法在线服务领域易用、性能极致、迭代效率远超普通方式的产品。本文将介绍TPP图化以及2021年在性能、开发体验上的改进,并介绍未来TPP图化的规划。
打造算法在线服务领域极致开发体验与性能 — 阿里TPP图化框架技术实践
|
运维 监控 Cloud Native
拒做背锅侠!如何利用网站性能优化驱动产品体验提升
对于运维工程师而言,如果要票选五大最抓狂运维支撑场景,花样繁多的各种促销活动一定榜上有名。每个促销季上线都是忐忑不安的不眠夜。大量内容更新、大量客户涌入,大量数据读写,虽有着各种技术方案或工具服务保障着大促顺利进行。但仍有可能收到譬如“商品图片加载不出来”、“页面打开缓慢”、“无法完成订单支付”等诸多各地用户投诉。这些由于用户体验与网站性能造成的用户转化低、业务增长缓慢等糟糕结果,最终都会让运维工程师成为“众望所归”的背锅侠。
368 2
拒做背锅侠!如何利用网站性能优化驱动产品体验提升
|
数据处理 项目管理 数据中心
ABF平台设计(四):体验黑科技-结构化的体验数据平台
场景1: 新接收了一个项目,想了解一下当前的用户使用习惯和反馈,却没有一个全面、权威的数据支撑来帮助你深入了解,只能从用户口中了解到一些零散的信息;
244 0
ABF平台设计(四):体验黑科技-结构化的体验数据平台