【故障】我只是插了一根网线，全网中断！？(2)

在发生故障前要尽可能的建立完善的故障处理流程,先干什么,后干什么,故障的分级、故障的职能性升级都要有确切的流程和文档.保证故障的处理人能够合理的将故障解决,不能解决的及时进行故障升级.

反思：发生故障后我们能做什么?

1. 恢复是故障管理的第一要务

ITIL的服务运营有一个故障管理的流程,故障管理的目标是尽可能快地恢复到正常的服务运营,将故障对业务运营的负面影响减小到最低.

那么故障管理的大忌,就是试图快速定位故障原因而忽略了故障处理流程.下面有个小段子,可以帮助你理解：

某电商系统,一次用户系统升级,导致串号,也就是用户A登录后,看到的是用户B的帐号信息.

领导问：怎么办?
开发人员：老板,给我10分钟,马上修复这个bug.

然后开发人员实际使用了8分钟修代码并上线.结果故障依旧!

开发主管：你这水平不行啊,我来,我只需要5分钟.

然后开发主管用了4分钟修代码并上线.结果故障依旧!!

开发经理：你们都闪开,我只需要1分钟.然后开发经理真的1分钟修改代码并上线.结果故障依旧!!!(好吧,到这里连小编都已经看不下去了)

老板：谁能快速的恢复这个故障,我们已经故障整整13分钟了!
这个时候运维甲奋力的挤进人群：我们有秒级回滚脚本,所有节点回滚上一个版本并启动不到1分钟.
结果,1分钟后,故障恢复了.

篇幅问题,这个故障就到这里.我想无论你是老板、经理、开发、测试、运维都应该已经明白了,不做过多的解释了.

2. 故障复盘

每一次发生故障后,运维负责人都需要牵头进行故障的复盘.开发、测试、运维要一起审查这次故障,搞明白是哪里出了问题,我们应该怎么避免这类故障的再次发生.

俗话说：故障是我们最好的老师.不过这个老师大家都不会喜欢.当然还需要我们详细做好故障的记录.

3. 问题管理

故障复盘的目的和问题管理是相同的.ITIL的服务运营中,问题管理流程的目标是预防问题的产生及由此引发的故障,消除重复出现的故障,并对不能预防的故障尽量降低其对业务的影响.

所以我们可以在故障复盘的时候,要把这个故障转化为问题管理,全面分析故障的原因,务必彻底解决,而且每项工作一定要落实到具体的负责人.

好的,今天的软文(赵班长又调皮了—小编注)分享就到这里.故障这个话题比较大,无法面面俱到,大家可以加入“高效运维社区”一起讨论交流.

GOPS2016 全球运维大会?上海站 已开始报名

运维发展至今,早已不是刀耕火种的时代,不应该仍然是“背黑锅侠”,“背服务器侠”.运维可以更高逼格、更高价值,运维明天可以更美好!

“重新定义运维”让这些成为可能

汇聚整个行业的力量,集合海内外专家的智慧,我们在路上!

想在GOPS2016上海大会见到赵班长?您可以在文末留言哦

GOPS2016上海大会现已开始报名,可扫描下方二维码,或点击文末“阅读原文”链接,以了解详情：

文/赵舜东

文章来自高效运维微信公众号

（编辑：ASP站长网）