问题定位一般流程
如前文所述，直播是一个全链路的业务形态，尤其是拉流端处在整个链路的末端，各个环节的问题都会导致拉流端出现异常。因此如何根据现有信息及工具来定位问题的根源，便是解决问题的关键。定位问题一般要经历以下过程：
对于各类问题，首先需要的是明确的case与信息，针对具体case，需要的信息有：
拉流端device_id或user_id
问题现象描述（至少提供roomID或者流名）
问题发生时间
最好提供录屏
在Trace平台，根据前述信息检索相关日志，可以根据问题现象进一步查找对应的事件（对应event_key字段）
拉不到流？找到play_stop事件
根据first_frame_blocked字段判断首帧卡在哪个阶段
根据code字段判断错误码是什么（错误码是0？还记得拉不到流的部分原因是首帧慢吗？）
首帧慢？找到first_frame事件
根据前文中分阶段耗时对应的字段，寻找存在显著异常的阶段
卡顿？找到stall事件
根据流名查询对应时间点推流端的推流情况，是否推流端卡顿
根据拉流端在问题时间段前后的日志信息判断是持续性卡顿、短时间波动还是流相关卡顿
如果找不到stall事件，只有render_stall，那么可能的原因就是发生了丢帧
例如花屏、绿屏之类的问题，在日志上一般没有特别明显的错误，此时可以通过查看流回放判断源流是否有异常。如果源流回放没有异常，且用户播放转码流，且流已经结束的情况下，就需要运营同学持续关注相关反馈，尽可能保留现场（因为转码流不会进行录制）。
问题范围与定位方向
除了前述定位问题的一般过程，问题发生的范围也是快速定位问题的有效依据。一般有以下判断方法，根据问题（同一时间段）发生在不同用户或场景判断：
所有主播及观众 --> 这种情况非常少见，如果出现，一般意味着出现了整个系统级别的问题
单个主播的所有观众 --> 推流端本身或推流端到边缘节点或源站引起，如果到边缘节点日志正常，一般为源站问题
同一CDN下的多个主播的所有观众 --> 收流节点问题（收流节点相同）或源站问题（收流节点不同）
单个主播的部分观众（仅转码流观众或仅源流观众） --> 源站转码问题（默认分辨率的存在导致判断易受影响，如果只有转码流播放，那么发生问题即使的是源流，最终反馈问题的也只有转码流观众）
单个主播的部分观众（某一地区） --> 分发CDN问题，一般是某一节点问题，层级因地区而异
单个主播的部分观众（CDN聚集） --> 分发CDN问题，这种情况一般出现在活动，有多家CDN参与分发
全量用户（或有版本等特征）某一时间点后 --> 基本是放量引起的
某些版本一段时间出现激增并骤降 --> 一般是流相关的问题，在某些版本触发了异常
问题定位的经验是需要不断积累的，不可能一蹴而就；除经验外，还需要深入理解各个角色在整个链路中的作用，根据问题的表现推测根因，再基于推测进行佐证。
止损手段
推拉流 SDK 对于新功能都会添加各类开关，以保证功能上线后、出现异常时可以及时关闭进行止损。但是对于一些新问题或者一些历史问题，如果没有相应开关进行控制时，对于业务线会造成不同程度的影响。
这类问题一般会是流相关的，且在测试阶段隐蔽性高（测试阶段没有办法百分之百覆盖到这些流问题，尤其是新问题）、突发性强（往往随直播开播时发生、关播时结束）。这类问题在初步分析问题、确定问题可以通过调度等手段解决时，可以尝试与转码、流调度配合完成这类问题的及时止损。随后在新版本进行问题修复。
留言0