一、前言

你的代碼出過事故嗎？

老人言：常在河邊走哪有不濕鞋。只要你在做著編程開發的工作就一定會遇到事故，或大或小而已。

當然可能有一部分研發同學，在相對傳統的行業或者做著用戶體量較小的業務等，很難遇到讓人出名的事故，多數都是一些線上的小bug，修復了也就沒人問了。

但如果你在較大型的互聯網公司，那么你負責的開發的系統功能，可能面對的就是成百萬、上千萬級別用戶體量。哪怕你有一點小bug也會被迅速放大，造成大批量的客訴以及更嚴重的資金損失風險。就像：

拼多多“薅羊毛”事件，朋友圈瘋狂轉發。

淘寶昨現重大線上bug，S1級事故，疑似程序員故意埋雷。您使用的程序是內測版本，將于當地時間 2020-03-28 到期，到期后將無法使用，請盡快下載最新版本。

GitHub忘記續訂SSL證書導致網站排版混亂，部分網站不能正常打開。

類似這樣事故的出現，可能是因為技術流程、方案實現、技術服務以及運營配置等等原因產生的。綜合可以概括為以下幾點：

圖 19-1 事故類型總結

功能流程設計類：通常指的是研發在設計產品邏輯功能實現流程中，錯誤的執行調用關系而造成的風險事故。

技術方案實現類：在研發設計好流程后，每一個功能點的實現方案會因人而異，也會由于理解偏差或不足，而導致實現過程中缺少了對代碼在運行過程中健壯性的評估。

技術服務使用類：這一類說的是在研發使用數據庫服務、緩存服務、大數據服務、配置中心服務以及發布上線服務等時，對各項服務的配置以及使用上缺少一定的了解，而造成的事故。

后門違規操作類：這一類因公司對研發規范的執行強度不同，而是否會有此類風險。例如：有些研發同學會開發一些后門程序，比如可以在某個ERP頁面執行數據庫語句，臨時修改數據。這樣造成的風險，通常為后門違規操作，會有開除風險。

運營操作失誤類：在研發以為還有一部分公司內的伙伴會使用研發同學開發的運營系統，配置活動、變更用戶、執行流程等操作，但一般情況下這類系統缺少一定的強規則驗證，導致運營小白在操作過程中造成風險，從而引發事故。一般線上配置出錯誤卷，或者推錯短信給用戶等等，都是這樣發生的。

可以說，大多數比較蠢的事故主要是個人責任心問題。但那些有技術含量的事故，犯一次還是挺值得的。雖然公司很討厭你造成事故，因為會給公司帶來損失嘛！但這樣具有具有技術含量的事故，卻對你個人成長非常好的案例。不過禁酒雖好，可不能貪杯！

接下來，小傅哥就帶著你領略下各類事故的風采，看看在什么場景、遇到什么問題、怎么解決的以及能學到什么！

二、研發事故

1. 功能流程設計類

圖 19-2 功能流程設計類事故

• 事故級別：P1
• 事故判責：相應的研發、測試總結復盤，罰款50元給參加的會議的伙伴買棒棒糖以示警告。
• 事故名稱：抽獎積分支付流程不合理
• 事故現象：用戶積分多支付，造成批量客訴，當天緊急排查修復，并給用戶補充積分。
• 事故描述：這個產品功能的背景可能很大一部分研發都參與開發過，簡單說就是滿足用戶使用積分抽獎的一個需求。上圖左側就是研發最開始設計的流程，通過RPC接口扣減用戶積分，扣減成功后進行抽獎。但由于當天RPC服務不穩定，造成RPC實際調用成功，但返回超時失敗。而調用RPC接口的uuid是每次自動生成的，不具備調用冪等性。所以造成了用戶積分多支付現象。
• 事故處理：事故后修改抽獎流程，先生成待抽獎的抽獎單，由抽獎單ID調用RPC接口，保證接口冪等性。在RPC接口失敗時由定時任務補償的方式執行抽獎。流程整改后發現，補償任務每周發生1~3次，那么也就是證明了RPC接口確實有可用率問題，同時也說明很久之前就有流程問題，但由于用戶客訴較少，所以沒有反饋。
• 學習總結： 調用的接口、發送的MQ，并不一定會每次都成功。那么一定要做好冪等性以及失敗后的補償，來把整個技術實現流程做的更加完善。就像小傅哥說的，擦屁屁的紙80%的面積其實都是保護手的！

網友事故分享：

2. 技術方案實現類

圖 19-3 技術方案實現類事故

