129
2017，那些我們一起刪庫跑路的日子
出大事了！
據可靠消息，位於荷蘭海牙的一家雲主機商 verelox.com， 一名前任管理員刪光了該公司所有客戶的數據，並且擦除了大多數服務器上麵的內容，客戶數據恢複希望渺茫。
引用verelox.com公告全文：
首先，我們想要對由此造成的任何不便表示歉意！
不幸的是，一名前任管理員刪光了所有的客戶數據，並且擦除了大多數服務器上麵的內容。正因為如此，我們已采取了必要的步驟或措施，暫時將我們的網絡下線。我們一直在努力恢複數據，但是這個方法可能恢複不了已丟失的所有數據。我們的網絡和托管服務會在本周恢複正常，到時會打上安全更新版。仍對我們的服務有興趣的現有客戶將獲得服務的相應補償。
如果客戶有重要數據，請聯係我們：support@verelox.com。[email protected]�的數據。
我們給出的建議是，更改所有服務器密碼。
狀態更新1：（最終）位於荷蘭的所有專用服務器應該會在協調世界時（UTC）傍晚6點投入正常運行。我們仍在為雲服務器製定一套解決方案。
狀態更新2：所有專用服務器已正常運行。如果您的專用服務器還是遇到任何問題，請發送電子郵件至support@verelox.com。眼下，所有虛擬機都上傳到一台新的服務器。
等等，又是荷蘭？！我怎麼聞到了似曾相識的味道捏。沒錯，年初的GitLab的刪庫事件也發生在荷蘭！看來今年不是荷蘭的DBA時來運轉的好時期。
回到事件，要怎麼處理呢？我也不知道啊，靜觀其變。
不過這慘絕人寰的事情接連發生，讓多愁善感的小編又要失眠了。月黑風高，有酒有故事，我們一起來回顧下那些刪庫跑路的日子吧。
我們一起刪庫跑路
不知道什麼時候開始，有一本紅遍大江南北的書叫做《MySQL 從刪庫到跑路》廣泛流傳於IT界，並持續陰魂不散，帶著一股妖風，影響了整個IT界的風氣。廣大的運維DBA們，大概是找不到女朋友生活沒有什麼樂趣吧（小編已經做好被打死的準備了），非得找點好玩的事情來體驗下人生。什麼最好玩呢，當然是破壞！
來我們玩個遊戲！
問：你想刪庫嗎？
DBA：我有病啊
問：你想刪庫嗎？
DBA：不想啊
問：你想刪庫嗎？
DBA：要負責任嗎？
問：你想刪庫嗎？
DBA：我操，這麼刺激的事誰不想幹！
看出來了吧，沒有不想刪庫的DBA，隻有不想負責任刪庫的DBA。但是自從'從刪庫到跑路'這一思想傳遍大江南北，大家都知道了答案，再不濟我還可以跑啊！你是不是也是這麼想的。
大家都想刪庫，都想好了出路。果然2017在劫難逃。我們來細數一下2017所遭遇的刪庫跑路事件。
斷電又不怪我
1月20日，大約一定是受到川普上任的影響，突如其來的服務器故障影響了一大批爐石玩家，恢複時間長，由於意外斷電，導致數據庫損壞，不得不通過遊戲回檔恢複數據庫的使用。（關於爐石傳說的Oracle數據庫故障不要以為你也可以幸免）
遊戲進度回退了，辛辛苦苦掙來的裝備都不見了，然而麵對網易和暴雪如此誠懇的態度，想發火都不容易。
深夜加班我也累呀
2月1日，除夕剛剛過完，荷蘭的一個DBA在數據庫複製過程中意外地刪除了一個錯誤的服務器上的目錄，刪除了一個包含300GB的實時生產數據的文件夾。300G的數據庫被刪成4.5G，由於沒有有效的備份，嚐試了所有5個恢複工具都沒有完成恢複。在丟失數據並恢複失敗後，服務器徹底崩潰。（五重備份無一有效，還有哪些 rm -rf 和GitLab類似的憂傷？）
這估計是春節期間最勁爆的消息了，大過年的大家都放棄了吃肉喝酒的好光陰大半夜守著GitLab的故障分析直播。
講真，我還真沒有見過孩紙們這麼熱愛學習的時候呢。
老板你總是舍不得買高性能的存儲
2月11日，網絡剪報服務商 - Instapaper 遭受了超過31小時的服務中斷，聲明需要一個星期的數據庫恢複時間，然而經過10天的恢複，也僅僅恢複了6個星期的數據。（雲服務真的靠譜嗎？ AWS 用戶中斷31小時僅恢複6周數據）
Instapaper 最初的全文檢索使用一台 Sphinx 服務器直接和 MySQL 聯合提供搜索，這個搜索使用 AWS EC2 大約70GB 內存，4TB 存儲的資源：
Instapaper 的索引數據量（數據庫的數據量未知），在2016年5月時數據量2.2TB，每月增長約110GB，後來實在慢的不行，最後選擇了 AWS 的 elasticsearch cluster來承載這項服務。而最終，還是敗在了存儲，數據寫入失敗直接導致數據庫宕機。
別這麼看我，我們都犯錯，隻是我犯的錯誤更嚴重罷了
2017-04-05，位於紐約的雲服務商 Digital Ocean 遭遇了一次長達4小時56分鍾的停機事故，事故的原因是主數據庫被刪除了（primary database had been deleted），由於配置錯誤，本應指向測試環境的任務被指向了生產環境，測試任務包含的環境初始化過程刪除了主生產數據庫。（不以規矩不成方圓：Digital Ocean也刪除了他們的數據庫）
手動刪庫簡直太low，我都是腳本自動刪
又不禁想起了Google曾經轟動一時的流水線刪庫事件，這可是團隊作案喲，這麼團結真的好嗎？（時移世易：遵從既往經驗致 1.5PB 數據刪除，Google SRE是如何應對的？）
一個 Google Music 用戶匯報某些之前播放正常的歌曲現在無法播放了。Google Music 的用戶支持團隊通知了工程師團隊，這個問題被歸類為流媒體播放問題進行調查。3 月 7 日，負責調查此事的工程師發現無法播放的歌曲的元數據中缺少了一個針對具體音頻數據文件的指針，於是他就修複了這個歌曲的問題。
但是，Google 工程師經常喜歡深究問題，也引以為豪，於是他就繼續在係統中查找可能存在的問題，當發現數據完整性損壞的真正原因時，他卻差點嚇出心髒病:這段數據是被某個保護隱私目的的數據刪除流水線所刪掉的。Google Music 的這個子係統的設計目標之一就是在盡可能短的時間內刪除海量音頻數據。
該流水線任務大概誤刪除了 60 萬條音頻文件，大概影響了 2.1 萬用戶.
辦法不早就教你了嗎
刪庫就刪庫也沒有什麼了不起，但是千萬別說我沒有告訴過你處理辦法。不信往這裏看，歲末警示：當你手抖刪了線上數據庫..
互聯網發展仍是日新月異，挑戰無處不在。要想變挑戰為機遇，隻有創新和技術才有可能。隻有重視技術的公司，才能充分發揮技術人員的能動性，也將更容易在技術的競爭中勝出。
我們經常開玩笑，很多公司，做不到技術驅動，因為他的每一步都是領導提出領導拍板，它隻能叫領導驅動。而如果一個公司在遇到事情之後就總是想到懲罰，不注意保護和發揮技術人員的能動性，技術導向也隻能是一個口號。
所以下次呢，如果你手抖刪庫了，一定要冷靜地到你老板那裏說，人家也很傷心，需要抱抱安慰。
好吧你這樣就太過了，會被老板轟出去的。但你要記得，不要談故障的原因，要談解決方案，Be a man,你自己闖下的禍，自己承擔起來!
萬一老板真要懲罰你怎麼辦，一個字，跑啊！說實話，你是不是老早就打算刪庫跑路了，隻是一直沒有機會。
小編最近查了一下，發現想跑路的人真是不少。
我說大家都怎麼了呢，這是跟世界有多大的仇恨呀。不過考慮到，你們可能真的沒有遇到好老板心裏苦，你看像我這種生活在幸福深處的員工，有一個超級完美的老板，就完全不能理解你們普通人的心情。
既然你都有了這種想法，我好像也沒有什麼可說的了。但是我必須要再次苦口婆心地提醒你，備份重於一切！rm是危險的！三思而後行！如果這三句話還沒有成為你的座右銘，我覺得你應該需要休個假好好思考一下人生了~
既然你都耐心看到了這裏，不送禮我都不好意思結束文章，來收禮吧！
最後，小編實在沒實力，得找老板來撐下場子。壓軸出場，如何幸存於類似事故？
好吧，我們談一談如何避免陷入這樣的困境？以下是我們的一些思路，與大家商榷。
首先，要有完善、有效的備份和容災機製。誠然很多企業都有了一整套的備份、容災機製，但是這套備份機製能否真實奏效是需要檢驗的。我接觸過某大型企業，投入巨資興建的災備中心，從未正式切換過，這樣的災備在故障來臨時也很難有人拍板去進行切換，所以備份的有效、容災手段的有效是必須確保的。注意，備份的恢複速度必須足夠的考慮到，磁帶的低效備份關鍵時刻會害死人。
其次，要有完善的故障處理策略和流程。對於不同係統，在關鍵時刻要優先確保什麼，是要訂立規則的，有了規則才能照章辦事，不走錯方向，不無辜背鍋。幾年前某國內金融係統出現數據壞塊，同樣選擇了帶病修複，最終沒能解決問題，同樣選擇了回檔承擔了數據損失。
再次，要有端到端融會貫通的應急機製。也就是說不僅僅技術上具備容災應急的響應方案，從業務端同樣要有對應的預案，以便應急時同步處理，區別對待。很多時候，有了業務上的應急、降級服務方案，技術層麵的處理就能夠從容許多。
最後，要有能夠快速協同的團隊資源。很多時候嚴重的故障，需要較大規模的專業團隊協作處理，原廠商和第三方在其中都承載著重要的角色，所以關鍵時刻，要能夠獲得內外部快速及時的支持，尤其是在綿延數天的高強度工作中。
講真，不要把我們的話當成耳旁風，備份重於一切。預防和檢測少不了。
如果真的刪庫了，請找雲和恩墨，我們7*24為你的數據庫安全站崗。
文章轉自數據和雲公眾號，原文鏈接
最後更新：2017-07-17 17:03:00