互聯網大廠，常見研發線上事故總結！

沉澱、分享、成長，讓本身和他人都能有所收穫！

1、前言

你的代碼出過事故嗎？

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

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

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

1. 拼多多「薅羊毛」事件，朋友圈瘋狂轉發。
2. 淘寶昨現重大線上bug，S1級事故，疑似程序員故意埋雷。您使用的程序是內測版本，將於當地時間 2020-03-28 到期，到期後將沒法使用，請儘快下載最新版本。
3. GitHub忘記續訂SSL證書致使網站排版混亂，部分網站不能正常打開。

相似這樣事故的出現，多是由於技術流程、方案實現、技術服務以及運營配置等等緣由產生的。綜合能夠歸納爲如下幾點：

• 功能流程設計類：一般指的是研發在設計產品邏輯功能實現流程中，錯誤的執行調用關係而形成的風險事故。
• 技術方案實現類：在研發設計好流程後，每個功能點的實現方案會因人而異，也會因爲理解誤差或不足，而致使實現過程當中缺乏了對代碼在運行過程當中健壯性的評估。
• 技術服務使用類：這一類說的是在研發使用數據庫服務、緩存服務、大數據服務、配置中心服務以及發佈上線服務等時，對各項服務的配置以及使用上缺乏必定的瞭解，而形成的事故。
• 後門違規操做類：這一類因公司對研發規範的執行強度不一樣，而是否會有此類風險。例如：有些研發同窗會開發一些後門程序，好比能夠在某個ERP頁面執行數據庫語句，臨時修改數據。這樣形成的風險，一般爲後門違規操做，會有開除風險。
• 運營操做失誤類：在研發覺得還有一部分公司內的夥伴會使用研發同窗開發的運營系統，配置活動、變動用戶、執行流程等操做，但通常狀況下這類系統缺乏必定的強規則驗證，致使運營小白在操做過程當中形成風險，從而引起事故。通常線上配置出錯誤卷，或者推錯短信給用戶等等，都是這樣發生的。

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

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

2、研發事故

1. 功能流程設計類

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

網友事故分享：

事故名稱	事故描述	事故結果
業務流程搞錯+代碼頻繁開闢線程池	業務流程搞錯致使的問題就是改動特別大，有點相似重構代碼了哎西，致使服務宕機好久，客戶瘋狂反饋	瘋狂加班改業務，加了不知道多少個晚上，因爲是菜狗子，寫的代碼太垃圾了，被大佬給瘋狂叼
線上修改用戶收貨地址失敗（同事須要的問題，也能夠借鑑下^v^）	場景：客服反應用戶須要把收貨地址從河北省改成浙江省（由於疫情），公司要求修改線上數據須要提交工單，所以l到審覈平臺提交申請等一系列流程。  問題：工單顯示修改結果成功，可是數據沒有改過來，多爲同事一塊兒查看sql發現sql編寫沒有問題。  解決過程：檢查sql是否正確，平臺是否修改爲功，又檢查了數據是否正確，還檢查了修改時間是沒有問題的。	首先，忽略了一個問題，這個訂單數據是淘寶下單同步到咱們訂單這邊的，數據修改的後，淘寶又同步也數據過來，把修改正確的數據又改成了河北的地址。而後就懷疑sql審覈平臺問題。到這裏故事已經講完了。結論：想告訴你們要相信代碼，多檢查不肯定的狀況，不要鑽到死衚衕，總是懷疑審覈平臺問題，多檢查自身問題。
業務相關事故	剛加入一個新的團隊，沒有深刻了解別人的代碼就進行復用，沒有理解業務的場景就限制條件，相似的狀況不少，只能說，再簡單的代碼都要保持敬畏，由於你不知道哪裏會出問題	用戶投訴、領導批評

2. 技術方案實現類

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

網友事故分享：

