中國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：

• 血淚史參考《被小伙伴們嚇哭了：可怕的命令》。

• 理工科其他手滑方向：

• 血淚史參考《理工宅之——那些年我們闖過的禍……系列》。

歡迎關注老兵筆記：