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

最近有个项目遇到了一次重大故障，引起甲方负责人的高度重视，并直接@我们的Leader，从故障发生到基本解决，我们花了两天时间。本文是关于这次故障的复**和总结。

最近有个项目遇到了一次重大故障，引起甲方负责人的高度重视，并直接@我们的Leader，从故障发生到基本解决，我们花了两天时间。

之后项目组还花了近两个小时进行了复**及总结：

（1）故障发生的原因。

（2）故障解决办法。

（3）如何防止故障再次发生：

1. 加强预警机制，快速发现问题；
2. 发生警告通知项目组内成员，而不只是其中一两个成员；
3. 重视预警，收到预警需在2小时内解决。

（4）如果再次发生此类问题，应如何解决。

通过复****议，大家达成了一致共识并讨论应对方案，改进后续的工作。但还有一个问题，引起了我的思考：

这类故障并不是第一次发生，为什么之前没有得到很好的解决？

作为项目的主要负责人，之前发生此类故障，我是如何跟进处理的？

通知后台程序员，程序员一般进行重启或开启多个线程，等上一天，基本可以解决问题。

然后大家各忙各的，并没有正式进行复**故障原因及防止故障发生的办法。

那为什么没有进行复**呢？

（1）针对此类问题，如果需要根治，可能涉及到重构系统。大家并没有想到简单并快速的解决办法，因此治本的办法就一直搁置。

（2）考虑到这类问题并未引起严重的后果，能用简单的办法应付就应付，以减少维护成本。

事实证明：简单应付的办法，并不能减少维护成本，程序员的工作量看似减少了，但是维护的工作直接传递到我身上，系统不完美的地方引起的小问题，导致我跟甲方沟通工作并不少，占用了我一部分的时间

（3）作为项目负责人，我没有向上级求助，申请资源协助。

我突然意识到要及时向上级求助这一点很重要。

主要是因为我发现Leader很重视这次故障，全程跟踪并督促相关人员。（之前也发生过类似的故障，但并未深入跟进）

Leader做全程跟踪的原因之一是：在跟程序员交流问题时，发现这类故障我们居然束手无策，除了等别无他策。

这意味着：以后再次发生这类故障，我们依然没有办法解决……于是Leader做了全程重点跟进，跟督促技术负责人进行故障复**。

之前也发生过类似故障，但是我并没有积极调动Leader和技术负责人这两部分资源，没有向他们传递问题的严重性，也没有引起他们的重视。

而我发现问题没有完美处理方案时，也没有把遇到这类问题的无奈与无助及时地反馈出来。而是采取短视的方式处理问题，并回避根本性问题。

总结：

1. 对于故障问题，就应该进行复**并建立预防机制。不能因为怕麻烦或者担心项目组成员情绪问题而放弃，否则引发的工作量将积压到自己身上。
2. IT系统遇到严重故障且没有好的解决办法时，应第一时间求助Leader，必要时候需要通过Leader调用技术资源来解决问题。（特别是关于涉及改动程序的解决方案，一定要请技术专家一起**诊并讨论解决方案）
3. 对常见问题进行流程设计，让提问人第一时间知道如何处理，甚至在没有维护人员的情况下也能自行处理。

本文由 @璇玑鱼 原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自 Unsplash，基于CC0协议。

给作者打赏，鼓励TA抓紧创作！

**赏

5人打赏