作为一个专注于搭建珠宝类垂直SaaS系统的服务商，在疫情期间，我们上线了直播功能，旨在帮助珠宝门店构建私域流量变现闭环。然而，我们在一次直播活动中遇到了事故，由于推流端网络的不稳定，导致用户数据急剧下降，留在直播间的用户甚至自嘲被“关小黑屋”了。我们及时发现并内部进行了追责处理。

流量对直播的重要性

直播是一种对实时性要求较高的场景，如果在处理网络异常时不当，会产生以下两个影响：

1. 主播无法正常上传数据：当主播端的网络发生异常时，直播数据无法上传。如果没有及时反馈，主播会处于不知情的状态。如果主播继续直播，这部分直播内容将会白费。如果直播间持续无内容产出，观众会意识到直播发生问题，产生疑虑，却得不到说明。而主播由于不知情，没有及时采取相应的恢复、补救措施，浪费观众的时间，导致产生更大的怨气。更严重的是，异常情况一直没有得到妥善处理，主播在直播过程中胆战心惊，分心询问观众来获知直播间是否正常。观众会认为这个直播间不稳定，对主播的信任降低，长此以往，影响主播和观众之间的关系。一个无法沉淀好内容、好口碑、好粉丝关系的直播间，无法建立好主播IP。

2. 观众无法正常下载数据：当观众端的网络发生异常时，无法下载数据到观众本地页面，导致页面长时间加载，等待数据重传，引发观众的不良情绪。此时，如果没有及时反馈，没有明确的操作指引和解决方案，观众会不知所措，停滞在页面上，加重不良情绪。这使我意识到，对异常情况的处理方式不当，轻则影响用户使用产品的体验，重则导致产品无法使用，丧失用户对产品的认可。

异常状态处理的重要性

在实际使用产品的过程中，用户进行某种操作或满足某项条件往往会导致异常状态的发生。这些异常状态可能使产品呈现与用户预期不符，部分操作没有反应，甚至导致产品无法操作或局部/全面影响产品功能的使用。因此，我们需要设计配套的异常状态处理方案，一般有两种典型的模式。

1. 规避异常状态

规避异常状态是系统和用户共同参与的过程，目的是在异常发生之前将其扼杀在萌芽状态，降低异常发生的可能性。这种模式需要用户事先授权，在异常发生前接受行为告警，并上传错误日志。如果规避方案需要用户参与决策，系统会发起告警或请求帮助。例如，多个视频网站会在用户从WiFi切换到4G网络时发出流量模式警告，让用户自行选择继续观看还是切换网络。

2. 修复异常状态

修复异常状态是系统和用户共同参与的过程，目的是将产品从不可用状态恢复至可使用状态，避免异常状态的升级和扩散，降低其影响范围和程度。系统应具备智能修复异常状态的能力，例如在直播观看中出现画面衔接错乱或花屏现象时，系统会立即对每一帧音频和视频的时间戳进行逻辑值矫正，使音画实现同步。对于无法智能修复的异常状态，系统会发起请求帮助，用户参与修复。例如，用户上传照片时，由于访问相册的权限获取失败，系统需要提示用户无法使用功能的原因，并再次发起请求以获取权限。

缺少规避或修复两种模式之一都会导致异常状态处理流于表面，无法真正解决问题。因此，这两种模式的存在是相辅相成的。

如何处理异常状态

1. 预判异常状态

在讨论如何处理异常状态之前，我们需要预先知道有哪些异常状态，并判断它们可能在哪里发生以及具体的影响。这一步骤非常考验逻辑的完整性，一旦出现疏漏，就意味着对部分异常状态失去了预判，无从谈起处理。为了提高效率，我们可以通过穷举法逐一列举所有可能的异常状态，以免逻辑疏漏。穷举法的缺点在于效率低下，而在正常的产品设计中，时间往往是有限的。为了提高效率，我总结了三种穷举的方向。

首先，根据业务流程，穷举各个角色在业务流程中可能发生的异常操作。通过梳理业务流程，我们可以从每个节点穷举可能发生的异常操作，这是最直观的方法。在直播场景中，涉及到四个角色：主播、业务系统、直播系统和观众。

文章所讨论的是主播在直播过程中可能遇到的异常情况。为了更好地理解，我们可以将主播开播到直播系统转码这个过程中的异常操作进行总结。首先，我们可以根据异常操作的影响数据的方向进行分类。异常操作包括前端无法将请求传递给后端、后端返回超时或错误信息等。这些异常操作将导致产品功能无法正常使用。为了更好地理解异常情况，我们可以绘制业务流程图和数据流向图，以帮助我们穷举异常条件。另外，我们还可以通过回溯历史异常来查漏补缺，找出可能触发异常的规律。系统的日志记录和事件监视功能可以为我们提供回溯历史异常的依据。我们可以从用户、行为、时间、环境和性能等指标进行分析，以找出可能触发异常的因素。

