本文根据演讲者在 GOPS 2023 · 深圳站演讲整理而成，如有图文不妥，请以视频为准。更多精彩，请关注高效运维公众号。
一、京东 H5 观测体系的背景
目前主流移动端开发模式已经成为 Native+H5 来进行 Hybrid APP 开发。
H5有其优势，如跨平台开发效率高、更新迭代方便；但同时也有劣势，比如用户体验不如原生页面、H5 工程质量难以把控等。
-
业务特性：京东内部有2000万+H5页面，90%页面是通过CMS搭建，涉及到20+业务团队。
-
研发测试痛点：研发想做技术改造、性能优化没有发力的方向；业务研发不知道业务性能现状，没有统一的标准。
-
线上用户反馈：有些活动线上用户反馈页面打开慢，安卓某个机型打开慢。
综上所述，线上用户体验问题如果发现和处理不及时，都会造成用户流失。
京东是如何解决的
基于上面的背景，京东自建了一套 UEM 观测平台，分三个阶段。
二、深度主动观测
主动观测基建
主动观测其实并不复杂，主要是做好三方面基建。
-
是从用户页面 Js 探针收集指标，建设成衡量标准；
-
是上报到日志服务端；
-
是通过数据清洗、流转、加工，存储到存储介质，最落到观测平台实现看板及价值的体现。
H5 探针指标建设
我们经常碰到就是指标建设是基于什么来实现的？我认为指标建设应该服务于度量标准，应该先将度量标准确定下来，然后根据标准相关的指标因子进行采集。
京东的用户体验指标分为两块：综合性能评分和异常率。
如图所示，评分依托性能指标点，然后向上提炼出来综合评分体系。另一块是 H5 体现出来异常率指标。
综合性能评分算法
综合性能评分算法借鉴了谷歌的 lighthouse 评分算法并它进行扩展提炼。
右图上每个性能指标可进行可配置项，配置权重和性能良好阈值和较差阈值，通过左边的单指标评分算法进行入参输入，输出单指标分数，结合权重计算总分。
这个标准在于实际推的过程中也发现一些问题，H5涉及的场景比较多，京东的做法是结合专家经验及实际现状设计对应评分标准，在前端通道里面推广。前面提到为什么采集这些指标，跟标准有关；我们采集这些指标更能代表真实的用户体验。
H5探针质量保障
真实落地时阶段我们也做了质量保障，输出两个S、两个O。
-
“S”peed：H5的探针速度，通过Tree Shaking、Hybrid离线包能力保证加载速度。因为探针会尽可能放在业务最前方进行加载，尽量不影响到后续业务流程。
-
“S”table：稳定方面做了管控及探针发布流程标准化。如果不去做这件事情，发上去出问题后会影响多个业务，观测平台信任度就会大大降低。
-
“O”ptional：如果能保证发布、探针质量，会更倾向于把选择权交给业务部门，我们支持多种介入方式：插拔式配置，配置上报频率、灰度控制等。
-
“O”bservable：探针自身监控能力也是非常有必要的，每次发版能从监控里面发现兼容性问题，做异常监控和 CDN 加载性能监控。
日志服务端架构
观测平台在大促期间需重点发力，一方面需要防止大促期间服务被打穿，另一方面是存储端的设计与容灾，还需要满足不同人群的查询统计需求。
因此我们设计了上面右图这套架构，从上往下从移动端请求流转到服务端，再通过 NSQ消息队列解耦转发给各服务。
其中也涉及一些业务配置，比如京东自研DUCC、观测平台自身API服务。
存储层根据不同查询需求做了分类，比如原始日志存到 ES，通过冷热数据节点降低成本、扩充数据体量。MySQL 主要用于结果集，Clickhouse 用大规模聚合查询，大促期间全量数据存到 CK 里方便后续业务发展。
在这个过程中发现业务方会经常关注我们的排障能力，所以我们设计了一套Sourcemap堆栈反解析方案，通过自研Webpack/rollup打包插件。业务研发通过在本地CICD打包过程中，会把Sourcemap产物上传到云对象存储OSS上，业务研发排障过程中就会请求Node.js反解析服务，去拉对应版本文件进行反解析。
如果不这样做，业务研发每次发版会走一遍观测平台上传对应Sourcemap文件，再去反解析，因此在这里做了一些提效工作。
说到观测，不得不提到异常告警。因为H5发版频繁，发布新版本以后可能产生新的异常信息，因为我们做了首次异常告警，提示用户进行检查，是不是因为新版本发布导致异常。
我们将异常信息字段进行关联，综合制成 Event id。如果新增Event id出发告警，通知业务方去看一下是不是因为新版本迭代导致新的异常。
第二块告警是我们建立的一套分钟级阈值告警配置，支持各维度，以及告警指标里面涉及异常量、异常用户数等进行阈值告警，推送给告警接收人，同时生成一系列工单，我们去追踪。
观测平台建设误区
回到观测平台，大家经常有一些建设误区，比如以下几种：
分享一个我们认为较为正确的思路。我们在建设平台初期拉通了两端，前端委员会以及QA共同设立内部用户体验标准，建立指标体系。目标建设成统一自循环可观测平台体系。
用户反馈平台进行半自动化生成工单、体验工单，后续根据工单推进业务研发，与QA协同起来解决工单问题。这方面是渐进式，最终还是要落地到业务，在过程中碰到业务问题，根据业务计划完善平台，最终目标是深入到业务，主动辅助业务排障，做技改优化，实现最终价值，提高工单解决率和推动技改落地数。
工单案例
618期间用户反馈页面加载慢，拉齐QA、业务研发一起协同治理加载慢的问题，最终通过指标模型发现综合评分比较差。看了一下指标，发现有几个指标非常差，经过社区及业界优化方案进行单指标优化，比如骨架屏提升，渲染提升单指标值。
这是优化效果，实际用户体验提升。左边这张图是Plus页面一开始的状态，首屏进来再也不是白屏，右边通过性能友好，把首屏加载时间从1.98秒提升到1.68秒。
第二个案例是观测平台赋能技改项目，打通CMS搭建过程中，发现有些项目CDN节点异常，触发告警，拉其运维、研发协同治理CDN资源容灾，增加重试机制，重试之后进行结果上报，汇总到观测平台进行数据收集。这也是体现业务技改产出的效果。
通过观测辅助他们度量城市成功率达到70%以下，整体成功率提升0.3%，原始值已经比较高了，达到99%。这个案例体现观测平台三个价值，观测平台发现问题能力，协助业务技改项目的能力，度量技改优化效果能力。
三、自动化被动观测带来的降本提效
做完主动观测发现还是有些问题没有解决，比如业务研发反馈侵入式探针接入成本比较高，线上非异常业务问题感知不到，比如运营配置页面突然下线导致404，这种情况导致探针都没有加载到，通过主动观测方式观测不出来。
因此设计了一套被动观测体系去做延伸，增强观测覆盖面积，提升测试人效。
落地方案是先调研了检测引擎，目前定下来 Puppeteer、Lighthouse，通过 Node.js 在服务端进行检测，能获取到用户性能数据。
第二个步骤是我们没有立即去做平台可配置化落地，我们回顾主动观测，进行数据及配置上的打通，比如业务标识、页面资源池，不需要让业务研发进行多余配置，直接在探针上报池子里面去找就行了。
被动观测的核心能力
被动观测核心能力目前覆盖50项，一是功能问题检测，一是性能问题检测。
功能问题检测主要覆盖一些场景，活动已经过期，404找不到，通过 Puppeteer 的爬虫能力清楚知道是不是404出发告警，通知业务方整改。
性能问题也可以通过 Puppeteer 去做一些页面打开，资源监控。看是否超过阈值，或者资源传输没有通过压缩，这些都可以检测出来。
检测效率保障
如何保障检测效率，现状大概10台8C12G容器承载每天差不多10万+ URL 检测任务。
第一通过多chrome进程户用、多 Page 架构，让单机脚本机承载页面更多。
第二减少无用进程数，减少IPC通信消耗，有些进程其实不需要拉起，通过调参优化，通过 Websocket 进行 chrome 进行串联。
第三是精细化调控方向，比如业务问题检测其实用不到比较高规格的机器，就用低规格机器形成脚本机农场。性能问题检测涉及CPU敏感，我们需要服务端模拟终端机型，我们用到中规格机器。大促期间如何重保高频业务检测需求，需要通过资源倾斜、Serverless 自动扩缩容进行横向拓展。
业务问题检测案例
某次活动现场，从APP分享H5页面到微信小程序的量级过大导致小程序卡片被封，但问题是从用户侧反馈得知的。
事后复盘确定两个方向：1、事前监控，通过加上 APP 端分享点击埋点，按照分享总量进行阈值告警通知，如果达到业务预警值会推动业务进行切量，从微信小程序转到H5。
2、事后监控通过被动观测、线上定制巡检，模拟用户使用场景，通过 OCR 文字识别进行扫描告警。
性能问题检测案例
第二个案例是性能检测案例，被动观测和主动观测进行对齐，统一出一个标准，度量页面性能健康度。通过注入探针JS获取用户体验的基础值，根据标准算出总分。
既然触发了告警，就要告诉他们如何优化建议。我们结合 Lighthouse 性能分析能力，获取优化建议。比如右下角这张图，可以看到图片大小有问题，可以帮助业务方进行整改。
四、全链路观测及质量保证实践与思考
京东内部H5贯彻体系全链路主要针对客户端场景，做了单用户单会话维度，通过链路各维度数据进行开素排障分析；包括客户端基础信息、用户反馈、崩溃、网络等进行数据串联，通过时间线维度观测发生异常前后用户客户端的路径及现场情况，这个功能在公司用的比较多，排障时会比较方便。
另外我们做了延伸，针对用户体验性能优化，以性能优化为导向，我们做了全链路观测，按照业务发布流程，一方面发布前如何做质量门禁，另外一方面是在线上如何做埋点检测以及自动化扫描。
我们罗列了4个环节，都涉及质量体系，Webview、CDN加载情况，可以输入看一下在哪个环节还缺少，进行查缺补漏。没有接入Hybrid离线包，性能比较差的情况下，推动他们接入离线包能力，提升性能。
H5全链路质量保障能力分为两个，即上线前质量门禁检测和上线后的日常巡检。
上线前的质量门禁检测，主要是通过被动观测能力，包括性能检测、合规检测、安全检测等进行能力输出，输出给前端发布系统、jenkins流水线原子能力形式集成到发布前检测。
业务上线后要做的事情就是日常巡检，比如我们在进行检测和埋点数据结合，前面提到量变进行打通，检测可以直接配置埋点监控页面，通过统一标准体系进行检测。这是一块比较普遍的能力。题外话，还有一块能力，这个平台影响力，我们还做了一些事情，在大促618期间做质量综合日报，输出平台能力，增加影响力，推动业务方每日进行问题整改。
简单总结，根据之前提到的这些环节，我们先做了主动观测，更进一步实现被动观测提效，结合共识，统一标准辅助业务，以全链路观测为目标，最终实现H5应用质量保障。
沈亚，京东资深技术专家，负责京东客户端及跨端技术的可观测平台建设与实践，主导设计并完成Hybrid/H5监控能力从0到1的落地，经历多次618,双11以及春晚核心活动亿级别流量的考验。
还不过瘾？还想了解更多可观测性是如何建设的？
6月29-6月30，2023 DOIS DevOps 国际峰会暨 BizDevOps 企业峰会·北京站，BizDevOps、精益/敏捷、SRE 稳定性、AIOps，你想看的内容，都在这里！
近期好文：
“高效运维”公众号诚邀广大技术人员投稿
投稿邮箱：jiachen@greatops.net，或添加联系人微信：greatops1118。
发表评论