事故名稱	事故描述	事故結果
gc瘋狂回收	最近調整了本身業餘項目，跑一段時間就內存狂漲，還不能主動誘發	dump內存中
重複扣入帳	併發數過多，數據庫鏈接滿，等待超時，session斷開。事務未提交，撈出繼續幹	500塊，深刻併發編程，目前併發模型在我心中，歡迎battle
數據覆蓋	循環更新數據時，開啓事務，持續時間過長，而後覆蓋掉了用戶在持續事務中提交的數據	沒影響，就是多加了幾天班
數據穿透	第三分使用腳本海里請求併發形成數據穿透	削峯天谷， 使用隊列處理請求
這序列號咋重複了？？	序列號應具備全局的惟一，一條數據表明一條收入，序列號生成規則+代碼bug致使序列號重複，影響了幾萬單收入覈對	一級事故，回溯+通報
業務流程數據覆蓋	啓流程是一個公共類，各類交易都在這個裏面作，公共類一開始沒有通過設計，有一個方法返回了這個模板類型字段，同時這個方法又是一個檢驗類，當時加了一個檢驗返回成錯誤碼了，致使全部的交易都啓不了流程。	挨批長記性。。。
simpledateformat的線程不安全致使多線程定時任務解析日期出錯	某定時任務運行時，須要作一些日期解析動做，就用了一個公共變量simpledateformat，來格式化，結果任務常常間歇性報錯，幾天報一次或者一兩週報一次，沒啥規律。看異常信息才發現解析日期的字符串很奇怪，常常出現不少奇奇怪怪的數字。	定時任務報錯，不過還好，定時任務只是爲了作緩存而已，不涉及到數據庫的更新，僅僅是查詢而已。
前端解析主鍵異常	因爲Long類型最大19位而JavaScript最大接收數字爲16位，固存在精度丟失問題	統一處理將id轉字符串再返回前端
list遍歷刪除	遍歷刪除清空list數組，爲了節省計數器那小小一點內存，日了	報錯被叼了唄，爲啥不用計數器？不香嗎？
商品超賣	售賣一個兄弟部門的電子券商品，同步庫存的代碼有問題，致使了超賣 對客戶形成了損失	罰款1000元

3. 技術服務使用類

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

網友事故分享：

事故名稱	事故描述	事故結果
使用fastjson	全身上下都是高危漏洞，一年不停升級版本打補丁	珍惜生命，遠離fastjson
微信名存儲bug	微信名的emj頭等存入mysql編碼是utf8的庫報錯	被懟了！改爲utf8mb4編碼
磁盤不足	數據庫集羣磁盤空間不足，提早兩週提交擴容申請，甲方運維沒提交上去，最後某臺機器空間不足，致使整個集羣完全不能工做，體驗一把某國產號稱能夠方便橫向擴容的某idb的優越性	罰款，責任歸系統建設方

4. 後門違規操做類

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

網友事故分享：

事故名稱	事故描述	事故結果
刪除整個項目目錄文件	測試區，測試刪除文件時目錄寫錯，致使整個weblogic子項目目錄被刪	請項目中負責集成部署的公司幫忙從新部署，測試區癱瘓了兩天
誤更新生產訂單數據3萬多條	下班前，未帶核心過濾條件，致使誤更新3萬多條訂單數據，偷偷利用binlog恢復了，耗時3個小時	完美恢復數據
線上庫整庫誤刪除	應業務方要求要在線上環境建立線上聯調庫，使用了導出數據庫DDL語句後，直接執行，致使執行了exists  drop語句，刪除了線上庫全部數據，數據量大表均在千萬級，APP、網站全線癱瘓。	使用前一天的備份副本數據恢復，下載binlog日誌按操做避開事發時間點分割後編譯，導入數據，而後再修復事故以後的數據，共計耗時48小時。

5. 運營操做失誤類

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

網友事故分享：

事故名稱	事故描述	事故結果
業務漏洞	業務亂配優惠券，能夠疊加，超級優惠，而後被薅羊毛	部門幫着查羊毛記錄，處理訂單，挽回損失。而後對外發公告宣稱是被部門的風控系統誤殺的。
貸款費率	運營配置T+1日結算貸款費率錯誤，致使用戶貸款金額發生錯誤。	上線新費率替換舊費率，已經產生的費率錯誤聯繫貸款用戶修復。
多活動互斥	三個部門的都作活動，但最後致使重複發獎。一個用戶邀請別人獎勵，變成了三份獎勵。	產品提供渠道和互斥功能，讓運營本身選擇是否能夠並行發放獎勵。

3、總結

• 講道理，開發沒事故，不是沒用戶體量，就是沒用戶規模。不然只要是人就必定會出現事故，要不是小bug被你銷聲匿跡隱藏了，或者是大事故被噴了或者送飛機了。
• 而儘量減小事故的方式是須要儘量按照必定的研發流程來實現功能邏輯。就像：設計評審，把控的是實現流程、代碼評審，把控的是實現方案，在配合上完善的監控和報警。只有這樣才能更少的減小沒必要要的事故。
• 關於研發在職場中的事故本文就講到這了，感謝粉絲分享出本身的遇到的事故，讓你們能夠互相學習，減小離職扣工資的風險。????多關注小傅哥，一個寫有價值原創好文章的男人！