在确定了异常状态后，我们需要解决两个问题：如何预防异常状态的发生以及如何解决异常状态。预防异常状态需要采取一些措施，既要降低异常发生率，又要设置预警阈值以提醒用户。类似于在车辆行驶至意外高发地之前设置减速带，既能降低车速以避免意外发生，又能提醒我们注意安全。在直播中，我们可以设置带宽和流量超限的预警值，一旦达到预警值就提前警告主播，以避免直播过程中的中断和差劲的体验。解决异常状态的措施可以分为两种：系统自动触发和引导用户触发。系统自动触发可以在异常状态出现之前或出现中自动触发重试或恢复逻辑，而引导用户触发则需要在系统无法自动触发时让用户选择处理方式。举例来说，在直播带货中，如果缓存失败，系统应自动触发重新下载的恢复逻辑并尝试重连。如果仍然失败，系统无法决定处理方式，这时应将决策权交给用户自行选择删除任务或重启任务。在用户观看直播时，根据推流质量和网络环境的影响，清晰度的调整是一个动态平衡的过程。在直播带货中，系统会自动降低直播的清晰度以避免卡顿，但在高价位货品的场景中，用户可能无法接受看不清货品细节的情况，所以系统会提供入口供用户自行调整。综上所述，异常状态的恢复通常以系统自动触发为主，只有在系统无法完全解决问题时才引导用户触发。

在反馈给用户时，我们需要思考是否需要提示所有异常情况。如果通过系统自动触发的恢复措施能够在短时间内处理异常状态而用户根本无法察觉异常的存在，那么维持系统稳定的形象，让用户保持“无知”，避免用户担心风险是可取的。因此，在一定时间内系统有能力自行修复且无需用户参与的异常状态可以不反馈给用户。对于前面提到的前端请求超时的异常情况，我们可以调整为在一定时间内自动重连，以尽量减少对主播的“骚扰”，只有重连不成功才引导用户触发恢复逻辑。

总之，当遇到异常状态时，我们需要通过穷举异常条件、回溯历史异常和分析数据等方式来解决问题。在解决异常状态之后，我们需要合理地预防异常状态的发生和恢复异常状态，并在必要时向用户提供反馈。

确认异常状态是否需要提示用户后，我们需要考虑应该向谁发出提示。在业务流程中，受到异常状态影响的角色就是我们应该提示的对象。当主播的网络出现异常时，观众虽然无法参与解决主播的网络问题，但毫无疑问他们是受到异常状态影响的角色，因此需要进行提示。

最后，我们需要思考如何向用户发出提示。提示通常包括三个部分：

• 提示：告知用户当前的状态，以及导致此状态的基本原因；

• 操作：引导用户解决问题的方法；

• 反馈：告知用户问题是否成功解决。

我们可以看一下抖音在网络异常情况下的提示信息，它通过简洁的文案和图示向用户解释了当前遇到的问题，并提供了相应的解决方案。

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

补偿

当异常状态恢复并且用户反馈处理完毕后，我们需要考虑售后服务。如果异常状态持续时间较长甚至无法恢复，我们需要引导用户转移到适当的地方，以降低用户的流失。如果异常状态波及范围广或者造成了较大的损害，我们需要提供补偿机制，以确保用户的损失最小化。

以下是淘宝直播中的一个异常状态提示示例，可以看出它不仅提供了解决方案“点击重试”来触发恢复逻辑，同时还给出了“看看别的”选项。在用户多次重试无法解决问题的情况下，引导用户浏览其他直播内容。对于直播平台来说，这比让用户离开应用更好。

如果异常状态波及范围较大，我们需要向用户提供补偿。这不仅可以安抚用户，展现产品的信誉，还可以对受异常影响的活跃数据进行挽回和提振。下面是一个游戏的补偿奖励方案示例：

总结

通过这次经历，我意识到，一套专业、实用、高效的SaaS系统，在处理异常状态时应具备预测、恢复、反馈和补偿的能力。在异常状态发生之前，我们需要预设可能出现异常的条件，并时刻监控用户行为。一旦触发条件，我们应该及时给出反馈并修复问题，以避免异常的发生。在异常状态发生后，同样需要提供反馈和修复机制，以避免问题扩大。最后，我们应该尽力为客户提供补偿，以挽回损失。在日常的产品工作中，我们仍然需要不断监控和回顾所有的业务节点和数据流向。异常状态的处理是一个永无止境的过程，我写下这些内容希望能与大家一起完善和改进。