前段時間司训，我負責的小組在攻堅項目時，組內(nèi)成員由于考慮不周全脏里，導致代碼上線后出現(xiàn)低級錯誤，對線上所有的用戶都造成了數(shù)據(jù)混亂影響虹曙。影響范圍極廣（全用戶）迫横，還好后來通過各種方式在 1 小時內(nèi)將數(shù)據(jù)還原、錯誤修正酝碳。
理論上大家第一反應會是去追究第一責任人矾踱，做個組內(nèi)處分，加強代碼審核即可完事疏哗。但是我想起劉潤老師介紹過：企業(yè)發(fā)生的所有的問題都是管理問題呛讲。因此我針對此事故做了深入的思考與分析。
是人有問題？還是流程有問題贝搁？
首先吗氏，不可否認事故的第一制造者是員工。
那么是員工的工作態(tài)度不對雷逆，還是專業(yè)能力不行呢弦讽？
負責實施此項目的工程師是一名有多年經(jīng)驗的技術人員，理論上專業(yè)能力和態(tài)度應該不差膀哲。雖然說造成此次事故是有失職之實往产，但因此定義此工程師能力不達標，要換更好的工程師某宪，或者再安排其他人進組仿村，那成本未免也太高了點。
那是我們的流程有問題嗎缩抡？
貌似是奠宜。因為只要是人，只要存在人工操作瞻想，就不可避免出現(xiàn)人為錯誤压真。因為所有人不可能保證自己每時每刻的精力都是充分的。
這次事故發(fā)生的原因就是在修改代碼時蘑险，新增的功能漏考慮之前的邏輯滴肿，導致用戶操作污染了數(shù)據(jù)。
而在我們的開發(fā)流程里佃迄，為了追求快速開發(fā)泼差，一直缺少「自動化測試」這一環(huán)節(jié)。
也就是說：
員工的失職雖然是直接原因呵俏，但是項目的研發(fā)流程和制度上一直存在漏洞堆缘，項目在執(zhí)行的過程中一直存在「雷區(qū)」，只是看什么時候踩到罷了普碎。
怎么解決吼肥？
既然能定位到原因，問題就好解決了麻车。當前我做的第一決策是：
- 所有成員必須在 2 天內(nèi)補完自己負責的核心業(yè)務邏輯測試缀皱；
- 為了減少人員成本，我們將代碼從 coding 遷移到 git 上动猬，這樣做是為了能使用 travis-ci 進行自動化測試啤斗；
- 加強監(jiān)控機制（《一個簡單的天眼計劃》），保證所有用戶請求都能第一時間捕獲赁咙，方便定位問題钮莲；
- 加強項目的 code review免钻，避免出現(xiàn)業(yè)務邏輯錯誤；
- 培訓項目組以及公司內(nèi)部其他技術人員寫測試的方案臂痕，將此方案推廣到其他項目組中伯襟，避免類似事情發(fā)生；
現(xiàn)在的狀況
在我們集成了自動化測試后姆怪，不僅系統(tǒng)更穩(wěn)定了，而且還查出了幾次開發(fā)中的隱患澡绩。當前整個項目組運轉(zhuǎn)情況很好稽揭，用兄弟們的話說是：現(xiàn)在晚上都能睡得著覺了。
眾生畏果肥卡，菩薩畏因溪掀。身為一個合格的負責人，遇到問題要更加深入的追本溯源步鉴，從源頭揪胃、從制度上去避免問題的發(fā)生。
