浅谈告警平台的设计思路

一个告警平台检测和告警是密不可分的，检测用来发现异常，告警用来将问题信息发送给相应的人。如果说检测是一瓶红酒，那么告警就是开瓶器，不然只能望酒兴叹。

      对于很多运维团队而言，监控被划分为基础监控、调用链、日志监控、拨测监控等等，也会归属于不同的小组，更好的方式是将各个监控指标数据进行统一计算、统一存储、统一检测、统一告警、统一展示，同时将各系统告警收敛能力与告警发送能力下沉，将统一告警做成一个与各监控服务解偶的通用服务，结合管理（on-call机制）、脚本故障自愈等做到问题的处理与闭环。

一、告警与处理的逻辑

告警链条的逻辑可以分为以下三个方面：

事件输入：通常遇到的问题是事件太多，没有合理的检测机制

事件决策：决策往往大而无当，狼来了的故事太多

事件处理：真正要处理、需对的责任方处理的事件没有合理的分配

二、告警平台究竟要解决哪些问题？

输入端：数据精准、详实、全面、及时，为决策端夯实基础

决策端：策略有效且符合业务现状、有收敛、有压缩、有合并

处理层：理想状态时有告警必处理，但实际依赖于管理与告警的精准度

三、衡量指标

管理学大师彼得·德鲁克曾说“你如果无法度量它，就无法管理它。如果想全面管理提升一个系统，就需要先对它的各项性能指标有一个衡量，知道它的薄弱点在哪里，找到病症所在才能对症下药。

      以上是监控系统运营指标和对应时间节点关系图，主要体现了MTTD、MTTA、MTTF、MTTR、MTBF等指标与时间节点的对应关系，这些指标对于提升系统性能，帮助运维团队及早发现问题有很高的参考价值。业界有很多云告警平台也很注重这些指标，下面我们着重介绍一下MTTA、MTTR这两个和告警平台关系紧密的指标：

MTTA(Mean time to acknowledge,平均应答时间)：

（以上为MTTA计算公式）

t[i] -- 监控系统运行期间第i个服务出现问题后运维团队或者研发人员响应问题的时间

r[i] -- 监控系统运行期间第i个服务出现问题的总次数

      平均应答时间是运维团队或者研发团队响应所有问题所花费的平均时间。MTTA度量标准用于衡量运维团队或研发团队的响应能力和警报系统的效率。通过跟踪和最小化MTTA，项目管理团队可以优化流程，提高问题解决效率，保障服务可用性，提升用户满意度。

MTTR(Mean Time To Repair,平均维修时间)：

（以上为MTTR计算公式）

t[ri] -- 监控系统运行期间第i个服务出现r次告警后服务恢复正常状态的总时间

r[i] -- 监控系统运行期间第i个服务出现告警的总次数

      平均修复时间（MTTR）是修复系统并将其恢复到正常功能所需的平均时间。运维或研发人员开始处理异常，MTTR便开始计算，并且一直进行到被中断的服务完全恢复（包括所需的任何测试时间）为止。在IT服务管理行业中，MTTR中的R并不总是表示维修。它也可以表示恢复，响应或解决。让我们简要地看一下它们各自的含义：

1）平均恢复时间(Mean time to recovery)是从系统告警中恢复所需的平均时间。这涵盖了从服务异常导致告警到恢复正常的整个过程。MTTR是衡量整个恢复过程速度的指标。

2）平均响应时间(Mean time to respond)表示从出现第一个告警开始到系统从故障中恢复到正常状态所需的平均时间，不包括告警系统中的任何延迟。该MTTR通常用于网络安全中，以衡量团队缓解系统攻击的效率。

3）平均解决时间(Mean time to resolve)表示完全解决系统故障所花费的平均时间，包括检测故障、诊断问题以及确保故障不再发生来解决问题所需的时间。此 MTTR 指标主要用于衡量不可预见事件的解决过程，而不是服务请求。

于一个统一告警平台而言，告警服务要能简单、高效、准确的告诉运维或者开发人员，哪里有故障需要去处理。所以对于后续服务的建设，应该考虑如何进一步减少人为的配置，增强告警智能化收敛的能力，同时还要增强根因定位的能力。这是一个长期的工程，需要业务与运维的持续共建，而他的价值是历久弥坚的。