一次直播事故引发的异常状态处理思考

作为专注于搭建珠宝类垂直SaaS系统的服务商，疫情期间，我们顺势上线直播功能，帮助珠宝门店构建私域流量变现闭环。

上线后，发生一次直播事故，珠宝店在做一场直播放漏活动中，由于推流端网络不稳定，用户数据断崖下降，还留在直播间的用户自嘲被“关小黑屋”了；我们监控到了这次事故并做了内部追责。

一、异常状态处理不当的影响

直播是一种对实时性要求较高的场景，若出现网络异常的处理方式不当，主要有以下2个影响：

1. 无法正常上传数据，影响主播

主播端的网络发生异常后，直播数据无法上传，此时若反馈不及时，主播处于不知情的状况。

如果主播继续直播，这部分直播内容将会白费。如果直播间持续无内容产出，观众会意识到直播发生问题，产生疑虑，却得不到说明；而主播由于不知情，没有及时采取相应恢复、补救措施，浪费观众的时间，导致产生更大的怨气。

更严重的是，异常情况一直没得到妥善处理，主播直播过程中胆战心惊，分心询问观众来获知直播间是否正常；观众会认为这个直播间不稳定，对主播降低信任，长此以往，影响主播和观众之间的关系。

一个无法沉淀好内容、好口碑、好粉丝关系的直播间，无法建立好主播IP。

2. 无法正常下载数据，影响观众

观众端的网络发生异常后，无法下载数据到观众本地页面，导致页面长时间加载，等待数据重传，引发观众的不良情绪。

此时反馈不及时，没有明确的操作指引解决方案，观众莫名其妙无处可去，停滞在这一个页面，不知所措，会加重这种不良情绪。

这使我意识到，对异常情况的处理方式不当，轻则影响用户使用产品的体验，重则导致产品无法使用，丧失用户对产品的认可。

二、什么是异常状态处理

用户在实际使用产品的过程中，进行的某种操作或是满足了某项条件，往往会导致异常状态的发生。

有的异常使产品呈现与用户预期不符，有的异常使产品部分操作没有反应，有的异常甚至使产品频繁崩溃至完全无法操作，或局部或全面影响产品功能的使用。

我们应该设计配套的异常状态处理方案，一般有两种典型的模式。

1. 规避

规避是系统和用户共同参与，将异常状态扼杀在萌芽之前，目的在于降低异常发生的可能性。这种模式需要用户事先授权，在异常发生前接受行为告警，异常发生时上传错误日志。

若规避方案需要用户参与决策，则由系统发起告警或请求帮助。多视频网站，都会在用户网络环境从WIFI切换成4G时发起流量模式警告，发起请求让用户自行选择，继续观看还是切换网络。

2. 修复

修复是系统和用户共同参与，将产品从不可用状态恢复至可使用状态，不让它升级、扩散，目的在于降低异常覆盖的范围以及影响的程度。

系统应具有智能修复异常状态的能力，比如直播观看中出现画面衔接错乱乃至花屏现象，系统会立刻对每一帧音频、视频的时间戳进行逻辑值矫正，使音画实现同步。

部分系统无法智能修复的异常状态，则由系统发起请求帮助，用户参与修复；比如用户上传照片，由于访问相册的权限获取失败，系统需要提示用户无法使用功能的原因，并发起请求，再次进行权限获取。

异常状态处理的两种存在模式缺一不可。

• 缺少“规避”，异常状态处理流于治标不治本，用户在遭遇一次异常状态后，很大几率再次遭遇，重复耗费解决成本。
• 缺少“恢复”，相当于无视异常状态，产品持续处于或局部或全面不可用状态，用户仍然得不到预期操作结果。

两种存在方式匹配进行，才是真正的异常状态处理。

三、如何处理异常状态

1. 预判

在讨论如何处理异常状态之前，要做的是预判——预先知道异常状态有哪些，并判断它会在哪里发生，它具体的影响。

在这一步，极考验逻辑完整性，一旦发生疏漏意味着对部分异常状态丧失预判，处理更无从谈起。

这时，我们可以通过穷举法逐一列举所有可能的异常状态，通过牺牲时间换取预判的全面性，避免逻辑疏漏。

穷举法的缺点在于效率低下，而在正常的产品设计中，时间往往是有限的；为了提高效率，我总结了三种穷举的方向。

穷举的第一个方向，是根据业务流程，穷举各个角色的异常操作

处于业务流程中的各个角色，在任何一个页面，进行任何一项操作都可能发生异常。梳理业务流程，从每个节点穷举出可能发生的异常操作就是最为直观的方法。

梳理业务流程时发现，直播共涉及了四个角色，分别是：主播、业务系统、直播系统和观众：

文章开头案例所涉及的直播事故，就是在主播直播过程中，由于网络异常而导致的。

为了便于说明，我们不妨以主播正式开播为起始，到直播系统转码为结束，我们穷举这个节点中，主播所有异常操作：

穷举的第二个方向，是根据数据流向，穷举影响数据的异常条件

产品正常使用过程中，必然伴随着数据从前端上报、从后端下发的过程。

数据流转中出现异常，比如前端无法把请求传递给后端，比如后端返回超时、后端返回错误信息，都意味着产品功能无法正常使用。

可见，异常状态和数据息息相关；我绘制完业务流程图，一般还会绘制数据流向图，通过理顺数据的流转过程，辅助穷举异常条件。

主播开播后的数据流向图如下：

从中我们可以穷举的影响数据的异常条件：

穷举的第三个方向，是回溯历史异常，穷举遗漏的异常条件

回溯，指带着发现问题的目的回顾过往经历，以期得到解决方案。

