一，歷史回顧：20150528攜程運維大事故

2015年5月28日上午11點開始，攜程旅行網官方網站突然顯示404錯誤頁，App也無法使用，業(yè)務徹底中斷。

據稱是因為烏云網公布了攜程的一個漏洞“攜程旅游網服務器配置不當可導致官方郵件劫持”，攜程修復后當天準備上線發(fā)布，但運維自動化系統有問題或者運維操作有問題，導致“發(fā)布不上去了，剛發(fā)就（根目錄包括代碼）被（物理）刪”，雖然數據庫還在，但應用都被刪了，業(yè)務遲遲無法恢復。

當日下午，攜程一度將流量切給了藝龍，但藝龍承受不了而雪崩宕機。

當晚19時許，離宕機過去8個小時后，攜程旅行網手機APP首先恢復，但是提交訂單仍然不穩(wěn)定。

當晚22:45，攜程服務全面恢復，至此，停服整整12個小時。

二，攜程事故之后我們做了什么，***落實了什么

當時我提出在Business Continuity Plan（BCP，業(yè)務持續(xù)計劃）之外盡快落實Disaster Recovery Plan（DRP，災難恢復計劃）。

DCP的目標是：

• 當IDC機房物理無法連接時，可快速異地重建生產系統。

它分為兩個層級：

• 代碼和配置的災難可恢復性；

• 數據的災難可恢復性。

時至今日其實通過以下做法間接達到了DCP的目標：

• 代碼和配置的災難可恢復性：

  • Docker鏡像：Web容器的配置都在Docker容器鏡像里；

  • 私有分布式鏡像倉庫，能夠做到在混合云多機房各處都有自動同步的鏡像庫；

  • 異地雙活機制等于說異地備份了Nginx/DNS等服務配置信息；

  • CloudEngine（我們的研發(fā)協作平臺）里保存了各種工程在不同環(huán)境里的應用屬性（也是配置信息）；

• 數據的災難可恢復性：

  • 異地備份：在iDB（我們的數據庫自動化運維平臺）的幫助下有數據庫自動備份以及備份的可恢復性自動檢查，并且做了異地備份；

  • 異地雙活機制等于說異地同步了全量數據庫。

[[256195]]

三，20190120拼多多無門檻優(yōu)惠券大事故

2019年1月20日凌晨1點到10點，整整9個小時，羊毛黨徒們狂歡，從拼多多領?。ǘ皇菗屬彛?00元無門檻優(yōu)惠券，據信拼多多損失高達數千萬元。

據傳，這個無門檻優(yōu)惠券實際上對應于已過期的運營活動，但由于操作失誤，導致凌晨又重新上線。

p.s.:

劵的來歷：〃在拼多多官方的公告中指出此券為拼多多此前與江蘇衛(wèi)視《非誠勿擾》開展合作時，因節(jié)目錄制需要特殊生成的優(yōu)惠券類型，僅供現場嘉賓使用。除此之外，此種類型優(yōu)惠券，從未在任何時候、以任何方式出現在平臺正常的線上促銷活動當中，甚至從未有任何線上入口?！?/p>

四，拼多多事故對我們的啟示，以及我們要做什么

運營規(guī)則，技術防護，風控預警，法律條款，電商行走江湖的四大護身法寶，缺一不可。

出了事兒不可怕，怕的是都沒有人知道出事兒了。要不是當天上午有并發(fā)異常，拼多多技術團隊也不會順藤摸瓜發(fā)現被領走那么多券。

風控體系的建立，至關重要：

• 我們已經上了業(yè)務保障平臺和全鏈路追蹤，能夠實時監(jiān)控第三方支付通道的活動，及時預警。但這還遠遠不夠。

• 應建立自動化的交易監(jiān)控機制和風險監(jiān)控模型，實時監(jiān)控，及時預警；

• 應通過分析欺詐行為特征創(chuàng)建反欺詐規(guī)則，對交易數據實時分析；

• 應制定異常交易監(jiān)測和處理的流程和制度；

• 應依據已識別并確認的風險數據，建立黑名單數據庫；

• ……

