三轮查完,收口。
cand-1, cand-14cand-2cand-5dr-1300080-platform 按platform拆 93 行、dr-1300062-platform 按platform拆 81 行cand-6dr-5730603-code 按code拆 27 行cand-7dr-2150603-appversion 按appversion拆 100 行cand-9, cand-23cand-10, cand-22, cand-21cand-16, cand-11cand-15, cand-32三轮查完,收口。第一条主线:版权限制(1300080,指播放时被版权校验拦下)和视频状态不合法(1300062)这两个码的「发生量翻倍、失败率大降」是同一个原因——泰捷新渠道集中涌入。新回喂的 1300062 下钻证实:该码当日 44289 次里泰捷占了 25992 次(约六成)且全部自动恢复,把泰捷剔除后其余平台的量比平时还少,也就是说增量全部来自泰捷;这和 1300080(泰捷占七成、全部恢复)完全同构。所以「同源群发」最终成立:泰捷渠道的接入/授权配置变更批量产生了这两类「命中限制但能恢复」的播放,把整体失败率读数稀释了;其他平台该失败的还是全失败。建议业务侧核对泰捷渠道的接入时间和授权配置变更记录。第二条主线:岩华平台(5730603,失败率连续 8 天越线、今天创新高)的失败主力码查清了——几乎全在播放器框架层:prepare 超时(11010002)一码 1782 次、占平台全部失败约八成,加上缓冲超时等 110 系框架层码合计约九成八;不是内容授权问题,跟泰捷那种授权拦截完全是两回事。建议平台侧排查播放服务/框架链路(重点看点播准备阶段超时的内容、节点、时段分布)。其余条目结论不变:19.7.0.2030 版本卡顿翻倍仍是今天最大的单一恶化源;2150603 平台卡顿因平台×版本分组下指标列缺失无法下钻到版本,按平台侧排查处理并待数据侧修复;无缓存率(没吃到缓存的比例,越高越好)全版本全平台微降仍指向缓存链路的系统性变化;其余几条是老版本退出期指标变坏、量已很小,观察即可。口径提醒同前:贡献度表均受 100 行上限截断,引用数字只在各自表口径内成立;本轮为最终轮,不再提下钻请求。
cand-8dr-1300080-platform 按platform拆 93 行、dr-1300062-platform 按platform拆 81 行cand-18, cand-24, cand-17, cand-25cand-19, cand-26cand-12, cand-13cand-30cand-31cand-3cand-4cand-29dr-1300080-platform 按platform拆 93 行cand-20cand-27cand-28