一、前言

你的代碼出過事故嗎？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

二、研發(fā)事故

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 事故級(jí)別：P0
• 事故判責(zé)：網(wǎng)友反饋，私自開發(fā)后門，執(zhí)行sql錯(cuò)誤，影響較大。開除！
• 事故名稱：通過后門程序修改線上數(shù)據(jù)
• 事故現(xiàn)象：這次修改影響范圍比想象的要小，只有部分?jǐn)?shù)據(jù)因?yàn)榫彺媸Я耍抛x取數(shù)據(jù)庫的活動(dòng)信息。所有有少部分客訴說活動(dòng)與名稱不符合。
• 事故描述：研發(fā)人員應(yīng)運(yùn)營(yíng)要求修改線上配置錯(cuò)誤的活動(dòng)名稱，但任何郵件記錄以及負(fù)責(zé)人審批。所以只是研發(fā)私自通過后門程序提交sql語句修改，但忘記寫where條件，造成幾千條活動(dòng)名稱被同時(shí)修改。
• 事故處理：事后聯(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ā)流程，緊急事情需要請(qǐng)求批準(zhǔn)處理。

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

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

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

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

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

三、總結(jié)

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

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

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