保持异常的异常性——我们如何学习过滤有意义的异常
保持异常的异常性——我们如何学习过滤有意义的异常
“These are not the exceptions you’re looking for…”
作为一家致力于客户成功的公司，我们必须尽快发现并解决问题，最好是在客户注意到之前。编写完美的代码可能是不可能的，但是在我们的代码中捕捉异常以免影响客户是每个开发人员努力的目标。
安装异常跟踪器是尽早发现问题的第一步。然而，在报告每个错误的和报告重要的异常之间有很大的区别。如果你曾经上过心理学入门课程，你可能听说过“选择性注意力和“疏忽性失明”，心理学家研究当几个刺激同时出现时，人类大脑如何选择专注于某些刺激。在 Olark 这里，我们发现，如果没有一个经过微调的异常报告和处理过程，我们有时很难从噪音中挑出信号。
根据我们的实时错误跟踪器 Sentry ，我们每分钟记录 91 个事件。对于一家初创公司来说，很容易陷入推动其平台向前发展的忙乱中，并挥手赶走可能在后台堆积的长尾错误。面对如此多的刺激，我们发现自己把注意力转移到了别处。
幸运的是，我们知道每分钟 91 个事件中的大多数不会直接影响我们的客户，但这仍然不够理想。作为开发人员，我们知道我们可以做得更好，并使我们的错误跟踪器成为我们调试过程中的一个有用工具，以及代码质量的一个体面标志。
我们决定深入研究，看看我们能做些什么来将我们的注意力重新引回到有意义的异常上。
以下是我们的发现:
See no exceptions, hear no exceptions, speak no exceptions…
我们记录了太多错误
限速是一件大事。当我们遇到停机时间，并且每个人都遇到相同的问题时，真的没有必要收到数百个报告相同异常的通知。但是，如果您记录了如此多的不相关异常，以至于经常受到速率限制，那么您就有可能意外地过滤掉唯一的异常。
我们决定，这个项目成功的主要衡量标准是降低我们的比率限制例外的百分比。我们观察了一些重量级选手:每月投掷数千次的例外。真的有什么问题吗？我们是否恰当地抛出了一个错误，如果是，为什么我们如此频繁地抛出它们？我们能不能用另一种方法，比如提前返回，来摆脱工作流程呢？
最终我们决定我们正在适当地抛出错误。我们有几个例子，比如输入错误的电子邮件或信用卡信息，其中一个错误是有保证的，但一个例外不是。问题不在于我们抛出错误，问题在于我们将这些错误作为异常进行报告。通过减少我们报告的异常数量，我们为重要的异常提供了更多的上升空间。
普通异常
幸运的是 Sentry 客户端给了我们一个默认忽略某些异常的配置设置。我们没有使用一般的“错误”并记录几乎所有的错误，而是开始对所有的错误进行子类化，只记录我们认为最想知道的错误(例如服务器错误)。
我们还发现了另一种清除一些无意义异常的潜在方法。默认情况下，Sentry 安装了一个全局错误处理程序，它将捕获浏览器中的任何错误，包括与我们的网站无关的错误，例如浏览器扩展异常。Sentry 允许选择忽略来自某些 URL 的异常，或者将一些 URL 列入白名单，以便专门监听。我们创建了一个名为 Lumberjane 的 npm 包，其中包含我们所有前端应用程序的忽略设置，这有助于减少噪音。
在成功地忽略了这些预期的错误，并把我们的注意力集中在真正的异常上之后，我们的统计数据开始迅速提高。很快，我们只在停机期间受到速率限制，当我们查看 Sentry 时，我们实际上发现了以前没有见过的新异常，这些异常揭示了我们已经在调查的问题。
缺少上下文
调查几周前的异常可能会很棘手。我们通常每天多次部署代码。除非您非常熟悉某个特定的错误，否则如果您的部署已经超过几天了，那么就需要进行一些认真的挖掘，以找出哪个部署是 bug 的来源。幸运的是，这是一个简单的修复，因为 Sentry 的发布特性会用 git commit 标记每个异常。
我们也没有充分利用 Sentry 允许用额外的上下文标记异常的事实，例如用户 id 或电子邮件。通过确保我们附加这些种类的相关细节，可以更容易地看到有多少和什么类型的客户受到给定异常的影响，更好的是，如果我们注意到任何相关的情况，允许我们直接跟踪客户。
有时异常的上下文不可读
即使我们知道有问题发生，我们的前端开发人员经常发现自己茫然地盯着缩小的代码。缩小代码有助于快速加载应用程序，但人眼几乎看不到。
此外，在我们的暂存环境中，我们的前端异常甚至更加神秘，因为 Sentry 无法访问我们受 VPN 保护的文件。我们所要做的就是在一个巨大的串联 javascript 文件中的某个地方发生了异常。
幸运的是，Sentry 允许我们将源地图直接上传到他们的服务器。通过这个过程，我们可以看到相关文件作为堆栈跟踪的一部分，就像我们编写代码时一样，没有经过混合，也没有从 ES6 或 Coffeescript 传输。
我们还没有定义一个清晰的策略来区分低严重性异常的优先级
最后但同样重要的是过程问题。虽然高严重性异常很容易证明从项目中花费时间来工作是合理的，但是作为一个团队，我们并不总是知道如何处理低严重性错误。虽然 Olark 作为一家公司对工程师在他们认为重要的事情上的工作给予了高度信任，但作为一名工程师，并不总是很容易知道在低严重性的错误上付出了多少努力。我发现对于艰难的决定，我倾向于推迟。我们可以在几个小时内解决掉的小 bug 只会呆在队列中，队列看起来越来越令人生畏。
我们仍在测试哪种流程最适合我们团队和整个公司。我们正在尝试的一个想法是，除了日常工作之外，每周给每个开发人员分配一个 bug 进行调查。这是我们自己可能会做的量，但通过这种方式，这是一个正式的过程，也是对关注小土豆的许可和鼓励。
通过识别这些问题并研究处理这些问题的最佳实践，我们已经从每分钟 91 个事件减少到每分钟 1–3 个事件，从几乎总是被 Sentry 限制速率，到只有在实际停机时才被限制速率。我们肯定还可以做出改进，我们还在学习，但我们已经在创建支持工程师构建高质量代码的基础架构和流程方面取得了长足的进步，这有望为我们的客户带来更轻松、更流畅的体验。
关于作者: 莎拉·辛格是 Olark 的一名回调处理员。她住在纽约，喜欢科幻小说，喜欢在城市中长途跋涉，并志愿让纽约市的科技场景变得更棒。
想看更多这样的文章？
如果你在过去几年中做过任何类型的前端工程工作，你很可能会被…
blog.olark.com](https://blog.olark.com/how-a-saas-company-evolves-its-front-end-tech-stack) [## 有效使用 Olark API:防范社会工程攻击
我们的朋友马修·哈里斯是 sendwithus 的创始人。他最近为 Venturebeat 写了一篇关于社交…
blog.olark.com](https://blog.olark.com/guarding-against-social-engineering-attacks) 
