暂无图片
暂无图片
暂无图片
暂无图片
暂无图片

多听听不同意见是有好处的

白鳝的洞穴 2022-05-16
1369
搞IT的人容易偏执,相信眼见为实,不喜欢听和自己观点不同的故事和观点。可能有人会觉得自己很能够兼听并蓄,不过事实上,在很多时候,坚持自己的观点可能才是常态。我也有这方面的问题,经常会就一个问题非要和不同意见者分辨清楚,有时候别人认同了我的观点,这时候我会很高兴,不过大多数时候,别人可能并不认同你的观点,这时候我会觉得有些沮丧。不过时候仔细思考思考对方的观点,发现其中也不乏正确的一面,有时候是自己考虑的过于极端或者片面了。只有不断地和持不同意见的人沟通,交流甚至辩论,对某个问题的掌握才能够更为清晰,每个人都有自己的思维盲区,每件事情也都有几个面,因此正确的思想往往不止一个。
“事实只有一个,观点各有不同”,这句话是时时提醒着我的,包括我所表述的只不过是观点,而不是事实本身,也不代表真理。说起来容易,不过一旦偏执起来,这句话很容易就被丢在脑后了。我们总是说的眼见为实也并不一定就真的准确,展现在你眼前的也只是一个现象,而不是隐藏在后面的真理,在你眼前这个场景中正确的观点也不代表能够适合于其他场景。有着不同经历的人在看待同一件事情的时候往往会有不同的观点,这是基于各自的“眼见为实”的。
自从开始做“运维知识图谱”之后,我的争辩的心淡了很多,因为从这些复杂的诊断路径上,我看到了超集繁复的复杂性和不确定性,两个完全相同的根因,可能表现出极其不同的表征,而两个完全一致的表征可能隐含着完全不同的根因。因为诊断路径的复杂性,导致了运维知识是一种网状的复杂结构,因此片面的认为事实就是如此,是十分危险的。
就拿日志分析来说吧,日志分析一直有两种不同的思路,一种是日志深度分析,使用专家的经验来分析日志,从而定位问题的根因。另外一种是大数据分析,认为专家经验分析可能很难覆盖全面,因此完全放弃专家经验,而是通过收集应用系统的广泛的日志,利用算法来找出异常。
这两种方法收敛报警风暴的方法各不相同,日志深度分析是完全依赖于专家经验形成的“分析知识图谱”的分析方法,通过专家梳理出的知识来开展分析定位,其优势是针对已知问题十分有效;而日志大数据分析是通过算法对上下游的各种日志进行异常检测,通过算法找出可能存在的异常。
我以前是坚定的日志深度分析方案的坚持者,经常用上面的这个Oracle错误信息的复杂性来否定大数据分析的可行性。同样一个错误信息,其产生的原因十分复杂,如果没有专家标注,是很难找到正确的路径的。似乎不管从哪个方面来看,这个观点都没错,这些年以这个观点和另一派的同行辩论的时候也是不太容易输掉辩论的。
不过观点和辩论都不是最为关键的,关键的是有效性。在大多数IT系统中,这种极端复杂性的问题分析场景极难遇到,因此有些时候上面这个日志深度分析的场景就像是屠龙宝刀一样,难得能找到一条龙来屠。而基于大数据分析的日志分析算法虽然说准确性不高,而且根因定位能力不足,但是对于一般的,常见的异常发现,效率还是比较高的。二者在不同的场景中能够发挥的作用是完全不同的,并不存在某个一定能用,某个一定不能用的问题。
那么是不是说基于大数据分析的异常检测算法的实用性就一定比日志深度分析高呢?这又涉及到场景与积累的问题了。虽然基于专家知识的日志深度分析其知识积累成本较高,但是一旦经过一段时间的积累后,企业的大多数日志报警的诊断路径都积累的很好了,那么其有效性高的特性就能够很好的发挥出来了。基于大数据分析的日志异常检测如果也积累了足够多的样本,并有专家进行了精准的标注,那么其根因定位能力也可以得到有效提升。
上面说的可能过于理想化了,不过在现实的IT运维中,如果能够很好的结合这两种技术,一种用于广泛的异常发现,一种用于深度的根因定位,那么是不是会更好呢?
多听听不同意见,多尝试下自己不喜欢的技术,肯定是有好处的,只不过很多IT人不太喜欢这么做而已。哪怕是最糟糕的想法中也可能有值得学习的逻辑,能秉持这种态度,才能更好的做好技术吧。
文章转载自白鳝的洞穴,如果涉嫌侵权,请发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论