运维的故事,故障处理系列(四)

海陆空立体式故障处理
接下来,老姜又讲了下他自己摸索的一套打法,他给这套打法定义成“海陆空立体式故障处理模式。“
”我们这边曾经遇到过一个很严重的故障,系统出现了一堆ORA-00600错误,导致查询的时候会报错,这个系统是核心系统,非常的重要。当这个故障报出来的时候,立马就直接升级到了我这儿,这个升级的过程非常快,我当时就在现场。我立马进行了指挥。首先我吩咐一线的工程师进行日志和Trace的收集和打包,并把这份打包的日志传输给三线的专家,同一时间开1级的SR,上传给Oracle Support。其次我吩咐二线人员,紧急就出现的600问题进行解决,当时主要出现的问题是索引块和数据块当中的数据不匹配。换句话来说,就是数据里面有这个数据,而在索引块里面没有这个数据,而通过索引查找数据直接就报ORA-00600错误。当时的解决办法就是重建索引。二线就在做这个事情。重建完成之后就能保障再次查询的时候不报错。而三线的工作就是接到日志和Trace分析问题产生的原因。他们必须尽快的找到事情的原因,才能够有效的进行问题的规避。因为后台报的600错误实在是太多了。这个时候局方的领导非常的着急,追着我就问,究竟是什么原因?什么时候能够解决。然后我把我的人员安排告诉了他,然后我还告诉他我们正在联系原厂的工程师到现场。我们的三条线起头并进,一起进行着协调工作,最大程度的提升了故障处理及分析的效率,这就是我的海陆空立体式故障处理的一个模式。当然大家一旦发现什么蛛丝马迹,都统一向我进行了汇报,这么做的好处是我们能够统一口径。这里我得说一下统一口径的必要性。以前我这里出现过一个故障,然后我的几个工程师一起在处理,结果那个问题有点复杂,一个人判断可能是应用问题,一个人判断可能是存储问题,然后他们分别告诉了应用的人和存储的人,这两个人就统一的反馈到了整个系统管理科室领导的耳中,然后领导劈头盖脸的就训斥我,我一会听人说是应用问题,一会听人说是存储问题,你们到底有没有搞清楚究竟问题产生的原因是什么?你们究竟专业不专业?从那个事情以后,我就要求大家只要是查到任何有可能引起问题的原因和问题所处的境况,都第一时间先反馈到我这里,由我来对外进行沟通和故障的阐述,这样我们起码能给人一种比较专业的形象。如果有人问你们故障到底是什么原因,你们大可回答,暂时还不是很清楚,你可以去问我们的领导,他比较清楚事情的来龙去脉!“
小李流露出崇拜的表情说道:”啊,是这样子啊,领导你要是不告诉我们,我们肯定会犯这种错误的。“
老姜微微的一笑,说道:”当然啦,这些都是坑来着,我们这些老人都给你们把坑都踩了一遍,现在你们只要按照我说的来做,肯定没问题。“
”后来那个问题怎么解决的?“小王若有所思的说道。
“这个问题后来经过查询发现和赛门铁克的卷同步软件有一些关系,后来被定位了出来,所以就算我们把索引都重建了一遍,如果根本原因没找到,还是没办法把问题给解决掉。“
 
