监控体系建设（完整）(6)

能知道如何查到某支或某类交易出现了问题,是大面积、局部,还是偶发性问题,能用数据说明交易影响的情况,能定位到交易报错的信息.这里最常用的方法就是数据库查询或工具的使用.知道最重要的交易如何检查是否正常,重要的定时任务的应急处理方案,比如开业、换日、对账的时间要求及应急措施.

(4)沟通方案：

?沟通方案涉及通讯录,包括上下游系统、第三方单位、业务部门等渠道.

另外,有了应急方案,如何让运维人员持续去更新是难点.我认为要解决这个难点,需要先让运维人员经常使用这个手册.如果一个手册没有场景可以用,那就需要管理者为运维人员创造机会去使用这个手册,比如应急演练.

五、持续优化

1、整体思路

监控系统建设目标是完善“监”能力,增加“控”的能力,这章提到的持续优化主要是针对“监”能力的落实,归纳起来就是“不漏报,少误报”,可以针对不同的阶段量化目标,比如60%告警即故障,80%故障来自监控.

2、措施

1)目标分解：

??? 不漏报

漏报可以从两个层面看,一个是监控工具不具备某一方面的监控能力；一个是监控工具具备监控能力,但因为使用者使用问题导致未覆盖监控.前者需要完善监控能力,比如针对生产故障举一反三式的优化,或由不同专业条线主动增加监控能力；后者则需要考虑几个问题：

-管理上有没有要求指标的100%覆盖率

-覆盖率的要求是否确实可以落地,或功能上是否设计极不友好

-100%的覆盖率是否从技术默认设置,如果技术无法默认设置,能否从技术上主动发现

前面两个问题需要从管理手段上解决,最后一个问题需要在监控系统中解决,即尽可能让需要覆盖的监控指标从技术上落地,减少对运维人员主动性上的依靠,同时监控系统要快速从技术上响应新的监控指标的落地.

??? 减少误报

误报带来的问题也很大,大量、反复的误报告警会让运维人员麻木,进而忽视监控报警,错过了真正的监控事件的处理,所以监控误报情况也需要重视.

2)心得：

以下是在监控优化上的一些措施心得供参考：

第一阶段：减少监控报警数量

目标：每周报警总量上下降60%

主要工作：

??? 抓突出的报警指标,调整阀值,比如CPU、内存、空间、应用性能这几块大头,如果阀值不合理将带来大量告警,对这几类指标阀值做优化会有事半功倍的效果；

??? 抓每个指标突出的组、系统进行针对性整改,可能就是某个团队或某些管理员不重视监控,解决刺头的成效也很明显；

??? 针对重复性的告警,优化监控系统,减少重复报警；

第二阶段：减少监控误报率

目标：60%告警即故障(排除磁盘、表空间类)

主要工作：

??? 区分监控级别,告警即故障：分析确认哪类监控报警必须作为事件处理,并将交易量监控设置为告警,非故障调整为预警；

??? 所有预警即关联工单,对预警工单阀值进行分析调整；

??? 优化监控短信内容,提高短信对事件定位；

??? 完成动态基线的监控功能上线功能,提高监控准确率；

??? 完成应用部署与监控维护期关联,减少未设置维护期导致的监控报警；

??? 完成应用启停集中处理,减少应用启停带来的维护期报警；

第三阶段：提高监控对故障的覆盖率

目标：80%故障来自监控

主要工作：

??? 每周分析生产事件的发现环节,对于非监控发现的故障进行专项分析；

??? 其它方案(针对第一、二阶段实施情况完善)

第四阶段：提高监控事件处理效率

目标：监控告警1小时内关闭

主要工作：

??? 对监控报警耗时进行分析,并通报；

??? 针对无法快速恢复的监控报警优化功能处理；

??? 其它方案(待定)

3、团队

因为有持续优化的工作,所以最好能够有一个横向的监控优化团队,区分于监控系统工具建设团队,作为监控的使用角色,这个团队有几个目标：

??? 将持续优化的工作进行落地；

??? 作好数据分析,比如监控的事件量是否突增,某些系统的事件是否陡增,误报量是否过多,故障哪些不是通过监控发现,未通过监控发现的故障是否完成监控覆盖面整改,监控功能有哪些不友好等等.

整理的内容有点长,有点罗嗦,稍整理了整篇总结的思维导图：

文章来自微信公众号：运维之路

（编辑：ASP站长网）