摘要：數人云告別人肉運維上海的實錄第二彈來啦本次分享的嘉賓是餓了么團隊負責人虢國飛。虢國飛餓了么團隊負責人從事數據庫領域年，主要關注于數據庫管理自動化建設和等領域的研究。本次主題關于數據安全的保障。在這一層，餓了么做了一些數據方面相關的保護。

數人云“告別人肉運維”上海Meetup的實錄第二彈來啦！本次分享的嘉賓是餓了么DBA團隊負責人虢國飛。實錄將從用戶訪問、數據庫架構體系、數據備份、數據流轉和數據操作等幾個方面介紹餓了么目前在數據安全方面的一些措施。

虢國飛 / 餓了么DBA團隊負責人

從事數據庫領域10+年，主要關注于數據庫管理自動化建設和MySQL、Pg、MSSQL、NoSQL等領域的研究。

本次主題關于數據安全的保障。前面的引子是Gitlab數據庫出現問題，它有五重的數據保障，但都失效了。開始之前有幾個問題：

在座很多是做運維或數據庫工作的，現在公司數據庫有備份嗎？

如果數據庫有備份，多長時間做一次還原測試來驗證數據庫的備份是不是有效？

有沒有一個月之內做一次整個備份檢驗的？在一個月之內做一次，比如一年做十次或者十二次還原檢驗？

帶著上面的疑問，我分享一下餓了么在數據安全上所采取的一些措施，包括備份和還原的方式，與大家一起探討。

本次活動主題是如何減少人肉運維，讓數據庫運維和業務運維實現自動化。為什么做到保持有備份，并且驗證備份有效的公司不是那么多呢？關鍵在于資源，資源不光包括硬件資源，也包括人力資源。如果通過人肉方式時刻保證整套系統持續有效運作，成本相當高。

數據在入到數據庫之前，可能會面臨一些注入的攻擊甚至拖庫等風險。用戶訪問數據庫的時候，餓了么有一個中間層叫做DAL層，如果做一些分庫分表的應用很多時候都會運用這一中間層軟件，開源軟件有此類功能的也很多，像mycat、atlas等。

在這一層，餓了么做了一些數據方面相關的保護。首先，因為有中間這一層，所以在底層數據架構方面對研發或者對外都是一個不透明的狀態，拿不到具體數據庫IP地址，我們只把這些敏感的信息開放到有限的一些人的手里；第二層面，在DAL層把一些敏感的信息全部加密掉，比如用戶名、密碼這種訪問數據庫的信息；第三，會對風險的SQL做一些限制，比如一次要拉一百萬數據的SQL，是不支持的，或者想drop一個表，這樣的風險動作都會屏蔽掉。

餓了么對外開放的一些權限在賬號部分也做了限制：

首先，每個業務都是專用的賬號，不會多業務共用一個賬號；

第二，賬號權限是最小的，一般就是增、刪、改、查，有的甚至是只有增、改、查三個權限，刪除權限都沒有，所以賬號風險是最小化。還有一個是對內網的網段去做限制，在賬號賦權的時候限定它能訪問的網段；

第三，SQL限制講過，DAL層會做一些相應的限制，在數據庫一層也可以去做，比如一些更新的SQL是不帶條件的，這時可以限制掉，包括刪除的動作。如果沒有帶條件，這個風險是很高的，一般認為都是有問題的，所以這部分風險會在數據層去屏蔽。

在數據訪問上，主要把信息進行一個屏蔽以及加密，以及對權限和操作的動作做了一層保障。DAL的架構在中間層，也是相當于對數據庫提前做了一個訪問控制和負載均衡層，當然它的功能不止這一點，還包括剛剛說的路由，一些緊急SQL的屏蔽等。

數據進來之后會面臨各方需要使用數據的問題：
首先，在DAL這層進到生產數據庫的時候，在入口這一端做限制；
第二，數據落到相應BU生產數據庫的時候，如果這些數據要給其它BU去訪問，數據應該如何提供？目前比較通用的方式是通過接口，某個BU去調用其他BU一些相應的業務接口提去數據。如果接口提供不了的話，跨業務的訪問也走DAL層，DAL會把所有訪問的痕跡記錄下來。對于生產的數據，現在有很多研發會要求在他們的alpha和beta環境去做壓力測試，要同步生產的數據，還有需要查生產的數據，但這些數據可能包含敏感數據，怎么辦？

餓了么開發了一個DBQuery的軟件。對研發來說DBQuery能提供能查生產的數據，然后導出生產的數據，同時還能夠把數據同步到其它的環境，但是這些操作都是受限的。首先它能操作的數據量是有限的，一些敏感的記錄會做脫敏的處理，所有研發人員在上面所做的操作都會被記錄下來，例如在上面做的導出動作、拉取數據、查詢等。如果是這個平臺本身不能支持的需求，那么會聯合DBA和安全團隊去做把關，比如要對第三方提供一些大數據量的數據，這樣會有安全的保障。所以數據流的控制從入口，跨業務團隊的訪問，以及到不同的環境數據同步，包括研發想查看的這些記錄，都會記錄下來它的操作，以及對這些操作做相應的限制。

