一、前言

你的代碼出過事故嗎？

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

當(dāng)然可能有一部分研發(fā)同學(xué)，在相對傳統(tǒng)的行業(yè)或者做著用戶體量較小的業(yè)務(wù)等，很難遇到讓人出名的事故，多數(shù)都是一些線上的小bug，修復(fù)了也就沒人問了。

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

拼多多“薅羊毛”事件，朋友圈瘋狂轉(zhuǎn)發(fā)。

淘寶昨現(xiàn)重大線上bug，S1級事故，疑似程序員故意埋雷。您使用的程序是內(nèi)測版本，將于當(dāng)?shù)貢r間 2020-03-28 到期，到期后將無法使用，請盡快下載最新版本。

GitHub忘記續(xù)訂SSL證書導(dǎo)致網(wǎng)站排版混亂，部分網(wǎng)站不能正常打開。

類似這樣事故的出現(xiàn)，可能是因為技術(shù)流程、方案實現(xiàn)、技術(shù)服務(wù)以及運(yùn)營配置等等原因產(chǎn)生的。綜合可以概括為以下幾點(diǎn)：

圖 19-1 事故類型總結(jié)

功能流程設(shè)計類：通常指的是研發(fā)在設(shè)計產(chǎn)品邏輯功能實現(xiàn)流程中，錯誤的執(zhí)行調(diào)用關(guān)系而造成的風(fēng)險事故。

技術(shù)方案實現(xiàn)類：在研發(fā)設(shè)計好流程后，每一個功能點(diǎn)的實現(xiàn)方案會因人而異，也會由于理解偏差或不足，而導(dǎo)致實現(xiàn)過程中缺少了對代碼在運(yùn)行過程中健壯性的評估。

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

后門違規(guī)操作類：這一類因公司對研發(fā)規(guī)范的執(zhí)行強(qiáng)度不同，而是否會有此類風(fēng)險。例如：有些研發(fā)同學(xué)會開發(fā)一些后門程序，比如可以在某個ERP頁面執(zhí)行數(shù)據(jù)庫語句，臨時修改數(shù)據(jù)。這樣造成的風(fēng)險，通常為后門違規(guī)操作，會有開除風(fēng)險。

運(yùn)營操作失誤類：在研發(fā)以為還有一部分公司內(nèi)的伙伴會使用研發(fā)同學(xué)開發(fā)的運(yùn)營系統(tǒng)，配置活動、變更用戶、執(zhí)行流程等操作，但一般情況下這類系統(tǒng)缺少一定的強(qiáng)規(guī)則驗證，導(dǎo)致運(yùn)營小白在操作過程中造成風(fēng)險，從而引發(fā)事故。一般線上配置出錯誤卷，或者推錯短信給用戶等等，都是這樣發(fā)生的。

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

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

二、研發(fā)事故

1. 功能流程設(shè)計類

圖 19-2 功能流程設(shè)計類事故

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

網(wǎng)友事故分享：

2. 技術(shù)方案實現(xiàn)類

圖 19-3 技術(shù)方案實現(xiàn)類事故

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

網(wǎng)友事故分享：

3. 技術(shù)服務(wù)使用類

圖 19-4 技術(shù)服務(wù)使用類事故

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

網(wǎng)友事故分享：

4. 后門違規(guī)操作類

圖 19-5 后門違規(guī)操作類事故

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

網(wǎng)友事故分享：

5. 運(yùn)營操作失誤類

圖 19-6 運(yùn)營操作失誤類事故

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

網(wǎng)友事故分享：

三、總結(jié)

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

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

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