引言
身为一名前端开发者，我们通常会在业务中加入异常上报功能，以便解决以下两个主要问题：
- 主动上报异常，通知开发人员，使其能够及时响应并解决问题；
- 当用户反馈问题时，开发人员可以在已上传的异常日志中找到解决问题的线索；
我们经常会遇到各种各样的异常和告警。要处理这些问题，我们需要一个有效的告警策略来帮助我们识别并解决问题。在这篇博客中，我们将探讨如何运用统计学中的 正态分布理论 来制定前端告警策略，从而提高项目的稳定性。
问题背景
最近我接手了一个 老祖宗传下来的项目。随着这些年业务的拓展、开发人员的更替以及业务的迭代，项目出现了以下问题：
- 前端业务告警发送到多个群中，消息之多让人不想查看；
- 前端业务告警策略不合理，没有随业务及时更新维护，导致告警消息不精准；
因此，我们急需优化告警平台，加强告警信息的筛选和处理，以提高告警的准确性和及时性。
你能想象吗？企业微信群里每天都有几十条告警，但是没有人排查。领导也不说话，开发也不说话，这是何等的尴尬。
解决方案
- 告警策略优化：只有影响使用的业务告警才发送告警信息（例如：页面崩溃、白屏）；
- 质量改进：安排专人定期分析历史异常信息，对发生次数排名较高和影响较大的问题，建立需求单并跟踪解决。
实施方案
告警策略优化
若不合理的拆解任务，会很懵，不知从何下手
在查看日志系统中的数据时，我发现一个月内大约有数十万条日志。仅凭肉眼观察，密密麻麻的日志中包含了有用的、无用的、重要的和紧急的信息。刚开始时，我完全无法分辨这些日志，一脸懵逼。
我们需要针对目标，合理的拆解任务。我们拆解成两个任务 确定维度 和 确定阈值，从这两个任务可以切入，可以很好的完成告警策略优化的事情。
- 确定告警策略的维度
我们将关注两个主要维度：告警次数 和 异常人数。告警次数是指在一定时间内发生的告警总数，而异常人数是指受到影响的用户数量。
- 确定告警日志的维度
接下来，我们需要确定告警日志的维度。在前端不断上报的各种类型日志中，我们需要关注的是 接口是否不可用、页面是否不可用。因此，我们将关注三个类型的日志：js-error（JavaScript错误）、ajax-error（请求错误） 和 render-error（渲染错误）。这三个维度涵盖了前端开发中的大部分异常情况。
- 确定告警时间的维度
这一个维度我直接参考业内的常规设置，一分钟 统计一次
- 确定告警阈值
维度确定好之后，就是本文的重头戏，如何对各个维度，设置合适的告警阈值，实现 既不漏报，又不多报。比如，js-error 这个类型的日志告警，在单位时间（一分钟）内 出现了多少次，影响了多少人, 算一个异常点，根据连续出现多少个异常点，来判断要不要在群里发一次告警信息，周知并触达到开发人员
「出现了多少次」、「影响了多少人」 就是告警阈值
异常点的判断，如果 PV / UV 比较高，可以初步根据
质量管理的理论来确定，连续出现 7 个异常点，就要触发告警
现在我们需要收集足够的历史告警日志数据，我从导出了过去30天内（样本尽可能大），然后根据我们定义的日志维度进行拆分。像本案例中将每分钟所发生的 js-error 次数（已经将 0 次过滤）过滤出来，总共是 43096 条数据
如果我们将这份数据制成条形图，它应呈现出 L型分布，且数值差异较大。例如，在一分钟内发生 1 次 js-error 的情况共有 34 次；而在一分钟内发生 31 次的情况仅有 1 次。
看到条形图，是不是很像我们高中数学的 正态分布图 的一半，中间大两边小
在计算 告警阈值 前，我们通过统计学的理论进行初步的分析，样本数据的众数和中位数是 1，但最大值却是 31。很明显我们的样本数据离散程度比较大，所以我们要去掉离群值（是指在数据中有一个或几个数值与其他数值相比差异较大），在本案例中我们去掉大于 10 次的情况。得出 修正的标准差。
对一组数据进行均值、众数、中位数、标准差的计算，都可以用 Excel 表的公式处理
由于离散程度较大，所以计算出来的均值也不太可信，我们用
众数替代均值代入公式进行计算
依据正态分布理论，我们只需要关心 2倍标准差 之外的告警。这是因为在正态分布中，约有95%（通过算曲线面积得到）的数据位于均值（众数）的 2倍标准差 范围内。本案例中，我们是一半的分布曲线，所以2倍标准差范围之外，大概是 2.2%。因此，如果某个告警的次数或异常人数超过了这个范围，我们可以认为它是一个异常值，需要引起我们的关注。
我们来确定我们的告警阈值：众数 + 2倍标准差 ≈ 4 次，我们的告警策略是：1 分钟内出现 4 次 js-error 日志，算 1 个异常点，连续出现 7 个异常点，就要在企业微信群里发送告警信息，周知相关人员并触达给开发人员，开发进行修复。同理可得其他维度的告警策略，render-error、ajax-error 等
位于 2 倍标准差之内的异常，我们认为它是正常范围的异常，且这些异常肯定是存在了很久，不会引起重大事故（崩溃、白屏...）。 2 倍标准差之外的异常，可能是由于最近的发版、后台接口突然不通等情况引起的问题
此外，我们只需要得到一个大概可行的值，计算结果不需要很精确
质量改进
除了处理 2 倍标准差之外的异常，我们还需要关注 2 倍标准差之内的异常（正常范围内的异常）。这些异常不需要我们实时关注，也不需要在群里发送告警信息，因为它们不会引发重大事故。我们的策略是定期处理，例如每两周处理一次。处理策略如下：获取过去两周的异常日志信息，针对发生次数较高和影响较大的问题，创建需求单并跟踪解决。通过几个迭代周期，我们可以借助 戴明环（PDCA循环） 的质量管理思想进行质量改进。
成果展示
在优化之前，群里的告警消息日均达到几十条。
优化后，我们可以分为两个阶段来观察：
- 前期：日均告警消息量降至两三条，持续了2-3周，逐周递减。这是因为我们在收到告警消息后立即处理了历史异常问题。
- 后期：每周最多只有三条告警消息。这并非是因为代码质量问题，而是因为用户使用了浏览器插件导致页面报错（针对这类错误，我们会逐一发现并进行日志屏蔽）。
根据优化结果，我们会动态调整阈值，因为随着历史问题的解决，标准差会逐渐变小并趋于稳定
结束
实践出真知，本文通过一个真实的案例，确定运用正态分布理论制定前端告警策略是一种有效的方法。通过关注 2 倍标准差之外的告警，我们可以更好地识别并解决问题，从而提高项目的稳定性。希望这篇博客对你在前端开发中处理异常告警有所帮助！
