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

故障流程管理
出了故障怎么办? 快速解决还是查原因?
周五开会,老姜着重点名让几个新人参与,老专家一律不参加。老姜想让小李把这一周遇到的故障来龙去脉及处理的过程说了一遍。小李说完,老姜就开始问话:“大家觉得出现了故障我们应该怎么办?一个一个的来回答?”
小王:“沉着冷静的应对突发性的故障,先判断能不能解决,如果不能解决,就开始打电话上报,请求专家的支持。”
小周:“我觉得吧,出现了故障,一定要有思路,找到可以突破的突破点!”
小李感慨颇深的说道:“我觉得应该注重先恢复业务,然后在去找思路解决。”
老姜点了点头继续说道:”假设现在有一套数据库Hang住了,你们应该怎么处理?“
小王抢着说道:”首先我会做个hang analyze的分析,然后看看是那个造成的阻塞,然后我把阻塞进程杀掉就行了。“
“嗯,假设你做了hang analyze的分析,没有会话造成阻塞,你又该如何处理呢?“老姜接着问道。
一时没有人能够再接着回答,老姜顿了顿说道:”对于这个问题,很多人和你们一样,只是考虑了技术层面上的解决办法?而没有讨论从业务层面上的解决办法?“
”业务层面?“小王疑惑的看着老姜。

”对,数据库hang住会导致业务无法继续,很多前台的操作都无法进行,试着想象一下,你现在在某个银行窗口排队取钱,而银行前台人员无法给你办理,因为后台数据库出问题了,你需要等后台数据库人员慢慢的分析问题?分析出了问题才能让你的业务继续,你们能等吗?我想基本上没有人会在这里继续等下去,因为大众对于银行自身的效率就很不满。我有时候经常去排队办理个业务都要等半天。所以啊,还是那句老话,故障分析固然很重要,但是业务的连续性更加重要,此时我们唯一的做法就是把数据库的全部会话杀掉,如果是RAC,可以考虑迅速把一个节点给停掉。这样我们就能保证业务只是小小的中断,还能继续的高效的办理各种业务。在很久很久以前,我曾犯过这个错误,那个时候我和你们一样,是一个技术人员,总是只考虑了技术层面上的问题。考虑到自己的这一块,没有从整个业务上顾全大局,因为数据库也是给业务服务的!“老姜语重心长的说道。
这个时候的老姜陷入到了沉思,同样是在N年前,自己刚刚进入这一行的时候,运维还处于萌芽阶段,那个时候什么都不懂,经常出了问题就是埋头苦干,总是想靠技术来解决问题,但是每次都适得其反,导致大面积的停机,最后被业务部门的老大批评,说他不会从全局考虑,那个时候的自己没有少挨过批。也就是从那个时候起,老姜摸爬滚打经历了各种各样的困境,才有了今天的这些经验,看着这些新兵,一进来就有一套成熟的体制给他们,他们能少走很多的弯路。
大家伙听完老姜的话后,点了点头,小李作为经历过一次故障的新人提出了一个疑问:”那我们把数据库重启了,不是v$那些内存视图的信息都没了吗?对于我们查询故障的原因是不是会很不利?“
“那当然,鱼和熊掌是不可兼得的。但是呢?你们还是可以做一些事情的?你们几个仔细想想,数据库现在要直接停止前,我们能做些什么?“老姜说道。
小王抢着答道:“我觉得是生成最新的快照吧,在重启之前,生成一个新的快照,能帮助我们把很多信息记录下来,还能帮我们生成AWR报告呢。“
“嗯,我觉得在正常情况下可以做快照,但是数据库是hang的,我们又怎么做呢?我觉得收集个hang ananlyze的信息也不错。但是得收集3级的,因为3级的更加详细。“小李说道。
大家你一言,我一语的说着各自不同的意见,在这个问题上并没有一个统一的答案,老姜的心里也没有,因为针对的情况不同,无法盖棺而论。老姜只是说了以下几点:”首先你们要考虑你们的情况?如果没hang,我觉得做个快照是可以的。如果是hang的情况,我觉得小李的方法可行,就是做个hang analyze,然后还可以做一个ash的dump,把最后5分钟或者10分钟的ash的信息dump出来。这样在重启之前,我们也算是保存了一份当时会话的信息。也是用oradebug命令。这个命令大家要可以回去研究下。这个话题到此为止,我们来讨论下一个话题“
 
