讀完需要9
分鐘
速讀僅需7分鐘
相信這些天微盟的事情大家已經聽說了。
每每看到行業内的資料事故，我們在感慨之餘，更需要的就是自省，因為這可以敲響我們已有狀态的警鐘。微盟技術團隊從一個創業團隊一路走來，逐漸建立了較為成熟的安全管理規範，對伺服器和資料通路權限有着明确的分層和分級的授權管理制度，這次雖然有疏忽，實際上也是受害者。
根據事件跟蹤得知，本次騰訊雲從一開始就大力支援微盟，派了很多技術專家來幫助微盟和微盟的客戶，使得恢複得以順利開展。
但是問題要補救和修複，需要一套流程和制度和技術相輔相成，而且是一個持久改進的過程。米蘭.昆德拉曾經說過：永遠不要以為可以逃避，因為每一步都決定着最後的結局。
從個人了解，因為涉及的環境複雜，涉及團隊較多，是以恢複效率和驗證方面需要一些時間。在資料恢複方面，有一條不成文的規定，那就是資料在一定程度上可以丢，但是不能亂，丢的資料，可以通過其他方式進行補救，但是資料一亂就失去了修複的基準。因為這次是人為惡意操作，是以恢複的難度會更大。
我打算通過如下的三個部分來進行闡述。
流程：
1.完善故障演練流程，作為一項共同目标來請協作完成，做到忙而不亂
很多公司都會對故障演練存在一些疑慮，因為這會帶來一些潛在的隐患，越是不能動，不敢動，在出問題的時候修複的效率是很低下的，每個人和團隊更加關注自己這一部分的工作，顯然會忽略一些相關的環節，是以能夠組織故障演練的流程和規範，把這些梳理和固化下來，在處理問題的時候才能夠做到忙而不亂。
2.完善故障響應流程，什麼等級的問題系統哪些負責人介入
為什麼很多問題的修複進展不可控，一方面是需要團隊協作，另一方面是臨時去協調和熟悉問題，排查問題的效率是比較低的，可以考慮引入故障的等級分類，及時通知相關團隊，把一些問題的處理作為預先處理的環節提前接入。
3.運維操作需要報備
運維操作不做無準備的操作，不做加塞操作（比如臨時補充一些未經測試的腳本），重要操作，重大操作都需要報備，及時通告，把被動變為主動。
4.引入審計流程，實作獨立的服務審計機制
審計環節是一個相對重要的獨立環節，可以引入服務審計機制，可以通過獨立的審計服務發現潛在的隐患，及時督正問題。
5..業務異常預警，需要同步相關鍊路層
對于業務層的異常，業務預警是尤其關鍵的，及時預警，及時同步到相關的鍊路，可以避免系統雪崩的情況。
技術：
1.完善備份恢複體系，使得恢複能夠可控，高效。
比如基礎備份（全備和增量備份）和熱資料恢複(基于binlog的閃回技術)
備份恢複體系的建設是資料庫建設的基礎，也是衡量服務可用性的最後一根稻草。充分結合全量備份和增量備份，提高恢複的效率。
比如下面是一個全量備份和增量備份方案，實作一次全備，永遠增量的實作政策，然後在這個基礎上實作基于binlog的閃回。
2.叢集環境的恢複是系統薄弱環節。系統服務之間互相依賴，這是之前很少有人關注的，是以毫無疑問，這是一塊硬骨頭，我們需要重點關注。
3.使用資源回收筒技術，杜絕人為惡意，誤删除
備份能夠解決一些異常情況的資料恢複，但是效率相對不高，從規範角度來說，如何避免危險操作，轉而使用更加優雅可控的處理方式是我們需要思考的問題。
Drop操作是預設送出的，而且是不可逆的，在資料庫操作中都是跑路的代名詞，MySQL層面目前沒有相應的Drop操作恢複功能，除非通過備份來恢複，但是我們可以考慮将Drop操作轉換為一種可逆的DDL操作。
MySQL中預設每個表有一個對應的ibd檔案，其實可以把Drop操作轉換為一個rename操作，即把檔案從testdb遷移到testdb_arch下面；從權限上來說，testdb_arch是業務不可見的，rename操作可以平滑的實作這個删除功能，如果在一定時間後确認可以清理，則資料清理對于已有的業務流程是不可見的，如下圖所示。
此外，還有兩個額外建議，一個是對于大表變更，盡可能考慮低峰時段的線上變更，比如使用pt-osc工具或者是維護時段的變更，就不再贅述了。
4.服務權限設定，需指定用戶端權限
分業務管理主庫和備份庫，是網際網路行業的普遍慣例，很多公司普遍都會授予運維較大的權限，這也是導緻很多故障的潛在隐患。
在這方面我們可以參考如下的一張設計圖（來自張文宇老師），可以在多個環節發力，改進權限問題。
制度：
制度相對來說是比較嚴格，冷面的，我們可以在技術和流程規範之中尋找一些平衡點來輔助作為制度的基石。比如，密碼的安全等級設定，權限管理引入審批制度等，在此就不在贅述了。
希望删庫跑路隻是大家的一種玩笑，一旦當真就麻煩了。