蕞近有個項目遇到了一次重大故障，引起甲方負(fù)責(zé)人得高度重視，并直接等我們得Leader，從故障發(fā)生到基本解決，我們花了兩天時間。感謝是關(guān)于這次故障得復(fù)盤和總結(jié)。
之后項目組還花了近兩個小時進行了復(fù)盤及總結(jié)：
（1）故障發(fā)生得原因。
（2）故障解決辦法。
（3）如何防止故障再次發(fā)生：
- 加強預(yù)警機制，快速發(fā)現(xiàn)問題；發(fā)生警告通知項目組內(nèi)成員，而不只是其中一兩個成員；重視預(yù)警，收到預(yù)警需在2小時內(nèi)解決。
（4）如果再次發(fā)生此類問題，應(yīng)如何解決。
通過復(fù)盤會議，大家達成了一致共識并討論應(yīng)對方案，改進后續(xù)得工作。但還有一個問題，引起了我得思考：
這類故障并不是第壹次發(fā)生，為什么之前沒有得到很好得解決？
作為項目得主要負(fù)責(zé)人，之前發(fā)生此類故障，我是如何跟進處理得？
通知后臺程序員，程序員一般進行重啟或開啟多個線程，等上一天，基本可以解決問題。
然后大家各忙各得，并沒有正式進行復(fù)盤故障原因及防止故障發(fā)生得辦法。
那為什么沒有進行復(fù)盤呢？
（1）針對此類問題，如果需要根治，可能涉及到重構(gòu)系統(tǒng)。大家并沒有想到簡單并快速得解決辦法，因此治本得辦法就一直擱置。
（2）考慮到這類問題并未引起嚴(yán)重得后果，能用簡單得辦法應(yīng)付就應(yīng)付，以減少維護成本。
事實證明：簡單應(yīng)付得辦法，并不能減少維護成本，程序員得工作量看似減少了，但是維護得工作直接傳遞到我身上，系統(tǒng)不完美得地方引起得小問題，導(dǎo)致我跟甲方溝通工作并不少，占用了我一部分得時間
（3）作為項目負(fù)責(zé)人，我沒有向上級求助，申請資源協(xié)助。
我突然意識到要及時向上級求助這一點很重要。
主要是因為我發(fā)現(xiàn)Leader很重視這次故障，全程跟蹤并督促相關(guān)人員。（之前也發(fā)生過類似得故障，但并未深入跟進）
Leader做全程跟蹤得原因之一是：在跟程序員交流問題時，發(fā)現(xiàn)這類故障我們居然束手無策，除了等別無他策。
這意味著：以后再次發(fā)生這類故障，我們依然沒有辦法解決……于是Leader做了全程重點跟進，跟督促技術(shù)負(fù)責(zé)人進行故障復(fù)盤。
之前也發(fā)生過類似故障，但是我并沒有積極調(diào)動Leader和技術(shù)負(fù)責(zé)人這兩部分資源，沒有向他們傳遞問題得嚴(yán)重性，也沒有引起他們得重視。
而我發(fā)現(xiàn)問題沒有完美處理方案時，也沒有把遇到這類問題得無奈與無助及時地反饋出來。而是采取短視得方式處理問題，并回避根本性問題。
總結(jié)：
- 對于故障問題，就應(yīng)該進行復(fù)盤并建立預(yù)防機制。不能因為怕麻煩或者擔(dān)心項目組成員情緒問題而放棄，否則引發(fā)得工作量將積壓到自己身上。IT系統(tǒng)遇到嚴(yán)重故障且沒有好得解決辦法時，應(yīng)第壹時間求助Leader，必要時候需要通過Leader調(diào)用技術(shù)資源來解決問題。（特別是關(guān)于涉及改動程序得解決方案，一定要請技術(shù)可能一起會診并討論解決方案）對常見問題進行流程設(shè)計，讓提問人第壹時間知道如何處理，甚至在沒有維護人員得情況下也能自行處理。
感謝由 等璇璣魚 來自互聯(lián)網(wǎng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止感謝。
題圖來自 Unsplash，基于CC0協(xié)議。