埋头解决 or 快速升级
老姜继续说道:“今天还有几个问题要给大家交待一下,出了故障,我们得判断故障的可控性,比如数据库无法启动的这类问题,这类问题属于比较严重的问题,我们需要考虑故障升级的问题。在我们的团队,我将大家伙分成一线,二线,三线,一线的工程师就是刚刚进来,和你们一样,主要的任务工作就是日常的基础运维。基础运维包括日常的巡检、基线的检查、监控及数据库日常的一些管理任务。同时,我们还提供了故障知识库给大家学习,这样面对一些简单的故障,大家还是可以得心应手的。而二线就是一些高级的运维,可以解决一些复杂的故障,是现场的大拿。三线也就是专家,一般不在现场,负责解决一些疑难杂症。当然有些问题是属于内核、底层代码或者是算法的问题,这类问题我们根本不能够解决,只能依赖厂商才能处理。当出了问题之后,你们要先进行判断,这个故障我已经有处理过的经验吗?如果没有处理过你们就直接升级二线,让二线进行处理。这个升级的过程一定要快,因为二线和你们一样也是在现场的。这里给你们说一个典型的例子,以前我这有一个下属,有一天业务人员需要增加数据文件找到了他,然后他就开始做添加表空间的这个事情,这本来是一个很简单的事情,可是它发现怎么添加都报I/O错误,然后它就在这里慢慢的检查究竟是那个地方出了问题,就这样检查了30-40分钟也没搞定,因为没有加上空间,业务人员就着急了,就去我们数据库科室的领导那里投诉了我们,直接导致后来就把我骂了一顿,说我工作没做好。我也很郁闷,把他拉过来问话,我发现他是一个相当闷的人,不擅言谈,是一个非常典型的IT屌丝,只懂得埋头苦干,我当时就和他谈了谈心,让他不要太内向了,其实很多工程师本身就是很内向的人,不擅于和他人进行有效的沟通。所以今天把你们几个拉过来开会,我也想再次阐述下,你们要经常的在一起交流,不要总是顾着埋头干活。出了问题,你发现你解决不了,你就可以把责任给卸下来,交托给有经验的人来处理。如果当时这个工程师直接告诉二线,二线的工程师很快就会定位出是主机的问题,然后联系主机的工程师,就不会把这个事情的责任算到我们的头上了。大家明白吗?在很多事情上面,我们都要避免类似的错误。大家还记得以前有一个节目叫《开心辞典》吗?主持人会问一些比较复杂的问题,如果这个时候你没有办法答上来,你可以选择求助现场观众或者是求助电话热线,在我们的日常运维中,求助现场观众就是求助二线工程师,而求助电话热线就是求助三线的专家。还有一个事情我也得提一下,我把它叫做“安全边际“,有时候我们可能会遇到各种各样的问题,比如你发现数据库的问题可能是主机上某个设置引起的,你或许会觉得我帮主机的人把这地方改掉就行了,你要是有这样的想法就大错特错了。因为我们是干数据库的,对于主机为何这么设置,是一个安全边际的问题,不熟悉的东西我们千万别去碰它,我们做运维工作的,不要去争什么功劳,也不要想着怎么出彩,我们要做的就是把安全边际以内的事情做好,安全边际以外的事情我们迅速通知专业人士,让专业人士去处理就是最好的做法。这也是最稳妥的处理方式。大家对我刚刚说的有什么疑问吗?”
小王点点头说道:“嗯,领导说的对,我也是这么做的,我经常遇到搞不定的问题我就抛出来,大伙一起研究探索,这其实也算是一种升级。我说的是那种不着急的问题。比较着急的我就直接找二线了。”
听完这话老姜补充了一下说道:“我们在遇到故障的时候我们需要先判断‘影响力’,‘影响力’这也是一个很重要的因素,一般情况下我把‘影响力’分成以下几个方面:

  • 用户数量->有多少用户受到影响?
  • 系统重要性->是不是核心系统?
  • 用户需求->有没有人关心?
  • 严重性->这是不是一个恶性的事件?

通过以上四点,我可以知道这个事件‘影响力’有多大?如果这个是核心系统,现在几千用户受到影响,是不是应该尽快升级到我这里比较好呢?如果这个是个非核心系统,只有1-2个用户受到影响,而且他们还漠不关心,你就可以尝试自己练练手,但是也要尽快的恢复业务。不要烂在自己的手里,到时候被人追究责任。”
大家听完这一席话,都特别的佩服老姜,领导就是领导,总是能把问题想的很全面啊。殊不知,若干年前,老姜不知道在这上面栽了多少个跟头,这心里的酸甜苦辣只有老姜自己心里面最清楚。

分享到: 更多

Post a Comment

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