0

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

 收集于1周前 阅读数 0

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

RruERzR.jpg!web

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

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

(1)故障发生的原因。

(2)故障解决办法。

(3)如何防止故障再次发生:

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

(4)如果再次发生此类问题,应如何解决。

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

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

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

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

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

那为什么没有进行复盘呢?

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

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

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

(3)作为项目负责人,我没有向上级求助,申请资源协助。

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

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

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

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

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

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

总结:

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

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

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

查看原文

猜你喜欢

关于头条


聚合每日国内外有价值,有趣的链接。