覆盤一次生產問題

夜空

有整整 10 天木有更文了,這段時間確實比較忙。微信

有加我微信的朋友知道我上週末出去春遊了,部門組織去了趟外伶仃島,環境挺不錯的,這段時間去的人也比較少,值得去玩。框架

今天講講上週末一次生產問題的覆盤。測試

1 事情通過

週日中午從外伶仃島回來就直奔公司,由於生產出了些問題。問題是這樣的:HBase 的一些節點掛了,致使一些數據丟失。丟失數據的客戶來授信或者借款,都會卡件。在肯定數據短期無法恢復時,就決定從系統的層面去解決這個問題。這時我諮詢了 2 位老員工,這些數據雖然是規則的入參數據,可是規則可能沒用這些數據去作決策,可否先跟規則的同事確認這些數據是否有使用,若是沒有,就能夠先暫停這些數據的獲取,減小影響面,再來細緻的分析數據。獲得的回覆都是這些數據很早前就上線了,確定有在用。這時只能分析系統數據,恰巧丟失的數據是原始數據,不是加工數據,原始數據不作規則入參,因此就簡單的修改了獲取數據源的代碼。spa

在測試同事進行簡單迴歸測試時,發現了一個奇怪的現象,舊數據被覆蓋,檢查了各類 SQL 配置,沒有發現問題,由於之前也有不少模型和規則入參都是這樣配置的,接着就陷入歷史問題的 debug 中,仍是沒有發現問題所在,到了晚上快 11 點,有同事聯繫了規則同事,才發現卡件的數據他們並無在借款的規則中使用,也就是能夠經過關閉獲取數據源來解決借款卡件問題,做罷,先解決數據卡件問題,後面再細緻分析歷史問題,搞完回到家 1 點半。debug

2 覆盤

這周也是持續在跟進這個生產歷史問題,最終發現是系統框架的 Bug,在數據處理的時候,私有的數據被公共的數據覆蓋致使的。這段時間也一直在思考此次生產問題,從馬後炮來講,其實能夠很快就把卡件問題解決,可是其中卻經歷了整整 10 個小時的折騰,確定是有緣由的,經過這篇文章覆盤一下。code

2.1 慣性思惟

從維基百科上看這個定義:慣性思惟(Inertial thinking)指人習慣性地因循之前的思路思考問題,彷彿物體運動的慣性。慣性思惟常會形成思考事情時有些盲點,且缺乏創新或改變的可能性。排序

上面的過程發現了 2 處慣性思惟。開發

  1. 一處是同事們由於經歷了整個系統的開發過程,因此直接否認了確認規則是否有在使用丟失的數據的方案;而我由於沒有經歷前程的開發,算是一個旁觀者去看待這個問題,因此纔有這個想法先肯定數據有沒在使用。這裏的慣性思惟是:由於數據很早前就上線了,當時就在使用,因此如今數據還在使用
  2. 另一處則是我對待生產出現的歷史問題,一直在經過檢查業務代碼和 SQL 配置去嘗試解決這個問題,由於之前也是這樣使用的,之前沒出現問題。這裏的慣性思惟是:之前這樣使用沒問題,這一次有問題應該是業務代碼或者 SQL 配置有問題

這裏都是由於之前作過某些事情是沒錯的,致使在遇到相同問題的時候會去把之前沒錯的作法當成是正確答案,而其實沒錯不等於正確,之前沒錯的作法只是參考答案,不是正確答案,這裏就涉及到思惟問題,若是當成參考答案,那麼思惟是發散的,這個參考答案以爲不對則能夠再找其餘參考答案或者去發現其餘解決方案;若是當成正確答案,那麼思惟是僵化的,會把這個正確答案一直往裏套,就會走不出來。rem

理解了上面這點,那有什麼能夠去擺脫慣性思惟呢?下面這兩點不肯定是否是對的,可是是我經過思考,決定接下來要嘗試去執行的。get

  1. 告訴本身,這是慣性思惟。《正念的奇蹟》書中講過洗碗、吃橘子的案例,都是去感覺洗碗、去感覺吃橘子的感受。有健身的朋友也會知道,健身肌肉痠痛的時候,去感覺那個感受。讓本身去清晰的正面對待慣性思惟,而不是去埋怨本身怎麼又陷入慣性思惟,正面對待它,而後告訴本身,這是慣性思惟,這個參考答案是錯的,找另外一個答案。
  2. 空杯狀態。若是沒有好的參考答案,放空本身,根據眼前看到的事情,按正常的解決思路去解決。

2.2 明確輕重緩急

當時最緊要的事情是解決生產卡件的問題。在解決的過程當中,卻發現了一個歷史遺留的 Bug,這時卡件的問題代碼已經驗證經過了,應該直接就上生產,解決當前的燃眉之急,再解決歷史遺留的 Bug。現實是一直去把心思放到歷史遺留的 Bug 中,致使延遲了好久才把 hotfix 上線。

明確輕重緩急很重要,不只在特殊緊急的狀況,在平時工做中也是同樣重要,天天要作的事情不少,要學會先作什麼,後作什麼。解決這個問題,能夠採用四象限工做法,什麼是四象限工做法?看下圖。

四象限工做法
<span style="font-size:0.8em;">(注:這裏的象限劃分和數學上的有些差異,數學上3、四象限和圖上是相反的,這裏是按照事情的重要緊急程度排序)</span>

每件工做用 2 個維度去衡量,分別是重要性緊急度。按照這 2 個維度進行分析後落位到各個象限,而後根據象限的順序去執行,好比上面遇到的卡件以及歷史 Bug 問題,卡件這個是放在一象限,歷史 Bug 是放在二象限,因此應該分開解決,解決好了卡件問題以後,再去解決歷史 Bug。當時有這個意識的話,在驗證卡件 hotfix 代碼沒問題後,就能夠直接上線了,後續再分析歷史 Bug。

3 總結

通過此次事情,讓本身靜下心來思考,思考哪些地方作錯了,思考犯錯的本質,思考如何去避免再犯一樣的錯,思考怎麼去用實際的行動改進。犯錯不可怕,可怕的是一錯再錯。嗯,這一刻,我又成長了。但願個人覆盤也能給你一些啓示。

推薦閱讀:

行爲型模式:觀察者模式

行爲型模式:迭代器模式

行爲型模式:策略模式

歡迎關注公衆號:LieBrother,一塊兒交流進步。

LieBrother

相關文章
相關標籤/搜索