建站
咨詢
售后
建站咨詢
新聞中心
一、前言
你的代碼出過事故嗎？
專注于為中小企業(yè)提供做網站、成都網站制作服務,電腦端+手機端+微信端的三站合一,更高效的管理,為中小企業(yè)故城免費做網站提供優(yōu)質的服務。我們立足成都，凝聚了一批互聯(lián)網行業(yè)人才，有力地推動了千余家企業(yè)的穩(wěn)健成長，幫助中小企業(yè)通過網站建設實現(xiàn)規(guī)模擴充和轉變。
老人言：常在河邊走哪有不濕鞋。只要你在做著編程開發(fā)的工作就一定會遇到事故，或大或小而已。
當然可能有一部分研發(fā)同學，在相對傳統(tǒng)的行業(yè)或者做著用戶體量較小的業(yè)務等，很難遇到讓人出名的事故，多數(shù)都是一些線上的小bug，修復了也就沒人問了。
但如果你在較大型的互聯(lián)網公司，那么你負責的開發(fā)的系統(tǒng)功能，可能面對的就是成百萬、上千萬級別用戶體量。哪怕你有一點小bug也會被迅速放大，造成大批量的客訴以及更嚴重的資金損失風險。就像：
拼多多“薅羊毛”事件，朋友圈瘋狂轉發(fā)。
淘寶昨現(xiàn)重大線上bug，S1級事故，疑似程序員故意埋雷。您使用的程序是內測版本，將于當?shù)貢r間 2020-03-28 到期，到期后將無法使用，請盡快下載最新版本。
GitHub忘記續(xù)訂SSL證書導致網站排版混亂，部分網站不能正常打開。
類似這樣事故的出現(xiàn)，可能是因為技術流程、方案實現(xiàn)、技術服務以及運營配置等等原因產生的。綜合可以概括為以下幾點：
圖 19-1 事故類型總結
功能流程設計類：通常指的是研發(fā)在設計產品邏輯功能實現(xiàn)流程中，錯誤的執(zhí)行調用關系而造成的風險事故。
技術方案實現(xiàn)類：在研發(fā)設計好流程后，每一個功能點的實現(xiàn)方案會因人而異，也會由于理解偏差或不足，而導致實現(xiàn)過程中缺少了對代碼在運行過程中健壯性的評估。
技術服務使用類：這一類說的是在研發(fā)使用數(shù)據(jù)庫服務、緩存服務、大數(shù)據(jù)服務、配置中心服務以及發(fā)布上線服務等時，對各項服務的配置以及使用上缺少一定的了解，而造成的事故。
后門違規(guī)操作類：這一類因公司對研發(fā)規(guī)范的執(zhí)行強度不同，而是否會有此類風險。例如：有些研發(fā)同學會開發(fā)一些后門程序，比如可以在某個ERP頁面執(zhí)行數(shù)據(jù)庫語句，臨時修改數(shù)據(jù)。這樣造成的風險，通常為后門違規(guī)操作，會有開除風險。
運營操作失誤類：在研發(fā)以為還有一部分公司內的伙伴會使用研發(fā)同學開發(fā)的運營系統(tǒng)，配置活動、變更用戶、執(zhí)行流程等操作，但一般情況下這類系統(tǒng)缺少一定的強規(guī)則驗證，導致運營小白在操作過程中造成風險，從而引發(fā)事故。一般線上配置出錯誤卷，或者推錯短信給用戶等等，都是這樣發(fā)生的。
可以說，大多數(shù)比較蠢的事故主要是個人責任心問題。但那些有技術含量的事故，犯一次還是挺值得的。雖然公司很討厭你造成事故，因為會給公司帶來損失嘛！但這樣具有具有技術含量的事故，卻對你個人成長非常好的案例。不過禁酒雖好，可不能貪杯！
接下來，小傅哥就帶著你領略下各類事故的風采，看看在什么場景、遇到什么問題、怎么解決的以及能學到什么！
二、研發(fā)事故
1. 功能流程設計類
圖 19-2 功能流程設計類事故
- 事故級別：P1
- 事故判責：相應的研發(fā)、測試總結復盤，罰款50元給參加的會議的伙伴買棒棒糖以示警告。
- 事故名稱：抽獎積分支付流程不合理
- 事故現(xiàn)象：用戶積分多支付，造成批量客訴，當天緊急排查修復，并給用戶補充積分。
- 事故描述：這個產品功能的背景可能很大一部分研發(fā)都參與開發(fā)過，簡單說就是滿足用戶使用積分抽獎的一個需求。上圖左側就是研發(fā)最開始設計的流程，通過RPC接口扣減用戶積分，扣減成功后進行抽獎。但由于當天RPC服務不穩(wěn)定，造成RPC實際調用成功，但返回超時失敗。而調用RPC接口的uuid是每次自動生成的，不具備調用冪等性。所以造成了用戶積分多支付現(xiàn)象。
- 事故處理：事故后修改抽獎流程，先生成待抽獎的抽獎單，由抽獎單ID調用RPC接口，保證接口冪等性。在RPC接口失敗時由定時任務補償?shù)姆绞綀?zhí)行抽獎。流程整改后發(fā)現(xiàn)，補償任務每周發(fā)生1~3次，那么也就是證明了RPC接口確實有可用率問題，同時也說明很久之前就有流程問題，但由于用戶客訴較少，所以沒有反饋。
- 學習總結： 調用的接口、發(fā)送的MQ，并不一定會每次都成功。那么一定要做好冪等性以及失敗后的補償，來把整個技術實現(xiàn)流程做的更加完善。就像小傅哥說的，擦屁屁的紙80%的面積其實都是保護手的！
網友事故分享：
2. 技術方案實現(xiàn)類
圖 19-3 技術方案實現(xiàn)類事故
- 事故級別：P0
- 事故判責：營銷活動推廣用戶較多，影響范圍較大，研發(fā)整改代碼并做復盤。
- 事故名稱：秒殺方案獨占競態(tài)實現(xiàn)問題
- 事故現(xiàn)象：用戶看到可以購買，但只要一點下單就活動太火爆，換個小手試試。造成了大量客訴，緊急下線活動排查。
- 事故描述：這個一個商品活動秒殺的實現(xiàn)方案，最開始的設計是基于一個活動號ID進行鎖定，秒殺時鎖定這個ID，用戶購買完后就進行釋放。但在大量用戶搶購時，出現(xiàn)了秒殺分布式鎖后的業(yè)務邏輯處理中發(fā)生異常，釋放鎖失敗。導致所有的用戶都不能再拿到鎖，也就造成了有商品但不能下單的問題。
- 事故處理：優(yōu)化獨占競態(tài)為分段靜態(tài)，將活動ID+庫存編號作為動態(tài)鎖標識。當前秒殺的用戶如果發(fā)生鎖失敗那么后面的用戶可以繼續(xù)秒殺不受影響。而失敗的鎖會有worker進行補償恢復，那么最終會避免超賣以及不能售賣。
- 學習總結： 核心的技術實現(xiàn)需要經過大量的數(shù)據(jù)驗證以及壓測，否則各個場景下很難評估是否會有風險。當然這也不是唯一的實現(xiàn)方案，可以根據(jù)不同的場景有不同的實現(xiàn)處理。
網友事故分享：
3. 技術服務使用類
圖 19-4 技術服務使用類事故
- 事故級別：P2
- 事故判責：網友說被叼了一會，問題不大！
- 事故名稱：擴容時忽略了連接池梳理，導致連接池被打滿
- 事故現(xiàn)象：線上突然收到報警短信，打開電腦一看，簡單的查詢接口超時到3分鐘才返回。
- 事故描述：幸好監(jiān)控報警加的全，及時收到了報警短信，聯(lián)系DBA檢查發(fā)現(xiàn)連接池被打滿了。為了快速解決線上報警，優(yōu)先臨時擴容了連接池以及把服務重啟。觀察后連接池打滿消失了。
- 事故處理：檢查應用數(shù)據(jù)庫連接池配置，以及額外不經常上線的服務一并排查。經查詢發(fā)現(xiàn)所有的應用加起來連接池的最高配置超過數(shù)據(jù)庫分配的連接池數(shù)量。尤其是定時任務較長時間掃庫處理，是直接導致連接池打滿的重要原因。
- 學習總結： 研發(fā)不僅是代碼開發(fā)搬磚人員，還要了解熟悉與之配套的服務。合理的使用、全面的考量才能避免一些看似不應該出現(xiàn)的事故問題。
網友事故分享：
4. 后門違規(guī)操作類
圖 19-5 后門違規(guī)操作類事故
- 事故級別：P0
- 事故判責：網友反饋，私自開發(fā)后門，執(zhí)行sql錯誤，影響較大。開除！
- 事故名稱：通過后門程序修改線上數(shù)據(jù)
- 事故現(xiàn)象：這次修改影響范圍比想象的要小，只有部分數(shù)據(jù)因為緩存失效了，才讀取數(shù)據(jù)庫的活動信息。所有有少部分客訴說活動與名稱不符合。
- 事故描述：研發(fā)人員應運營要求修改線上配置錯誤的活動名稱，但任何郵件記錄以及負責人審批。所以只是研發(fā)私自通過后門程序提交sql語句修改，但忘記寫where條件，造成幾千條活動名稱被同時修改。
- 事故處理：事后聯(lián)系DBA緊急通過binlog日志進行數(shù)據(jù)修復。
- 學習總結： 研發(fā)人員應避免操作線上數(shù)據(jù)，尤其是變更數(shù)據(jù)類。也不要開發(fā)各類改數(shù)據(jù)、上線、傳配置文件等后門。而應該嚴格遵守研發(fā)流程，緊急事情需要請求批準處理。
網友事故分享：
5. 運營操作失誤類
圖 19-6 運營操作失誤類事故
- 事故級別：P2
- 事故判責：網友說，金額太大沒發(fā)出去！被噴了一會！
- 事故名稱：運營把券配置成紅包
- 事故現(xiàn)象：線上用戶客訴，看到幾百億大的紅包，領不到！
- 事故描述：運營人員配置優(yōu)惠券，但是類型選成了紅包，導致頁面展示出超大額的紅包金額待領取，都超出屏幕長度了！
- 事故處理：緊急下線活動，重新配置上線。同時產品設計需求，由研發(fā)人員實現(xiàn)對于此類配置提供明確、醒目的配置和完整的審核流程。如果配置紅包、優(yōu)惠券，會有校驗此券的是否存在以及紅包最大金額限制。
- 學習總結： 看上去是運營配置錯誤，但從某個角度看其實也可以說是研發(fā)在做功能實現(xiàn)時，太過于單一完成產品功能，而沒有加深考慮以及產品的易用性。有時候多問一句就少一個風險！
網友事故分享：
三、總結
講道理，開發(fā)沒事故，不是沒用戶體量，就是沒用戶規(guī)模。否則只要是人就一定會出現(xiàn)事故，要不是小bug被你銷聲匿跡隱藏了，或者是大事故被噴了或者送飛機了。
而盡可能減少事故的方式是需要盡可能按照一定的研發(fā)流程來實現(xiàn)功能邏輯。就像：設計評審，把控的是實現(xiàn)流程、代碼評審，把控的是實現(xiàn)方案，在配合上完善的監(jiān)控和報警。只有這樣才能更少的減少不必要的事故。
關于研發(fā)在職場中的事故本文就講到這了，感謝粉絲分享出自己的遇到的事故，讓大家可以互相學習，減少離職扣工資的風險。多關注小傅哥，一個寫有價值原創(chuàng)好文章的男人！
網站欄目：五類研發(fā)事故，80%的人都可能犯過，重則開除
標題來源：http://www.dlmjj.cn/article/djoedej.html