寻找根原因,闭环故障处理
“在这里,我不得不另起一个话题,这个话题的名称叫做:寻找故障产生的根本原因。只有我们找到了故障产生的根本原因,我们才能够永远的把故障扼杀。做到一个闭环的故障处理。这里我给大家介绍一个案例,这个案例是发生在前不久,数据库无缘无故就CRASH了,于是客户就让我们分析原因,当时我们就根据系统的日志,找到了一些蛛丝马迹,我们的工程师就判断可能是某个bug引起的问题。建议安装补丁。当然Oracle的工程师也过来了,也分析了一通,然后和我们的判断是一样的,他认为是Oracle系统底层的代码出现问题引发的bug,对于这个CRASH是一个小概率的事件,因为这个补丁在Oracle Support上下载的人很少。当时他就建议对补丁进行安装,安装完了就可以规避这个问题。于是我们的人员就把这个补丁打上了,可是过了两天,系统又CRASH了一次,这下客户的大领导就坐不住了,把我们斥责了一番:’你们不是说这是个小概率事件的吗?怎么这个问题又发生了,你们究竟有没有搞清楚故障产生的原因?’当时我们都很郁闷,要知道分析这个问题我们也分析了1-2天,确实是这个bug也得到了后台的确认,究竟我们还有那些地方没有注意呢?”
老姜喝了一口水,语重心长的说道:“当时我分析这个问题,我只问了一下自己,为什么以前没有出这个问题?为什么现在出这个问题了?出现一次,我们可以说是巧合,说是遇到Bug,而短短时间出现两次,这样的几率是非常低的。一定是有什么特定的条件才会连续触发。所以当时我就把我的想法告诉了大家。我们在遇到故障要分析原因的时候,我们真的需要问问自己这个问题。当时我的下属就向我反馈了一个情况,说这个系统刚刚部署了一个SPA的采集脚本。我立马让他把部署SPA前和部署SPA后系统运行的一些情况做了一个对比,同时把所有的Trace在认真的都检查了一遍,终于我们在一大堆的信息中发现了SPA的身影,我立马建议把SPA采集停掉,果然停掉之后这个问题在没有发生。然后我又重新开启了SPA采集,并部署了警告的一个脚本,只要该问题一出苗头立马在我们的手机上显示严重告警,果不其然这个问题又重现了。我们赶紧停掉了SPA的脚本,阻止了事情的尽一步发生。所以我再强调一次,我们分析问题,一定要思考一个问题:为什么以前没出这种问题,现在出这个问题了?”
老姜为了能让大家更好的理解接着说道:“对于这个问题,我觉得最好的做法就是和历史对比,我们必须保留住以前的一些信息。一般我们进行历史对比的数据有几类:

  • 主机层面上的:OSWatcher(CPU、I/O、网络、内存)等等;
  • 主机层面上的:数据库层面上的:AWR报告(语句执行次数,硬解析,等待事件次数)等等;
  • 主机层面上的:监听层面上的:连接的会话数;
  • 主机层面上的:运维层面上的:是否部署了新的脚本;

