错误监控为何极易沦为鸡肋？

绝大多数前端团队，都有错误监控，无论是私有部署的，如 Sentry，还是采购三方。

这似乎是个政治正确的方向，直观感受上，是一定要做的。

但一接入线上后，发现并不是那么回事，短期会涌入大量错误，不同重要程度的错误，杂在一起，难以区分。

一时不知，该如何下手。

久而久之，就任由其增长，置之不理。

同时，线下似乎也无异常反馈，就更加坦然处之。

回到我们搭建错误监控的初衷。

接入前端错误监控的目的，本质是为了，通过真实监控生产前端错误，以此数据为支撑，确定生产健康状态。

可以认为，任何错误一定会影响部分逻辑，也就是说，一定是某种程度的生产问题。

无论，它是第三方依赖，还是自身应用爆出的。

原则上看，任何生产问题都应该被"解决"，这个"解决"，只有两种：

- 排期处理- 标记无需处理

社区也有谈到错误分级的问题。但我认为，无论分多少级，背后本质也是对应上述的两个动作。

那么为什么现在大家不会去“解决”呢？

可能是因为我们习惯于一个假设，那就是，真有问题早就有人反馈了，线下平静，就代表正常，改不改无所谓。

想想，如果某个问题是通过拉群反馈，哪怕只影响到一个人，估计十分钟之后就上线解决了。

那么，真的所有问题都会通过这类方式反馈上来吗？很显然，不是，错误监控中的数据，可以认为是，最全面，最真实的展示。

如果，我们只想着关注此类问题（人肉反馈），那么，前端错误监控还有存在的必要吗？关注群不就可以了。

所以，以清零错误，“解决”所有生产问题为最终目标（非立刻，而是在一定周期内），还是有必要的。

另一个问题出现了，做这个事情是有成本的，收益如何评估呢？

其实，也很好理解，自己负责的项目，生产出现问题，“解决”问题，本身就是正常的工作内容，确保业务真正一切正常，便是最大的收益。

那么，即使认识到上面所说的，是否就能达到清零的目标，并且可持续呢？从过往的经验看，显然也不行。

那要靠什么呢？可能还要靠绝对强硬的制度与考核，毕竟完全长久性地，靠人自发，是不靠谱的。

如果上面都做到了，最终可能会是这样：

• 真正先于业务反馈，发现问题

• 梳理与评估所有错误，从数据层面，确保业务项目真正意义上的健康

• 大家重点不仅停留在交付层面，而是开始具有关注项目的运行情况（错误是其中一种反应），综合能力上，得到提升。

与其说，错误监控效果的好坏，是个技术问题，不如说是个管理与实施问题。