一次事故反思

大概在一個月前，匹配系統搞出了一次事故。當時寫完了事故反思，奈何在提交的時候博客登陸態丟了，也沒有保存，就懶得再寫了。在這個深夜從新寫一下吧。

時隔這麼久，事故的細節可能已經忘了，但這個過程當中仍是能留下一些的。

事故說明

事故是匹配系統引入了一個新概念，這個新概念對匹配系統整個進行了一個大的改動，複雜度能夠說是指數級的增加。
定這個方案的時候，組長沒有和總監（也是匹配系統的設計者）去探討這個技術方案。最初接需求的時候是另外一個哥們兒作的，在眼看要作完的時候，那哥們兒直接離職走了，需求也就到了我手裏。最終的結果是因爲對匹配系統的掌握不夠，加上覆雜度確實比較高，最終考慮不周，致使匹配系統在那3天裏一直是不穩定的狀態。

後來仍是刪掉了這個東西，才讓系統比較穩定的跑着。

事故反思

0、需求合理性

新加的這個東西是boss想要這個，東西乍得聽起來確實不難，但從系統的角度，引入這個概念以後是指數級的複雜度增加，帶來極大的開發難度。

一、技術方案評審

若是是2天以上的項目，要和項目組技術同窗進行技術評審。
若是是比較複雜的開發任務，或比較核心的系統的需求，最好拉上總監進行技術評審。

二、人員安排

這個需求從評審，到方案制定，到開發，開始都不在我手裏，眼看着都作了一大半，結果那哥們兒直接離職走了。
而後我才臨危受命接了這個需求，致使對需求的理解不那麼透徹。內哥們兒直接拍屁股走人，他寫代碼的時候是怎麼想的都問不到，只能本身去理解。

人員安排上儘可能要固定一個程序員。

這塊也有一個要注意的點，若是本身真的沒把握，要及時反饋上去

三、開發時間

上面老是壓時間，從對匹配系統幾乎不瞭解，到要求的提測時間，總共也就兩週時間。這個時間搞完仍是有必定難度的。
這塊也是，若是沒把握要把情況反映一下（不過在這事情以前組長好像不太能聽得進去）

四、精力問題

這個需求所影響到的四個系統，匹配是比較大的一個系統，另外三個系統的改動比較小，但仍是我一我的作的。把精力也分到了別的系統上，也是一個小問題點所在。

五、灰度問題

以前在C端的系統中也是我推進了灰度，開發了灰度系統，更多的是針對用戶去作灰度。
但匹配這邊因爲是核心系統，基本上都是一刀切的功能，因此沒有使用灰度。若是能有灰度會把風險降到最低。

但此次事故也說明了，大的功能改動或核心系統的改動，能作到灰度就儘可能作到灰度。

六、事故預案

在上比較大的功能的時候，最好定一套事故預案，分析都有可能出現哪些問題，而且針對每一種可能出現的問題都給一套事故預案。

七、bug修復與錯誤數據修復

組長爲了用戶能儘快提現，在沒有理清具體錯誤的狀況下，單純強制更新了當天的錯誤數據，用戶是能提現了，但也有隱患是後期形成了一些髒數據。

以上。