DBA最重要的一個責任——數據庫的備份和還原。餓了么的方案和大家所知道的或所了解的都差不多，但是如何把它做到或者更好的做到，各個公司都會不一樣。餓了么有全量、增量、以及Binlog的備份，然后會拷貝到Ceph做保存，包括本地的備份和遠程的備份。關鍵的第三點，它能夠完成自動的部署、運行和監控。一個業務上線的時候，因為有標準化，上去之后，備份就自動跑，如果沒有備份，就會收到告警。運行得正不正常，或者備份中失敗了，或者沒有運行備份，都可以通過監控的一個界面看到情況，備份的時長以及什么時間點去做的、在哪些機器上去做的，都是自動在后臺運行的。

數據還原也是如此，有一個循環的周期。餓了么重要數據驗證周期是15天。因為有好幾百套DB，15天到一個月，重要的是15天會驗證一次，一個月周期的是不太重要的一些業務，都會在循環的周期去做驗證。驗證除了檢驗備份的可靠性以外，還有一個目的，即拿到數據還原的時長。研發或者領導會問如果現在某個數據庫出現了問題，多久能夠找回來或者還原回來數據？這些都是需要數據支持的。它還可以去抽樣，除了它自己循環去檢測的，可以隨時拉一個庫出來，還原到哪個時間甚至哪個點位都是可以的。餓了么通過平臺去實現，不需要找機器、再找被分在哪里，只要告之要還原的是哪個庫，想還原到什么樣子，維護成本很小。

上圖右側截圖里有一些應用的時間以及它的狀態是成功還是失敗。

除了在防范數據入口的時候對業務的數據進行一些控制，還要在底層做一些備份還原保障，另外DBA的一些操作對數據安全也相當重要，這部分出問題的情況也不少。在如何保證DBA操作的安全方面，很多公司都會有各種各樣的軍規。

類似的軍規餓了么也有，但現在慢慢淡化，因為軍規是與人相關的因素，特別不可控，餓了么之前做軍規的時候把那些操作的風險都分了不同的類，一個要求是能保證操作的時候能夠快速的回滾，舉個例子，比如清空一個表的數據應該如何做，因為有時風險很大。我們的處理方式是先把這個表去rename一個待刪除的表，放一周之后會有自動的任務再去清理這個表。如果操作的時候出現問題，那可以馬上讓它rename恢復過來。還有一個限制是風險操作在操作的時間上做限制，不能在業務高峰時間去做這些動作，是有一個維護的窗口期，在業務的低峰期才去做。這樣能夠保證一旦出問題損失最小化，雖然我們能夠快速恢復，但是如果在高峰時間操作其影響仍然很大，如果選擇有維護窗口期的話，損失是最小的。

之所以講淡化軍規是因為現在餓了么想做工具化，這個工具里最重要的是把高風險操作的流程步驟固化到工具里面，讓工具去操作，人就不用太在意操作的流程是不是OK的。有些做不到的流程，它也會提示出來有什么風險，操作的時候會給DBA一個相應的警告。工具化之后，很多操作就可以在后臺自動運行了

以上實際在生產上面跑的一些需求，紅色的部分大部分是自動執行的，因為平臺上線的時間才幾個月，之前這部分全是DBA在操作的，現在有很多任務DBA不需要自己操作，由后臺的系統任務去調度起來，基本上沒有風險，所以需要關注的點就變得越來越少了，人力也可以解放出來把這個平臺做得更好。餓了么今年正在做一個開發的自助平臺，設計的目標是研發能夠在上面完成數據庫的一些操作，包括數據歸檔，加表等動作，符合平臺驗證規則的話DBA不需要干預。

上圖是餓了么現在架構的情況。首先有兩個機房，A機房和大家主流的部署架構差不多，即主從的一個架構。有一臺特殊的機器DS（DelaySlave），它會保持與生產數據的數據同步有一個時差，比如它會延后一天或者是半天的時間、12小時，如果生產操作出現了問題，就可以快速的通過它回放到操作前的一個點把這些數據找出來。這樣的恢復速度是最快的，追回的時間僅要幾分鐘。它不光提供半天之內數據快速恢復，而且餓了么的備份也都在上面做，這樣備份的時候不會影響到生產運行。哪怕這臺機器上跑很多的備份任務都不會影響，因為它主要是做數據的備份，而且監控就是在標準化部署這一臺之后，所有的備份任務和監控程序都會自動與它做匹配，所以只要完成這一架構的搭建，接下來的事情系統自動去做，也不需要人肉干預。如果它沒有備份成功或者備份失敗或者跳過了備份，在監控備份和還原監控里面都會得到體現。

下面這是做還原的一部分機器，我們是循環周期去做還原的，所以它在一個周期內必定會完成這些庫的校驗，驗證它的備份是否有效。在另一個機房，中間有一個組件叫DRC，這個軟件最初淘寶做得比較多，即跨機房的一些數據的同步。它提供了數據同步和訂閱的功能，監聽數據庫狀態的變更，而且在多機房之間同步的時候可以做很多動作，比方如數據的壓縮、過濾，還有剛剛提到的數據訂閱，出了問題它可以上報。此外，有一個特殊的機器叫QS，DBQuery服務的功能就部署在它上面，在上面會完成研發對數據的查詢以及數據從它到各個環境的導入、過濾和脫敏。

從整個架構體系對數據的保障來看，一是有多機房，二是主從的HA，以及DelaySlave和一些備份機制。從數據入進來到DAL層、到數據庫里面針對一些賬號權限的限制以及架構的保障和備份、還原體系的完善以及DelaySlave的延遲備份來保障餓了么整個數據的安全，這樣的架構體系為數據安全提供了多層保障。