运维主管对于告警的10大需求

在监控产品中，告警是一个绕不过去的重点内容，那么，客户实际对于告警有需求呢？

对于告警需求来说，一般分为三个方面的需求，分别是运维部门主管的需求、告警平台负责人的需求以及使用告警的业务系统管理员的需求。

本文重点介绍一下来自运维部门主管的需求要点

来自运维部门主管的需求

作为运维部门一把手，对于告警更多从及时性、完整性、规范性方面关注

1、产生的告警要尽快通知负责人

告警发生后，每一秒种都是在生死线上抢夺时间，一般都要要求在1分钟内告警，核心系统的核心问题甚至要求秒级。

2、覆盖面要全

既然有了告警系统，就必须把所有核心业务系统都要覆盖到，否则没有被覆盖的系统、组件、主机、集群出现了问题，损失就到了。

一般从业务系统维度、标准告警落地覆盖维度提供覆盖度报告。

3、整合多源告警，尤其是历史监控系统

企业在历史监控中，肯定购买了很多不同类别的监控系统，有些还是定制的，或者干脆就是原业务系统配套监控，这些已经有了的监控点，肯定要归纳到企业的集中告警平台中。

4、告警与标准运维动作

告警一旦发生，如何快速解决就是核心问题，对于那些已经有了响应预案的故障来说，最应该做的就是找到对应的恢复手册，如果可以提前将告警与标准动作（恢复手册、应急预案、运维知识库）连动起来，那么看到告警的同时，运维人员也可以看到解决方案，这样恢复的也快，考核的也方便了。

当然这块未来可以升级为故障自愈。

5、告警默认升级策略

在告警发出后，如果原定的负责人没有收到或者一段时间内没有及时处理，那么告警也不能不处理，所以必须赶紧通知他的上级。这时候就需要告警自动升级策略。同时，这数据也得与考核挂钩。

6、告警问题的后续处理

有的告警提出的问题比较复杂，一线人员无法短期内解决、甚至做紧急处理，这时候就需要申请二线、乃至三线的专家给与协助，首先应该是线上呼叫，成立快速小组，之后也应该在系统上补单，明确整个流程发生了什么、怎么解决的、谁来解决的、用了多久的时间，这里往往就需要告警与其他系统进一步联动，并且传递以上信息。

这也是二线、三线专家的重要工作来源和考核依据，也是作为运维知识库的主要来源。

也有的告警告出来的问题，只是表征，虽然可以通过快速恢复动作进行紧急修复，但是往往此类告警多了，也代表着存在跟深层次的问题，企业也许需要一些改进。这时候，可以将告警转为企业内部的一种改进工单，往往就需要与ITSM做联动。

7、标准告警配置库的支持

在企业中对于一种设备、系统、场景总是存在类似的告警配置，这样告警配置也是经过优秀运维人员反复打磨，可以最大程度保障系统的告警监控手段，企业需要将这些组织财富收集起来，并且在新系统、新员工上进行推广。

同时，对于发生过得事故也需要及时复盘，复盘的成果之一就是形成标准告警配置要求，纳入到标准告警配置库中

8、告警设置的有效性统计

在系统多、人员多的情况下，每个系统都设置告警，往往就有成百上千的告警配置，每个告警配置都在产生告警、消耗企业资源、消耗运维人员的注意力，那么这么多告警配置中，哪些是乱告警、那些是从来没有发生过告警、哪些是告警数据与配置之间的比例是否正常，这些都是运维主管需要关心的问题。

处理不好就容易造成，无效告警乱发，直接产生告警风暴，或者你以为告警配置好了，实际上配置错误，根本没有发挥作用，这些都可以通过告警有效性统计来发现。

9、告警响应时间统计

告警发生后，每个环节的时间要做好统计，包括第一次接到告警的时间、紧急处理完毕时间、彻底解决告警问题时间。

只有对这些时间做好统计，日后才可以进一步优化企业在告警响应方面的速度，才可以减少突发问题给企业带来的损失。

也是各个运维负责人工作考核的重要标准之一。

10、支持轮岗支持

在企业中，往往是多个人对一个业务系统进行运维，或者有白天、晚上不同的人员进行分工。

这时候，告警的配置如果过于简单，不分时间的对所有负责人进行告警通知，那么对于正在休息的运维人员来说就是一种煎熬，休息不好，那么上班的效率也会大大折扣，所以要配合好企业的轮岗安排，根据当前值班人员的名单，结合告警负责人，动态发送信息给运维负责人。