故障发生前我们能做什么？

第一个故障的背景，其实我们已经制定好了机房上架的操作流程，每个人都知道自己应该干什么，但是并没有按之前的操作计划执行。

这是发生这个故障的根本原因，因为如果按流程，网络工程师肯定会发现这个端口的设置并修改。

还有就是非实际操作人员不能盲目介入，这也是操作规范性的一个例子，虽然我只是想帮个忙而已，但是帮了倒忙。

监控体系的重要性不言而喻，不准备多说。但正如第二个故障案例，我们有监控，但是遇到的问题是当报警很多的时候，并没有仔细的查看所有监控，而是把api无法连接当作重点，而忽略了其它报警。

所以说，仔细的看报警，以及给故障进行准确的分级非常重要。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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