• 事故級別：P0
• 事故判責：營銷活動推廣用戶較多，影響范圍較大，研發整改代碼并做復盤。
• 事故名稱：秒殺方案獨占競態實現問題
• 事故現象：用戶看到可以購買，但只要一點下單就活動太火爆，換個小手試試。造成了大量客訴，緊急下線活動排查。
• 事故描述：這個一個商品活動秒殺的實現方案，最開始的設計是基于一個活動號ID進行鎖定，秒殺時鎖定這個ID，用戶購買完后就進行釋放。但在大量用戶搶購時，出現了秒殺分布式鎖后的業務邏輯處理中發生異常，釋放鎖失敗。導致所有的用戶都不能再拿到鎖，也就造成了有商品但不能下單的問題。
• 事故處理：優化獨占競態為分段靜態，將活動ID+庫存編號作為動態鎖標識。當前秒殺的用戶如果發生鎖失敗那么后面的用戶可以繼續秒殺不受影響。而失敗的鎖會有worker進行補償恢復，那么最終會避免超賣以及不能售賣。
• 學習總結： 核心的技術實現需要經過大量的數據驗證以及壓測，否則各個場景下很難評估是否會有風險。當然這也不是唯一的實現方案，可以根據不同的場景有不同的實現處理。

網友事故分享：

3. 技術服務使用類

圖 19-4 技術服務使用類事故

• 事故級別：P2
• 事故判責：網友說被叼了一會，問題不大！
• 事故名稱：擴容時忽略了連接池梳理，導致連接池被打滿
• 事故現象：線上突然收到報警短信，打開電腦一看，簡單的查詢接口超時到3分鐘才返回。
• 事故描述：幸好監控報警加的全，及時收到了報警短信，聯系DBA檢查發現連接池被打滿了。為了快速解決線上報警，優先臨時擴容了連接池以及把服務重啟。觀察后連接池打滿消失了。
• 事故處理：檢查應用數據庫連接池配置，以及額外不經常上線的服務一并排查。經查詢發現所有的應用加起來連接池的最高配置超過數據庫分配的連接池數量。尤其是定時任務較長時間掃庫處理，是直接導致連接池打滿的重要原因。
• 學習總結： 研發不僅是代碼開發搬磚人員，還要了解熟悉與之配套的服務。合理的使用、全面的考量才能避免一些看似不應該出現的事故問題。

網友事故分享：

4. 后門違規操作類

圖 19-5 后門違規操作類事故

• 事故級別：P0
• 事故判責：網友反饋，私自開發后門，執行sql錯誤，影響較大。開除！
• 事故名稱：通過后門程序修改線上數據
• 事故現象：這次修改影響范圍比想象的要小，只有部分數據因為緩存失效了，才讀取數據庫的活動信息。所有有少部分客訴說活動與名稱不符合。
• 事故描述：研發人員應運營要求修改線上配置錯誤的活動名稱，但任何郵件記錄以及負責人審批。所以只是研發私自通過后門程序提交sql語句修改，但忘記寫where條件，造成幾千條活動名稱被同時修改。
• 事故處理：事后聯系DBA緊急通過binlog日志進行數據修復。
• 學習總結： 研發人員應避免操作線上數據，尤其是變更數據類。也不要開發各類改數據、上線、傳配置文件等后門。而應該嚴格遵守研發流程，緊急事情需要請求批準處理。

網友事故分享：

5. 運營操作失誤類

圖 19-6 運營操作失誤類事故

• 事故級別：P2
• 事故判責：網友說，金額太大沒發出去！被噴了一會！
• 事故名稱：運營把券配置成紅包
• 事故現象：線上用戶客訴，看到幾百億大的紅包，領不到！
• 事故描述：運營人員配置優惠券，但是類型選成了紅包，導致頁面展示出超大額的紅包金額待領取，都超出屏幕長度了！
• 事故處理：緊急下線活動，重新配置上線。同時產品設計需求，由研發人員實現對于此類配置提供明確、醒目的配置和完整的審核流程。如果配置紅包、優惠券，會有校驗此券的是否存在以及紅包最大金額限制。
• 學習總結： 看上去是運營配置錯誤，但從某個角度看其實也可以說是研發在做功能實現時，太過于單一完成產品功能，而沒有加深考慮以及產品的易用性。有時候多問一句就少一個風險！

網友事故分享：

三、總結

講道理，開發沒事故，不是沒用戶體量，就是沒用戶規模。否則只要是人就一定會出現事故，要不是小bug被你銷聲匿跡隱藏了，或者是大事故被噴了或者送飛機了。

而盡可能減少事故的方式是需要盡可能按照一定的研發流程來實現功能邏輯。就像：設計評審，把控的是實現流程、代碼評審，把控的是實現方案，在配合上完善的監控和報警。只有這樣才能更少的減少不必要的事故。

關于研發在職場中的事故本文就講到這了，感謝粉絲分享出自己的遇到的事故，讓大家可以互相學習，減少離職扣工資的風險。多關注小傅哥，一個寫有價值原創好文章的男人！