记一次IT系统故障处理及复盘

　　最近有个项目遇到了一次重大故障，引起甲方负责人的高度重视，并直接我们的Leader，从故障发生到基本解决，我们花了两天时间。本文是关于这次故障的复盘和总结。
　　最近有个项目遇到了一次重大故障，引起甲方负责人的高度重视，并直接我们的Leader，从故障发生到基本解决，我们花了两天时间。
　　之后项目组还花了近两个小时进行了复盘及总结：
　　（1）故障发生的原因。
　　（2）故障解决办法。
　　（3）如何防止故障再次发生：
　　加强预警机制，快速发现问题；
　　发生警告通知项目组内成员，而不只是其中一两个成员；
　　重视预警，收到预警需在2小时内解决。
　　（4）如果再次发生此类问题，应如何解决。
　　通过复盘会议，大家达成了一致共识并讨论应对方案，改进后续的工作。但还有一个问题，引起了我的思考：
　　这类故障并不是第一次发生，为什么之前没有得到很好的解决？
　　作为项目的主要负责人，之前发生此类故障，我是如何跟进处理的？
　　通知后台程序员，程序员一般进行重启或开启多个线程，等上一天，基本可以解决问题。
　　然后大家各忙各的，并没有正式进行复盘故障原因及防止故障发生的办法。
　　那为什么没有进行复盘呢？
　　（1）针对此类问题，如果需要根治，可能涉及到重构系统。大家并没有想到简单并快速的解决办法，因此治本的办法就一直搁置。
　　（2）考虑到这类问题并未引起严重的后果，能用简单的办法应付就应付，以减少维护成本。
　　事实证明：简单应付的办法，并不能减少维护成本，程序员的工作量看似减少了，但是维护的工作直接传递到我身上，系统不完美的地方引起的小问题，导致我跟甲方沟通工作并不少，占用了我一部分的时间
　　（3）作为项目负责人，我没有向上级求助，申请资源协助。
　　我突然意识到要及时向上级求助这一点很重要。
　　主要是因为我发现Leader很重视这次故障，全程跟踪并督促相关人员。（之前也发生过类似的故障，但并未深入跟进）
　　Leader做全程跟踪的原因之一是：在跟程序员交流问题时，发现这类故障我们居然束手无策，除了等别无他策。
　　这意味着：以后再次发生这类故障，我们依然没有办法解决于是Leader做了全程重点跟进，跟督促技术负责人进行故障复盘。
　　之前也发生过类似故障，但是我并没有积极调动Leader和技术负责人这两部分资源，没有向他们传递问题的严重性，也没有引起他们的重视。
　　而我发现问题没有完美处理方案时，也没有把遇到这类问题的无奈与无助及时地反馈出来。而是采取短视的方式处理问题，并回避根本性问题。
　　总结：
　　对于故障问题，就应该进行复盘并建立预防机制。不能因为怕麻烦或者担心项目组成员情绪问题而放弃，否则引发的工作量将积压到自己身上。
　　IT系统遇到严重故障且没有好的解决办法时，应第一时间求助Leader，必要时候需要通过Leader调用技术资源来解决问题。（特别是关于涉及改动程序的解决方案，一定要请技术专家一起会诊并讨论解决方案）
　　对常见问题进行流程设计，让提问人第一时间知道如何处理，甚至在没有维护人员的情况下也能自行处理。