“通过这一系列的对比,我们可以发现以前系统和现在系统中的一些差异点,很多时候我们的后台Alert会报一些错误号出来,这让我们的工程师可能会觉得这也许是一个Bug。但是我们仔细思考以下,一个运行良好的系统,出现一次这种问题,你可以说是Bug,确实有一定的几率会莫名其妙的出现,如果接二连三的出现这种问题,我想,说是Bug可能说不太过去,一定会是某项改动或者是变动导致的,当然也有可能是硬件上某个设备出的问题。这需要我们细致的通过上面的各个层面去分析变化性,才能找出最根本的原因。
“当然我觉得最大的挑战就是概率,以前我和一个朋友探讨过一个问题,我的朋友认为:一台数据库上面什么应用也不运行,基本上运行个3-5年都不会宕机,但是一旦运行了业务系统,那就说不好了,一年总是会有个把事故的。所以绝大多数问题都是业务系统导致的。而另外一个业务系统的哥们就不这么认为,他说我们的系统在多个省运行,有的省从来就没出现过问题,运行了3-5年,怎么跑都不会有问题。可是在你们的系统上跑就总是出问题,我觉得是你们系统设置的某个参数不对。综合他们两个人的观点,我认为这也许是一个化学反应。有可能确实是因为某个环境上的不一致,导致出现了某个连锁的化学反应,导致最终出现了这种宕机事件,我们只能把这说成是概率。就像我们买电子产品,有的人买过来怎么运行都不死机,有的人买过用了两天就死机了是一个道理。“老姜一口气把这些话说完心想,不知道这些新兵能不能理解,感觉我们做这个既像私家侦探,又像数学家,探讨这么高深的概率问题。
小李听完惊叹道:“领导,真是厉害啊,能把问题上升到这种高度,我们太佩服了,我们根本就没往这方面想过。”
此时老姜的心想,这也是这么多年摸爬滚打出来的经验,和运维人员打交道打的多了,各种各样的思想也都接触到了。
小王也跟着说道:“是啊,领导以后要多给我们培训培训这方面的知识,好让我们哥几个多长长见识。我现在对您的佩服又加深了一个档次。”
“少来,你们几个就知道拍马屁,我安排给你们的学习任务进度到哪里了?下个星期到底能不能把PPT写好,然后给我讲讲?谁知道我为什么安排你们几个讲课吗?”
大家伙面面相觑,一时都不敢贸然回答。
老姜又语重心长的说道:“给你们安排学习任务,是希望你们把业余的时间也抽出一部分出来用到学习上,干我们技术这一行就是逆水行舟,不进则退,如果你一天不学习,你就处于一个倒退的状态。不要以为有经验就很了不起了,技术更新换代是很快的。几年以前我还在用9i的时候,我都看statspack,而现在呢?出了awr,ash,addm这么多报告。如果我不学习,我肯定就被淘汰了。让你们写PPT是锻炼你们给领导汇报的能力,要知道不会汇报工作,你们还怎么混迹职场?举个很简单的例子,现在出了一个故障,这个故障被解决了,局方的领导会开故障会,我们必须把故障的来龙去脉以及处理方法都说清楚,你们要是上到台上去,话都说不清楚,即使你干活干的再好,也不会得到领导的赏识。因为领导根本就不知道你在说些啥。所以我让你们讲PPT也是锻炼你们将来汇报工作的能力。都是为了你们好。“
小王立马接道:”领导真是用心良苦啊,我一开始还很抵触这个事情,说真的,您给我安排的学习任务是RAC的理论,我觉得太复杂了,资料又少,我还很忧虑这件事情。“
老姜笑着说道:”前面我说过,有些同事不擅长交流,所以通过这个讲课活动,每个人都可以把自己的想法说一说,也能够促进彼此的交流。搞技术交流会不是比谁的技术更加厉害,也不是让你研究的多么深入,只是为了让大家多沟通,多接触。所以你不必担心。”
“哦,我心理的这块石头总算放下了啊,心理压力好大,好怕讲错。“小王接道。
老姜看了一下大家点了点头道:”另外我还想和大家强调一个事情,就是我们找到了故障的产生的根本原因后,还需要思考的一个问题:以后还会不会出现类似问题?如何避免问题再次发生?这个问题也是我们的客户非常关心的,每一次开故障会都会问我们这个问题。一般有workground的问题,我们就会直接告诉客户,以后类似问题不会出现,已经完全修复好了。而对于那种没有workground的问题,我们就需要思考怎么规避,对于那种需要修改底层代码及设计的故障,我们只能提供监控脚本,并且部署上。同时提供应急的文档。然后给大家分发下去形成学习任务。这样一旦出现问题,大家都能及时的通过主动型故障处理把它解决掉。这里说个题外话,我们把故障处理分为主动型故障处理和被动型故障处理,被动型故障处理就是我们经常遇到的突发性的问题,比如数据库突然宕机、系统有大量异常等待等等都属于被动型故障处理,而主动型故障处理是我们通过日常巡检,部署监控脚本来实现的,举个例子就是我们的PK脚本,这个脚本的主要作用就是监控当前的Session的PGA使用,一旦发现有Session使用的PGA达到一个阈值,比如10g,脚本会立马先记录下Session的信息。然后kill掉这个Session。这么做的好处就是把坏事扼杀在摇篮里面,因为像这种内存溢出的会话一旦爆发,会立马把内存耗光,导致数据库系统无法正常运行,与其被动接受还不如主动出击,占得故障处理的先机。当然这是个题外话。我们在回到刚才我们说的。我们通过主动型故障处理就可以给局方一个交待,以后还会出现类似的问题,但是我们部署了脚本,能够很好的规避这个问题。举个例子,前段时间爆发了一个很严重的SCN跳变的问题,这类问题只能靠改变SCN的算法来解决,短期类这类问题是无法解决的,所以我们只好通过监控来找到最先跳变的数据库,然后对其进行隔离,找出它自身SCN跳变的根本原因。最终形成闭环的一个故障处理。“
 
