基于报警处理的思考（r9笔记第88天）

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

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

对于当前的具体问题，分为了几个层面，
资源使用方面，有下面的一些类别。

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