(图8 Falco 领域问题模型)

运维的范畴极为广泛，围绕问题发现、问题接手、定位分析、问题修复关键流程，从海量设备的指标观测、告警，到单机排查、日志分析等，大家都知道要这么做，里面每个流程都涉及很多能力的建设，但实际执行起来很难做，各方也不认可，淘宝客户端一直以来存在指标准确性和日志拉取效率低下的问题。如APM性能指标为例，淘宝App过去很多指标不准，业务同学不认可，不能指导实际优化。本章节会从重点分享下淘宝App在指标准确性和日志拉取效率方面的相关优化实践。

(图9 问题扭转用户动线以及运维系统)

宏观指标体系

以端性能横向战役为契机，基于用户体感的体验，APM开启了相关升级工作，核心涉及启动、外链以及各业务场景下的可视可交互指标，如何做到让指标对应的终点更贴近用户体感，主要有以下一些工作：

• 8060算法的升级：视觉有用的元素提取出来计算（如图片和文字），剔除用户不能感知的元素（空白控件、兜底图），如制定视图可视规范，满足图片库、鱼骨图等自定义控件打标

• H5领域：支持UC 页面元素可视可交互以及前端 JSTracker（事件埋点框架）回溯算法，与H5页面可视算法打通

• 深入复杂的场景：制定自定义框架可视规范，打通 Flutter 、TNode（动态化研发框架）并校准等各类研发框架，8060算法交由各研发框架来实现。

• 外链领域：打通H5页面口径，重新定义外链离开等负向动作。

以启动为例，APM 在 校准后，包含了图片上屏等阶段后，数据虽然上涨了，但更符合业务方诉求

(图10 校准后启动数据趋势)

以外链为例，打通H5后，新口径也出现了上涨，但更符合体感

(图11 校准后外链前后口径数据对比)

基于此战役，已实现打通若干研发框架可视指标和校正工作。

单机排查体系

对于问题排查，目前核心还是基于TLOG，本次仅围绕用户问题排查动线中日志上报、日志分析、定位诊断关键环节遇到的问题(无日志、日志看不懂、定位难等)，介绍运维排查体系为提升问题定位效率做的努力。

(图12 单机排查问题定位核心功能)

• 提升日志上传成功率，从几个方面保障在排查问题时有日志供应过来，一是内置日志主动上传能力，在核心场景或问题反馈多时机触发，提高日志触达率，如舆情反馈、新功能上线发生异常时；二对TLOG能力进行升级，涉及到分片策略、重试、日志治理等优化，解决以往用户反馈较多日志上传的时效问题；最后是收集各类异常信息，作为快照，通过MTOP链路旁路上报，辅助还原现场。

• 提升日志的定位效率，首先对日志做分类，如区分出页面日志、全链路日志支持快速筛选过滤；接着是打通各个场景的全链路调用拓扑结构，目的是可以快速看出问题发生在哪个节点，以便快速分发处理；最后结构化错误、慢、UI卡等问题，原则是将领域问题的解释权交给领域，比如卡顿日志有几类，如APM冻帧、ANR、主线程卡顿等；业务类有请求失败、请求RT大于xx时间、页面白屏等，通过各领域的能力 对接来提升问题的快速诊断定位能力。

• 全链路追踪能力建设，鹰眼（分布式跟踪系统在阿里后端的实现）接入业务众多，日志量大，不可避免要做日志的采样，对于没有命中采样的调用，缓存只有5分钟，需要想办法在5分钟内通知鹰眼保持更久的时间。第一阶段，后端解析服务会解析出调用链的鹰眼ID，通知鹰眼服务存储对应的trace日志，成功通知后可以存3天；第二阶段感知网关发生异常，取出鹰眼ID，通知鹰眼存储将存储前置；第三阶段，类似场景追踪，获取核心场景的鹰眼trace日志，尝试放在摩天轮平台上存储。第一阶段已经上线，可以做到关联跳转鹰眼平台，一般从问题发生到排查都过了5分钟，因此成功率不高，还需要结合2、3阶段进一步提升成功率，正在规划开发中。

