中國IT史上兩大嚴重事故對我們的警醒及預防措施
20190121
一，歷史回顧：20150528攜程運維大事故
2015年5月28日上午11點開始，攜程旅行網官方網站突然顯示404錯誤頁，App也無法使用，業務徹底中斷。
據稱是因為烏雲網公佈了攜程的一個漏洞“攜程旅遊網伺服器配置不當可導致官方郵件劫持”，攜程修復後當天準備上線釋出，但運維自動化系統有問題或者運維操作有問題，導致“釋出不上去了，剛發就（根目錄包括程式碼）被（物理）刪”，雖然資料庫還在，但應用都被刪了，業務遲遲無法恢復。
當日下午，攜程一度將流量切給了藝龍，但藝龍承受不了而雪崩宕機。
當晚19時許，離宕機過去8個小時後，攜程旅行網手機APP首先恢復，但是提交訂單仍然不穩定。
當晚22:45，攜程服務全面恢復，至此，停服整整12個小時。
二，攜程事故之後我們做了什麼，最後落實了什麼
當時我提出在Business Continuity Plan（BCP，業務持續計劃）之外儘快落實Disaster Recovery Plan（DRP，災難恢復計劃）。
DCP的目標是：
-
當IDC機房物理無法連線時，可快速異地重建生產系統。
它分為兩個層級：
-
程式碼和配置的災難可恢復性；
-
資料的災難可恢復性。
時至今日其實通過以下做法間接達到了DCP的目標：
-
程式碼和配置的災難可恢復性：
-
Docker映象：Web容器的配置都在Docker容器映象裡；
-
私有分散式映象倉庫，能夠做到在混合雲多機房各處都有自動同步的映象庫；
-
異地雙活機制等於說異地備份了Nginx/DNS等服務配置資訊；
-
CloudEngine（我們的研發協作平臺）裡儲存了各種工程在不同環境裡的應用屬性（也是配置資訊）；
-
資料的災難可恢復性：
-
異地備份：在iDB（我們的資料庫自動化運維平臺）的幫助下有資料庫自動備份以及備份的可恢復性自動檢查，並且做了異地備份；
-
異地雙活機制等於說異地同步了全量資料庫。
三，20190120拼多多無門檻優惠券大事故
2019年1月20日凌晨1點到10點，整整9個小時，羊毛黨徒們狂歡，從拼多多領取（而不是搶購）100元無門檻優惠券，據信拼多多損失高達數千萬元。
據傳，這個無門檻優惠券實際上對應於已過期的運營活動，但由於操作失誤，導致凌晨又重新上線。
p.s.:
劵的來歷：〃在拼多多官方的公告中指出此券為拼多多此前與江蘇衛視《非誠勿擾》開展合作時，因節目錄制需要特殊生成的優惠券型別，僅供現場嘉賓使用。除此之外，此種類型優惠券，從未在任何時候、以任何方式出現在平臺正常的線上促銷活動當中，甚至從未有任何線上入口。〃
四，拼多多事故對我們的啟示，以及我們要做什麼
運營規則，技術防護，風控預警，法律條款，電商行走江湖的四大護身法寶，缺一不可。
出了事兒不可怕，怕的是都沒有人知道出事兒了。要不是當天上午有併發異常，拼多多技術團隊也不會順藤摸瓜發現被領走那麼多券。
風控體系的建立，至關重要：
-
我們已經上了業務保障平臺和全鏈路追蹤，能夠實時監控第三方支付通道的活動，及時預警。但這還遠遠不夠。
-
應建立自動化的交易監控機制和風險監控模型，實時監控，及時預警；
-
應通過分析欺詐行為特徵建立反欺詐規則，對交易資料實時分析；
-
應制定異常交易監測和處理的流程和制度；
-
應依據已識別並確認的風險資料，建立黑名單資料庫；
-
……
每個電商都有規則漏洞，都有程式漏洞，無非是在多大範圍內被黑產和賺客們薅羊毛。
風控體系包括對傳統業務指標的監測和報警，至少能讓我們發現系統潛在的漏洞，及時修補，而不是最後一個知道系統出事兒的人。
我們要把別人的歷史當作自己的未來，這樣才能知道過去人家錯在哪裡，我們現在應該怎麼做。
歡迎關注 雲縱達摩院 ：
再贈送舊文一篇，也是攜程事故之後寫的。
小夥伴們手滑集
鄭昀 最後更新於2015/5/29
攜程旅行網的技術團隊今天註定是一個不眠之夜，我的猜測是自動化運維繫統過於強大以至於誤操作後覆水難收，加之歷史悠久規模龐大各種新老系統交錯，全面從新部署與平常迭代上線肯定不一樣，難度係數更高。
這也就是為什麼過去我反覆強調審計歷年來對我們做的企業內部安全審計非常重要，他們提出的意見，我們必須認真審視認真去落實。
為了警醒各位技術人員，下面列出本次攜程誤操作事件引發的各種手滑吐槽。
-
Rebuild：
-
當年酷殼在亞馬遜的時候，AWS的一個新人在工作第一天做熟悉開發環境自助培訓時，他本來想連測試環境，結果連不上，老員工給了他一個配置，他沒分清哪個是測試的，哪個是生產的，不小心聯上了生產線資料庫，把整個資料庫給 Rebuild 了，導致全美 Netflix 停止服務數小時；
-
Recreate：
-
某人用 hibernate 反向生成資料庫的一張表，並且連的是測試庫，結果一個配置沒加，把所有的表都格式化掉並重新建立了一次。
-
UPDATE沒有WHERE條件：
-
十一年前，某人手寫 SQL UPDATE 線上資料庫，由於引號把 WHERE 子句截斷，使用者原創內容幾乎全都被清空，不幸的是運維也出錯了，備份程式停了半個月，於是全公司同事手工到搜尋引擎快照中找回使用者的文章。
-
以前更新錯誤資料，結果手滑 where 條件還沒寫完呢，想動一下滑鼠，結果點到執行。一下子把所有的採購單資料的某個金額給改了，後來 dba 立刻恢復我操作以前的資料，就這三五分鐘的時間，客服那邊就接到了超多投訴電話。
-
配錯了：
-
有次做頻寬排程演算法，方向寫錯了，瞬間給一個 CDN 提供商搞了 100G 上下的頻寬，持續 16 小時。給公司造成了近 20 萬的頻寬費用。某人至今最貴的bug。
-
自己挖坑：
-
某人曾把整個伺服器全部抹掉了。事情是這樣的，有一個硬碟是映象備份，掛載的時候用 sda1 這樣的名字，沒有用 uuid。後來加了個硬碟，結果原來的資料盤成了 sda1，等於說從一個空盤做映象。
-
在高盛剛入職的時候一不小心把生產環境 compliance 資料庫鎖了，紐約 gsam 的 equity trading 停頓了15分鐘，完了經理跟我說，沒事兒，我闖過更大的禍。
-
膽子太大
-
好幾年前剛開始學著做 windows 伺服器管理，把幾個 windows 服務禁用，結果造成有服務互相依賴啟動不了，停機幾十個小時。
-
已然不知道該怎麼說了：
-
某年研發部所有電腦硬碟被偷，95%+的產品都丟了原始碼，為了維護一個已經上線的產品不得已，掛 HttpHandler 來處理。
-
某客戶為了重新部署系統，將資料匯出備份到行動硬碟，然後將 Raid 重新格式化，重新安裝系統，當進行 Oracle 資料庫重建，匯入資料時發現，行動硬碟上的資料無法正確讀取，檔案缺失一半。
-
曾經在 catch 裡寫過 system.exit。
-
drop 過生產環境資料庫表的路過。
-
剛入行時曾在程式碼里加過 system rm，然後測試環境裡的大部分程式都失蹤了，天真的以為是黑客乾的。
-
曾經把圖片的地址都寫成了“undefined”，上線後以為被 ddos 了。
-
rm -rf：
-
血淚史參考《被小夥伴們嚇哭了：可怕的命令》。
-
理工科其他手滑方向：
-
血淚史參考《理工宅之——那些年我們闖過的禍……系列》。
歡迎關注 老兵筆記 ：