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