• 平台能力的建设，基于端侧全链路日志做解析，在可视化方面，通过结构化展示全链路日志内容，方便快速部分节点的异常；还有就是基于结构化日志，对全链路日志中的耗时异常、接口报错、数据大小异常等问题进行快速诊断。

以上是今年在运维做的一些尝试，目的是希望可以通过技术升级，在排查领域用技术赋能代替流程赋能。

下面接着继续给大家展示下淘宝的实践和集团其它app接入的效果。

全链路运维实践

• 淘宝卡顿问题排查

内部同事反馈在海外用淘宝App，出现卡、部分页面打不开等现象，经过上诉排查过程，提取到TLOG日志后。

• 通过“全链路可视化”功能(图10)，可以看到H5页面spanID为0.1的network状态为“失败”，导致页面打不开。

• 通过“全链路诊断”耗时异常功能（图11），可以看到大量network耗时分布在2s、3s+，有的甚至8s+，network阶段发生在请求调用阶段(传输)，与海外用户访问到阿里的CDN节点慢相关。

(图13 全链路可视化功能)

(图14 全链路卡顿诊断功能)

• 饿了么主链路接入

(图15 饿了么全链路视图-冷启全链路)

店铺全链路

(图16 饿了么全链路视图-店铺全链路)

新指标体系

现在重点介绍下我们怎么围绕Falco可观测模型，从端到端全链路视角构建线上性能基线，用数据驱动淘宝App体验持续改善，首先就是数据指标体系的构建，主要有如下几点：

• 指标定义和规范：贴近用户的感受，围绕用户点击到内容呈现到滑动页面的操作动线来定义相关指标，重点采集页面打开、内容上屏、点击响应、滑动等技术场景，如内容展现有页面可视可交互、图片上屏指标，滑动有滑动帧率(手指)、冻帧等指标来衡量。

• 指标度量方案：原则是不同领域的指标交由对应领域负责，以卡顿指标为例，可以是厂商的口径(苹果MetricKit)、也可以是自建的口径(APM的主线程卡顿/ANR等)、还可以是不同业务域的自定义指标（场景全链路），如MTOP请求失败、详情头图上屏等。

• 指标组成：由线上集合指标和线下集合指标组成，基于线上和线下数据和相关规范，立足用户视角和竞对情况牵引APP体验优化。

• 场景全链路为例

某个具体业务下，对于用户的一次交互行为，从发起响应到结束响应，从前端到服务端到客户端的完整调用链路

还有其他等等... ...

可以看到，整个数据体系是多元化的，后续整个性能体验数据会有一个标准的输出，敬请期待。

新指标体系下的优化

FY22 平台技术围绕全链路视角，以体验为出口，深入业务开展摸排优化，围绕指标定义并拆解问题域，面向用户真实体感开展各大专项优化。我们自底向上一一介绍，通用的网络层策略优化，如何围绕请求周期，从连通性->传输层->超时策略提升；面向用户体感的有技术策略升级，如网关和图片的优化；面向业务场景的技术改造，会场框架的预处理预加载、安全保镖的轻量化实践，甚至是业务上的体验分级，如首页信息流低端机下不启用端智能，下面会重点介绍相关实践。

• 请求精简提速-极简调用实践

以MTOP请求作为一个场景，链路主要涉及「MTOP到网络库」的交互，通过对全链路线程模型现状分析，从MTOP发起到网络层接收到会几点会导致请求慢：

• 数据拷贝多：现有网络层机制，网络库存在hook拦截处理，基于NSURLConnection + "URL Loading System" 转发到网络库进行网络传输，涉及多次数据拷贝，中转拦截处理非常耗时。

• 线程切换多：线程模型过于复杂，完成一次请求频繁切换线程。