我们的大脑会骗人
外面下起了小雨,老姜他们还在开着会,看着外面的小雨,老姜突然想到一个事情,老姜问大家:“地面是湿的,是不是下雨了。”
小李立马抢着回答道:“如果地上是湿的,那肯定是下雨了。”
老姜又接着问道:“你是怎么知道的?”
小李说:“领导,你看啊,外面正在下雨呢?地面上肯定是湿的。”
老姜又说道:“你这么确定?地面上是湿的就一定是下雨造成的?”
小李一听觉得有点不对劲,仔细的想了一想说道:“这个嘛,我觉得如果正在下雨,就一定是下雨导致的,如果没有下雨,可能是其他的原因。”
老姜摇了摇头说道:“其实我想阐述一个观点,那就是我们的大脑会骗人。”
“啊?大脑怎么会骗人?”小李吃惊的说道。
老姜接着说道:“如果刚刚有一辆洒水车经过,把地面淋湿了,然后接着又下了点雨,然后我们出来看见地面湿了,我们一定会认为是雨造成的结果,而忽略了洒水车也造成了这样的一个结果。这是因为你看到了下雨,所以你臆断下雨就是原因,殊不知也许是一果多因。这个世界的很多问题也许并不是一果一因,所以我们在回溯原因的时候,切忌不要臆想,不要看见什么就说是它造成的,我们应该占据更加全面的资料,以更加客观的方式来进行问题的判断。举个例子,前一段时间我们这里出现了一个故障,系统总是莫名的宕机,根据后台的Trace我们判断是网络出现了异常,同时我们通过OSWatcher发现是网络上存在较多的坏包,于是我们就认定这个问题是网络问题,我们联系了网络管理员查这个问题。结果查到的结果让我们大吃一惊,因为网络根本就不存在任何延迟的现象,而UDP的坏包被认为是正常的一种可能性的行为。当时我们就一直局限在网络这个圈子里面,无法找到新的思路,直到后来该问题又重现了,我们通过抓取的AWR报告发现是因为应用导致了大量的GC传输,从而导致网络需要不停的互传,导致UDP坏包迅速的提升,最终引起的宕机。最终问题并不是网络引起的,而是应用引起的。所以我们在分析复杂问题的时候切忌不要臆想,要多用客观的证据是证明我们的推论。
老姜看时间差不多了,想着要回家接孩子下班,于是说道:“今天关于故障流程的会议就到这儿吧,你们下去之后把我的话好好的消化消化,这些都是我在这一行摸爬滚打这么多年的经验之谈,我希望你们不要犯错,对于运维行业来说犯错的成本实在是太高了,我会时不时的对你们进行这方面的考核。希望你们不要忘记我今天所说的。”
小李和小王齐声附和说道:“谢谢领导的谆谆教诲,我们一定会好好努力做好这份工作的。”小王说完和小李相视一笑。
老姜看在眼里。他希望这批新人快点成长起来,因为现在信息化发展越来越迅速,要维护的系统也越来越多,以前5个人维护几十套系统绰绰有余了,现在系统有200-300套之多,还要分出一批人去做应急容灾、数据治理、模型等业务,要10-20几个人才能干的过来。

分享到: 更多

Post a Comment

Your email is never published nor shared. Required fields are marked *