昨天我谈了一个健康管理项目组的案例，现场DBA认为已经找到了解决这个小问题的关键，而实际上隐藏在这个小问题背后还有更大的问题。当时分析这个问题的时候，因为holadata存在一个BUG，无法从企业版D-SMART的分布式模式下下载数据，因此当时的分析仅仅依靠了现场DBA发来的几份问题诊断报告，而并没有全面地去分析数据。缺乏完整数据的情况下，分析问题和发现问题依靠的更多是经验，我对Oracle LOGON过程以及LOGON AUDIT过程的准确理解是我能够在不经意间发现这个隐患的关键。
昨天也有朋友给我留言说，通过监控，完全可以发现IO链路抖动的问题。实际上也并不一定是如此的。因为很有可能某个故障发生的持续时间只有1-2分钟，而且故障发生的频率也不高，而监控往往都是采样而不是持续性的，持续性的采样只能从内核来实现，成本太高，已经不属于监控范畴而属于TRACE了。TRACE的成本是极高的，不大可能在一般系统中开启。而基于采样的监控，对于低频发生问题的发现是存在一定概率的逃逸的，因此低频问题的监控，我们需要从多个侧面来进行问题发现。从该问题可能影响以及带来的多种迹象中，只要能够抓住一种，触发告警，从而促进问题的发现，就达到监控的目的了，并不一定要追求直接命中问题。
从holadata发来的数据看，在11号7点左右故障发生期间，基线告警是存在几次db file parallel write延时过高的告警的，不过并不严重。因为安全管控问题，最近系统调整了权限，关闭了所有OS采集的权限，因此系统没有采集操作系统IO延时情况，也没有采集操作系统的日志，所以仅凭这个告警还是无法定位问题的。而且基线告警的数量庞大，作为告警来使用，那么运维人员每天就不用干别的，所有时间都来看告警，十来个DBA也干不过来。因此此类的无效告警实际上对运维是没有太大价值的。我们一般都只关注故障模型的告警。
从9号到现在的数据来看，系统产生的严重告警数量并不多，和链路故障有关的告警主要有“运维对象连接失败”、“LOG FILE SYNC延时过高”、“非正常状态进程数量过多”这几个告警了。
从诊断结果上看，确实是进程会出现D状态的进程，这是IO子系统存在问题的另外一个侧面的表现。
今天谈了半天，都是谈的系统如何监控，如何从不同的角度去发现系统可能存在的问题。似乎有点跑题了，今天的题目是“从IPHONE手机误报车祸说起”，实际上这个话题也来自于近期IT界比较热门的一个话题。苹果手机里有十分强大的传感器，借助苹果ICLOUD强大的算法能力，可以为手机使用者提供很强大的功能。车祸自动报警就是其中一个十分实用的功能。当车祸发生时，如果能够及时报警，重度车祸人员被救活的几率要高出很多，如果车祸第一时间没有人告警，等到有目击者告警的时候往往就错过了最佳的拯救时间。因此很多人把车祸告警这个功能，一旦出现车祸，能够第一时间获得救治。
不过问题来了，苹果的算法再强大，也只是基于数据的一个模型计算而已，其中就有一定的出错概率。如果某个城市很多人都开启了这个功能，对于如此巨大的基数，再小的概率都会产生巨大的告警量，城市公共资源因此就不堪重负了。昨天我看到的一个案例就是因为一个哥们玩过山车忘记关闭车祸告警，玩得很嗨的时候发现下面开来了警察救护车。
IPHONE车祸告警的这个案例实际上和我们的IT监控告警十分类似，我们在IT运维监控时也面临类似的困境，某些情况是否要把告警推送到告警台上，如果狼来了的事情太多了，警察还会不会把IPHONE车祸告警当回事，真的狼来了怎么办？
更精准的告警是运维监控一直在追求的目标，告警收敛也是精准告警算法的关键技术。在这方面要想做好也不易。IPHONE的车祸告警功能开发团队有可能考虑到了越野穿越的场景，而根本没想到还有一个坐过山车这种与车祸十分类似的场景，所以才导致了各种乌龙告警的频发，随着此类事件的不断出现，车祸告警的准确性会越来越高，最终越来越实用。
几年前我拜访一个客户的时候，他十分头疼的告诉我，他的数据中心有30多万台服务器，各种数据库3000多实例。哪怕告警系统已经通过算法收敛了90%的告警信息，他的手机上每天接收的基线告警和日志告警就有数万条。以前发短信的时候，他的手机经常半天就没电了。现在他们把告警信息发到微信群，而且把告警信息分类，把一些不重要的发到一个告警群，重要的发到一个严重告警群。不过每天收到的严重告警还是有数千条之多，还是看不过来。
正好这个时候收到了一条“不重要”的告警消息，他拿给我看，我一眼就看出来，这条并不是不重要的短信，而是很重要的。他收到的是一条ORA-1555的告警，如果是Oracle DBA，可能对这个经典错误告警已经很熟悉了，大多数DBA遇到此类告警，也会放在一边的。不过我当时就看出问题了。ORA-1555有五六种常见的场景，其中一种是因为某个索引的itl因为Oracle的一个BUG出现了错误，指向了错误的UNDO RECORD，此类错误实际上是一个索引数据逻辑损坏，一旦访问到这条记录，SQL马上就会报ORA-1555，如果索引不重建，此类SQL会永远报错。丢弃这样的告警，实际上是一个错误的做法。
很多朋友都觉得精准告警需要通过算法来实现，因为依靠传统的经验与知识，做了几十年也没做好。不过我觉得运维知识还是实现精准告警的关键，而依靠现在越来越强大的算法与算力，运维经验应该能够发挥出更大的效能。而目前对于经验的发现来说，某个企业或者群体还不足够，只有社区的力量才能做得更好。对于苹果这样的TOC产品，广大的用户群体可以为苹果积累巨大的案例库，而对于运维监控系统这种TOB的业务，想要达到TOC的效果，搞好社区是关键。这也是我们坚持做DBAIOPS社区的主要原因。
