内容简介:最近有个项目遇到了一次重大故障,引起甲方负责人的高度重视,并直接@我们的Leader,从故障发生到基本解决,我们花了两天时间。本文是关于这次故障的复盘和总结。最近有个项目遇到了一次重大故障,引起甲方负责人的高度重视,并直接@我们的Leader,从故障发生到基本解决,我们花了两天时间。
最近有个项目遇到了一次重大故障,引起甲方负责人的高度重视,并直接@我们的Leader,从故障发生到基本解决,我们花了两天时间。本文是关于这次故障的复盘和总结。
最近有个项目遇到了一次重大故障,引起甲方负责人的高度重视,并直接@我们的Leader,从故障发生到基本解决,我们花了两天时间。
之后项目组还花了近两个小时进行了复盘及总结:
(1)故障发生的原因。
(2)故障解决办法。
(3)如何防止故障再次发生:
- 加强预警机制,快速发现问题;
- 发生警告通知项目组内成员,而不只是其中一两个成员;
- 重视预警,收到预警需在2小时内解决。
(4)如果再次发生此类问题,应如何解决。
通过复盘会议,大家达成了一致共识并讨论应对方案,改进后续的工作。但还有一个问题,引起了我的思考:
这类故障并不是第一次发生,为什么之前没有得到很好的解决?
作为项目的主要负责人,之前发生此类故障,我是如何跟进处理的?
通知后台程序员,程序员一般进行重启或开启多个线程,等上一天,基本可以解决问题。
然后大家各忙各的,并没有正式进行复盘故障原因及防止故障发生的办法。
那为什么没有进行复盘呢?
(1)针对此类问题,如果需要根治,可能涉及到重构系统。大家并没有想到简单并快速的解决办法,因此治本的办法就一直搁置。
(2)考虑到这类问题并未引起严重的后果,能用简单的办法应付就应付,以减少维护成本。
事实证明:简单应付的办法,并不能减少维护成本,程序员的工作量看似减少了,但是维护的工作直接传递到我身上,系统不完美的地方引起的小问题,导致我跟甲方沟通工作并不少,占用了我一部分的时间
(3)作为项目负责人,我没有向上级求助,申请资源协助。
我突然意识到要及时向上级求助这一点很重要。
主要是因为我发现Leader很重视这次故障,全程跟踪并督促相关人员。(之前也发生过类似的故障,但并未深入跟进)
Leader做全程跟踪的原因之一是:在跟 程序员 交流问题时,发现这类故障我们居然束手无策,除了等别无他策。
这意味着:以后再次发生这类故障,我们依然没有办法解决……于是Leader做了全程重点跟进,跟督促技术负责人进行故障复盘。
之前也发生过类似故障,但是我并没有积极调动Leader和技术负责人这两部分资源,没有向他们传递问题的严重性,也没有引起他们的重视。
而我发现问题没有完美处理方案时,也没有把遇到这类问题的无奈与无助及时地反馈出来。而是采取短视的方式处理问题,并回避根本性问题。
总结:
- 对于故障问题,就应该进行复盘并建立预防机制。不能因为怕麻烦或者担心项目组成员情绪问题而放弃,否则引发的工作量将积压到自己身上。
- IT系统遇到严重故障且没有好的解决办法时,应第一时间求助Leader,必要时候需要通过Leader调用技术资源来解决问题。(特别是关于涉及改动程序的解决方案,一定要请技术专家一起会诊并讨论解决方案)
- 对常见问题进行流程设计,让提问人第一时间知道如何处理,甚至在没有维护人员的情况下也能自行处理。
本文由 @璇玑鱼 原创发布于人人都是产品经理,未经许可,禁止转载。
题图来自 Unsplash,基于CC0协议。
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网
猜你喜欢:本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
Pro Git (Second Edition)
Scott Chacon、Ben Straub / Apress / 2014-11-9 / USD 59.99
Scott Chacon is a cofounder and the CIO of GitHub and is also the maintainer of the Git homepage ( git-scm.com ) . Scott has presented at dozens of conferences around the world on Git, GitHub and the ......一起来看看 《Pro Git (Second Edition)》 这本书的介绍吧!