晚上在琢磨怎么把报警的处理实现自动化的功能,想来想去,发现其实很多内容都是相通,在纸上写写画画,简单理了理自己的思绪。
人嘛,有时候不逼着自己,只会更加懒惰,而一旦迈开了步子,可能就停不下来了,问题也有轻重缓急,我们来理一理。

基于报警处理的思考(r9笔记第88天)_Oracle我的一个简单总结,问题分为三类,当前问题,潜在问题,历史问题。
当前问题是实时抓取的状态信息,在这个基础上需要去做一些及时的响应和处理,这个过程也就会涉及到精细化运维的部分。
潜在问题需要提前发现,提前预警,这个涉及到半自动化运维,自动化运维
历史问题,遗留问题,解决起来难度较大,需要数据分析,通过数据的可视化,或者只能分析来达到目标。
而当前绝大多数的系统来说,问题的处理都是基于报警信息,也就是基于问题处理问题,所以基于报警信息的处理,大部分解决的是当前碰到的具体问题。

基于报警处理的思考(r9笔记第88天)_Oracle_02对于当前的具体问题,分为了几个层面,
资源使用方面,有下面的一些类别。
基于报警处理的思考(r9笔记第88天)_Oracle_03
这些也是在报警信息中基本都覆盖到的一些问题。都从各个层面反应出数据库,系统,应用的诸多问题。
而基于等待事件,也就是非常流行的OWI,这种方式本身很有说服性,但是经验论,方法论涉及的成分较多,单纯去分析等待事件可能收效不大。
而在此需要额外注意的就是基于DB time的方式,分为两种,一种是实时的DB time,一种是基于快照的方式,两种各有优劣,基于实时的DB time计算会基于上一次的快照数据得出一个递增的动态值,而基于快照的方式得到的是一个静态值,而且从得到的数据来看,基于快照是后知后觉。报警系统中的很多问题基于DB time可能会引刃而解。但是这种方式有点儿值得推敲的地方,一个就是实时的DB time,可能有一些突发的抖动,可能业务上的需求等,如果沟通不够充分,可能这类问题基本就是发现问题,分析问题,确认问题,忽略问题这样的套路。还有一类问题是反反复复出现,可能本身影响不算大,比如设定DB time的阈值为400%,结果2分钟内DB time到了450%,而后迅速跌倒了200%,这种方式如果反反复复就会出现大量的报警和报警恢复信息,这类问题其实还是比较纠结的。
而基于快照的DB time则是一种后知后觉的方式,对于整体的系统负载和问题的基本定位还是大有裨益,但是解决很多突发性的问题可能信息量不够。
最后一类是基于并发和锁,这种问题一旦出现,可能需要立即响应。这种影响的范围也是全局性的。
这些信息如果在Oracle中和优化工具结合起来,如果使用得当,那就是一块瑰宝,能够很容易实现精细化运维,半自动化,自动化运维的内容。这些内容现在还在盘算,已经有了一些思路了。相信最近也会逐步理顺,付诸实践。