故障发生前我们能做什么?
# 反思:故障发生前我们能做什么?
# 1. 操作的规范性
第一个故障的背景,其实我们已经制定好了机房上架的操作流程,每个人都知道自己应该干什么,但是并没有按之前的操作计划执行。
这是发生这个故障的根本原因,因为如果按流程,网络工程师肯定会发现这个端口的设置并修改。
还有就是非实际操作人员不能盲目介入,这也是操作规范性的一个例子,虽然我只是想帮个忙而已,但是帮了倒忙。
# 2. 建立完善的监控体系
监控体系的重要性不言而喻,不准备多说。但正如第二个故障案例,我们有监控,但是遇到的问题是当报警很多的时候,并没有仔细的查看所有监控,而是把api无法连接当作重点,而忽略了其它报警。
所以说,仔细的看报警,以及给故障进行准确的分级非常重要。
# 3. 故障处理流程
在发生故障前要尽可能的建立完善的故障处理流程,先干什么,后干什么,故障的分级、故障的职能性升级都要有确切的流程和文档。保证故障的处理人能够合理的将故障解决,不能解决的及时进行故障升级。
# 反思:发生故障后我们能做什么?
# 1. 恢复是故障管理的第一要务
ITIL的服务运营有一个故障管理的流程,故障管理的目标是尽可能快地恢复到正常的服务运营,将故障对业务运营的负面影响减小到最低。
那么故障管理的大忌,就是试图快速定位故障原因而忽略了故障处理流程。下面有个小段子,可以帮助你理解:
某电商系统,一次用户系统升级,导致串号,也就是用户A登录后,看到的是用户B的帐号信息。
领导问:怎么办? 开发人员:老板,给我10分钟,马上修复这个bug。
然后开发人员实际使用了8分钟修代码并上线。结果故障依旧!
开发主管:你这水平不行啊,我来,我只需要5分钟。
然后开发主管用了4分钟修代码并上线。结果故障依旧!!
开发经理:你们都闪开,我只需要1分钟。然后开发经理真的1分钟修改代码并上线。结果故障依旧!!!(好吧,到这里连小编都已经看不下去了)
老板:谁能快速的恢复这个故障,我们已经故障整整13分钟了! 这个时候运维甲奋力的挤进人群:我们有秒级回滚脚本,所有节点回滚上一个版本并启动不到1分钟。 结果,1分钟后,故障恢复了。
篇幅问题,这个故障就到这里。我想无论你是老板、经理、开发、测试、运维都应该已经明白了,不做过多的解释了。
# 2. 故障复盘
每一次发生故障后,运维负责人都需要牵头进行故障的复盘。开发、测试、运维要一起审查这次故障,搞明白是哪里出了问题,我们应该怎么避免这类故障的再次发生。
俗话说:故障是我们最好的老师。不过这个老师大家都不会喜欢。当然还需要我们详细做好故障的记录。
# 3. 问题管理
故障复盘的目的和问题管理是相同的。ITIL的服务运营中,问题管理流程的目标是预防问题的产生及由此引发的故障,消除重复出现的故障,并对不能预防的故障尽量降低其对业务的影响。
所以我们可以在故障复盘的时候,要把这个故障转化为问题管理,全面分析故障的原因,务必彻底解决,而且每项工作一定要落实到具体的负责人。