每個電商都有規(guī)則漏洞，都有程序漏洞，無非是在多大范圍內被黑產和賺客們薅羊毛。

風控體系包括對傳統業(yè)務指標的監(jiān)測和報警，至少能讓我們發(fā)現系統潛在的漏洞，及時修補，而不是***一個知道系統出事兒的人。

我們要把別人的歷史當作自己的未來，這樣才能知道過去人家錯在哪里，我們現在應該怎么做。

再贈送舊文一篇，也是攜程事故之后寫的。

攜程旅行網的技術團隊今天注定是一個不眠之夜，我的猜測是自動化運維系統過于強大以至于誤操作后覆水難收，加之歷史悠久規(guī)模龐大各種新老系統交錯，全面從新部署與平常迭代上線肯定不一樣，難度系數更高。

這也就是為什么過去我反復強調審計歷年來對我們做的企業(yè)內部安全審計非常重要，他們提出的意見，我們必須認真審視認真去落實。

為了警醒各位技術人員，下面列出本次攜程誤操作事件引發(fā)的各種手滑吐槽。

• Rebuild：

  • 當年酷殼在亞馬遜的時候，AWS的一個新人在工作***天做熟悉開發(fā)環(huán)境自助培訓時，他本來想連測試環(huán)境，結果連不上，老員工給了他一個配置，他沒分清哪個是測試的，哪個是生產的，不小心聯上了生產線數據庫，把整個數據庫給 Rebuild 了，導致全美 Netflix 停止服務數小時；

• Recreate：

  • 某人用 hibernate 反向生成數據庫的一張表，并且連的是測試庫，結果一個配置沒加，把所有的表都格式化掉并重新創(chuàng)建了一次。

• UPDATE沒有WHERE條件：

  • 十一年前，某人手寫 SQL UPDATE 線上數據庫，由于引號把 WHERE 子句截斷，用戶原創(chuàng)內容幾乎全都被清空，不幸的是運維也出錯了，備份程序停了半個月，于是全公司同事手工到搜索引擎快照中找回用戶的文章。

  • 以前更新錯誤數據，結果手滑 where 條件還沒寫完呢，想動一下鼠標，結果點到執(zhí)行。一下子把所有的采購單數據的某個金額給改了，后來 dba 立刻恢復我操作以前的數據，就這三五分鐘的時間，客服那邊就接到了超多投訴電話。

• 配錯了：

  • 有次做帶寬調度算法，方向寫錯了，瞬間給一個 CDN 提供商搞了 100G 上下的帶寬，持續(xù) 16 小時。給公司造成了近 20 萬的帶寬費用。某人至今最貴的bug。

• 自己挖坑：

  • 某人曾把整個服務器全部抹掉了。事情是這樣的，有一個硬盤是鏡像備份，掛載的時候用 sda1 這樣的名字，沒有用 uuid。后來加了個硬盤，結果原來的數據盤成了 sda1，等于說從一個空盤做鏡像。

  • 在高盛剛入職的時候一不小心把生產環(huán)境 compliance 數據庫鎖了，紐約 gsam 的 equity trading 停頓了15分鐘，完了經理跟我說，沒事兒，我闖過更大的禍。

• 膽子太大

  • 好幾年前剛開始學著做 windows 服務器管理，把幾個 windows 服務禁用，結果造成有服務互相依賴啟動不了，停機幾十個小時。

• 已然不知道該怎么說了：

  • 某年研發(fā)部所有電腦硬盤被偷，95%+的產品都丟了源代碼，為了維護一個已經上線的產品不得已，掛 HttpHandler 來處理。

  • 某客戶為了重新部署系統，將數據導出備份到移動硬盤，然后將 Raid 重新格式化，重新安裝系統，當進行 Oracle 數據庫重建，導入數據時發(fā)現，移動硬盤上的數據無法正確讀取，文件缺失一半。

  • 曾經在 catch 里寫過 system.exit。

  • drop 過生產環(huán)境數據庫表的路過。

  • 剛入行時曾在代碼里加過 system rm，然后測試環(huán)境里的大部分程序都失蹤了，天真的以為是黑客干的。

  • 曾經把圖片的地址都寫成了“undefined”，上線后以為被 ddos 了。