• 异步转同步：原有请求使用一个队列 NSOperationQueue 来处理任务，底层维护的这个队列把请求和响应绑在一起，使得发送之后要等待响应结果回来才会释放，"HTTP Operation" 占住完整的一个HTTP收发过程的全部IO，违背了网络请求的并行性，operation queue容易打满阻塞。

以上几点问题，在大批量请求、系统资源竞争激烈场景下下(冷启动，几十个请求一拥而上)，更为明显。

改造方案，通过MTOP直接调用网络库接口来获得较大性能体验提升

• 简化线程模型: 跳过系统URL Loading System hook机制，完成收发数据线程切换，减少线程切换。

• 避免弱网阻塞：数据包Sending 与 Receiving 拆分处理，空口长RT不影响 I/O 并发容量；

• 汰换废弃API：升级老旧NSURLConnection 到直接调用 网络库API。

数据效果：可以看到，在系统资源更为紧张环境下，如低端机上优化幅度更为明显。

• 弱网策略优化-Android 网络多通道实践

在WIFI信号差、弱网环境下，有时候多次重试对成功率提升效果并不明显。系统提供了一种能力，允许设备在WIFI环境下将请求切换蜂窝网卡的能力。网络应用层可以利用该技术，减少请求的超时等一类错误，提升请求的成功率。

在Android 21之后，系统提供了新的获取网络对象的方式，即使设备当前具有通过以太网的数据连接，应用程序也可以使用此方法来获取连接的蜂窝网络。所以，当用户设备同时存在WIFI和蜂窝网络的情况下，可以在特定策略下将不同请求同时调度到以太网和蜂窝网两个网卡通道上，实现网络加速。

核心改动点：

• 方案前提：当前Wi-Fi网络环境是否支持蜂窝网络。

• 触发时机：当请求发出超过一定时间未返回数据后，触发切换蜂窝网络重试的请求，原先流程的请求不中断，使用优先返回的通道的请求响应，晚返回的会取消。

• 时间控制：根据特定场景Orange配置，后续还需要灵活根据网络强弱来动态调整。

• 产品形态&合规上：使用时给用户透出文案 “正在同时使用WIFI和移动网络改善浏览体验，可在设置-通用里关闭”，弹出策略为 每次启动首次功能触发。

数据效果：在网络资源竞争剧烈的情况下，WiFi+蜂窝双通道网络场景下，长尾和超时率优化较为明显，AB数据，首页API， P99/P999分位性能分别提升23%/63%，错误率减少1.19‰，首页图片， P99/P999分位性能分别提升12%/58%，错误率减少0.41‰。

• 技术策略分级-图片分级实践

不同设备性能千差万别，业务的复杂度也越来越高，很多业务无法在低端设备上让用户体验到应有的效果，反而会带来卡顿等不良的体验。以往会通过“延迟、并发、预加载”等手段来优化性能，但只是规避了问题，核心链路仍然要要直面关键的调用耗时。所以，我们需要对业务做体验分级，基于对业务流程的分级处理，让高端设备体验最完美复杂的流程，低端设备也能顺滑的使用核心功能，理想是期望实现 用户体验 & 业务核心指标 的双高，退一步来说，让部分功能有损(不影响核心业务指标)的情况下，让性能体验更佳，初步的设想是希望分2步走来实现：

• 第一阶段，业务分级需要丰富的策略库和判断条件来实现分级，我们将在核心组件上沉淀这部分通用能力，帮助业务快速的实现业务分级能力。

• 第二阶段，随着大量的业务都接入了分级能力，积累了大量的业务分级策略以及AB数据，那么可以去做单点业务分级策略的推荐&最优化，实现大量相似的业务可以快速复用，提升效率。

传统CDN适配规则会根据网络、view大小、系统等因素动态拼装获取「最佳」的图片尺寸来减少网络带宽、位图内存占用，提升设备图片加载体验，本次设备分级视角，并且会基于UED给出的规范，实现压缩参数可配置，扩展原有CDN适配规则，实现不同机型的图片分级策略，通过该能力，可以让图片的尺寸进一步缩小，加快图片上屏。