人非圣贤，我们难以预判所有异常状态，往往异常发生后才意识到它的存在；因此，对已发生的异常问题进行多维度的回溯分析，是必不可少的；一方面帮助我们快速透视化了解异常问题，一方面为我们穷举的异常条件查漏补缺，避免下一次异常的发生。

雁过留痕，系统通常具有收集日志的能力，记录系统运行中的信息，同时监视系统中发生的事件，这就为回溯历史异常提供了依据。

日志拥有非常庞大的字段表，囊括了异常发生时所有信息。

我们可以从以下几个指标进行分析总结，找出可能触发异常的规律：

• 用户：用户状态、权限，比如发生同样异常的用户是否特征相似；
• 行为：异常发生时用户所有操作；
• 时间：异常发生时整个时间线；
• 环境：网络环境、硬件设备、操作系统，等等；
• 性能：加载时间、请求时长、响应速度，等等。

2. 恢复

预判所有异常状态以后，亟待解决的就是两件事：异常状态发生前，我们如何扫清问题？异常状态发生后，我们如何解决问题？

前者需要配备预防措施，后者需要配备恢复措施。

先说前者预防措施，既要起到降低异常发生率的作用，还要有预警阈值提醒用户。

就像车辆行驶至意外高发地之前，在道路中设置的减速带，既起到降低车速避免意外发生的作用，也起到提醒我们减速注意安全的作用，帮助我们防患于未然。

在直播中带宽、流量超限的异常状态，我们可以设置预警值，达到预警值时提前警告主播，这样就能避免在直播过程中直接中断，体验极差。

再说后者恢复措施，分两种：第一种是系统自动触发，在异常状态出现前或出现中，自动触发重试性的保护逻辑或者恢复逻辑；第二种是引导用户触发，主要使用场景在于系统没有办法自动触发，有义务让用户做选择的异常情况。

部分直播会提供回放功能，支持缓存；比如教育类的课程，缓存失败就是这类产品常见的异常状态，系统应自动触发重新下载的恢复逻辑，尝试重连；如果仍缓存失败，或因其他未知原因，系统没办法替用户决定处理方式，这时应将主动权交给用户自行选择删除任务或重启任务。

很多用户观看直播时，受推流质量和网络环境影响，清晰度的调整是一个动态平衡的过程。

在直播带货中，搞秒杀促销，对延迟的要求特别高，一旦卡顿，系统会自动降低直播的清晰度；但在高价位货品的场景中，用户可能无法忍受看不清货品细节的情况，系统在一定范围自动微调清晰度的过程中，同样会提供入口供用户自行调整。

从中我们可以总结出，异常状态的恢复一般以系统自动触发为先，仍然无法完全解决问题才采用两者结合的方式，引导用户触发。

3. 反馈

确定出现异常状态的恢复逻辑后，就来到反馈用户的环节，我们首先需思考的是所有异常都应该提示用户吗？

若异常状态发生后，通过系统自动触发的恢复措施，能将异常状态处理完毕，并且整个过程耗费的时间极短，短到用户根本来不及感知异常的存在；这种情况下，维持系统稳定的形象，让用户保持“无知”，避免用户对风险的担忧，何乐而不为？

总结而言，在一定时间内系统有能力自行修复，无需用户参与的异常状态，可不反馈。

我在前面预判阶段做数据流向图时，前端请求超时，直接提示主播异常信息，这种方式是值得商榷的，可以调整成在一定时间内自动重连，尽量降低“骚扰“主播次数，反复不成功再引导用户触发恢复逻辑。

调整如下：

确认这个异常状态是否应该提示用户后，我们需要思考的是提示谁？

在业务流程中，处于受异常状态影响的角色就是我们应该提示的对象。

主播网络出现异常，观众虽然无法参与解决主播的网络问题，但毫无疑问属于受异常状态影响的角色，需要进行提示：

最后，我们应该思考如何提示用户？提示一般包括三个模块：

• 提示：提示用户目前的状态，引发状态的基础原因；
• 操作：引导用户如何解决问题；
• 反馈：问题是否成功解决。

我们可以看一下抖音在网络异常情况下的提示信息，以简单的文案和图案为用户解释了目前遇到的问题，并提供了相应的解决方案：

网络恢复正常后，抖音选择了最简单有效的反馈，就是让异常状态提示信息消失，即时展现正常短视频内容。

4. 补偿

当异常状态恢复和用户反馈都做完后，我们需要考虑自己的“售后”了。

若异常状态恢复时间较长甚至无法恢复，需要引导用户至相应地方，降低产品跳出；若异常波及的范围或产生的损害大，需要提供补偿机制，确保用户的损失降到最低。

下图是淘宝直播中的一个异常状态提示，可以看出不仅提出了解决方案“点击重试”触发恢复逻辑，同时也给出了“看看别的”选项；在用户反复重试都无法解决问题的情况下引导用户观看其他直播间内容，对于直播平台来说，总比跳出APP要好。

若异常波及范围大，需要后置为用户提供补偿，一方面安抚用户彰显产品信用，另一方面是针对受异常影响的活跃数据的一种挽回和提振。

例子，下图是一款游戏的补偿奖励方案：

四、总结

经此一役我意识到，一套专业、好用、高效的SaaS系统，针对异常状态应该具备预判、恢复、反馈、补偿的处理。

预判在异常状态发生前，预设可能出现异常的条件，时刻监控用户行为，当触发条件时给出反馈，及时修复，避免异常。

在异常状态发生后，同样要给出反馈和提供修复机制，避免异常扩大。

最后提供补偿，尽力为客户挽回损失；在日常产品工作中，仍要不断监控、复盘所有业务节点和数据流向；异常状态的处理注定永无止尽，写出来是希望能和大家一起查漏补缺。

作者：百转；公众号：百转进化论

本文作者 @百转 。

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！