最近一段時間， 接二連三出現安全和運維事故， 先是支付寶服務因線路被挖，局部服務中斷； 接著是攜程整站被刪，給企業帶來了巨大的損失，到目前為止，攜程用了10多個小時全部恢復過來。其間，各種消息滿天飛，有在討論為何沒有備份，有在討論雙活為何沒生效，有在討論系統被黑，有在討論內部員工干的，也有說是出打bug了，發布的東西立即被刪，最后被官方確定為員工誤操作引起等。歷史以來的事故背后，總會有一連串的故事， 但歸根結底，還是那些爛熟于胸的分類：硬件故障，人為破壞，誤操作，軟件設計缺陷等。我還是引用微信上說的話，安全是細活，但做得再細，再強大的團隊也是無法規避問題的出現。但，如何規避呢？

手動實施，基礎入門措施，沒做的，趕緊做起來

在線類業務/核心業務，特別對于依賴互聯網渠道銷售的企業來說，是企業重中之中，應當作為第1優先級來保護。首當其沖，是對其核心數據庫進行主從部署，如果有銀子，另外這些節點應當都具備一定的節點容錯能力，也就是說Raid這些技術上去。但主從的問題，實際上，不少企業沒有做從啊，好可怕的。這里如果做了，+1分。做了從以后，還要在本地備份，對如果有備份意識的，其實已經做了。但是否就足夠了呢？ NO，本機備份只是很簡單的方案，理論上，出現問題的概率也基本一樣，一樣被刪，硬件故障一樣沒用。這時候，就需要手動復制一份到其他地方去，進行異地備份。這里做了，再+1分，遺憾的是更少的企業會做這個。

以上是一個簡單的對核心數據庫進行備份的方案，但這也僅僅是一個基礎，數據小，業務簡單也不是難事，寫幾個腳本就可以了。一旦當數據和業務規模發展起來后，數據量，業務種類，節點數目，版本迭代，研發流程等都會全面影響數據管理策略。遺憾的是，從目前了解的信息看，不少企業的負責人或執行團隊，并沒有與業務一起進步，忽略了數據連續性的價值，才導致看起來很低概率發生，最后變成了下一攜程。

總體來說，手動方案靠1個有態度，且敬業的團隊，否則，這個方案出問題的可能性很大

全程自動化，系統化，數據大、業務多、團隊大的場景，更鼓勵用此方案

我們簡單想象一樣，數十TB級數據，100個節點，10臺DB，30個業務，加上互聯網敏捷式的按天，按周的迭代，互聯網企業運維團隊常用的備份小技巧，主從，手動，本地，異地，手動歸檔等會變成麻煩起來了： 忘記做備份， 空間滿備份失敗，找不到備份版本， 備份慢，傳輸異常中斷，恢復慢，換人了，甚至備份了，也不敢用來恢復，……你說有啥用呢。

實際場景會更復雜，在線系統，內部研發系統，關鍵業務支撐系統等，加上團隊規模一大，基本上這塊事情就變復雜了。

對此，比較好的方案就是系統梳理業務類型，數據類型（DB，圖片，視頻，文檔，代碼），是抓取的，還是編輯產生的，內部，外部，需要保護的策路，包括頻率，以及數據保留的歷史周期，選擇好容錯能力的存儲設施，業務數據的敏感程度等，抽象幾種行為的結果，統一對數據，應用代碼進行本地和異地備份，對比較歷史的數據直接歸檔到離線位置。同時考慮在出現緊急問題后，最好能夠快速對核心系統恢復，甚至瞬間對部分核心環節的文件，數據庫單表進行恢復。結合自動化邏輯，不管規模有多大，按內外，按業務，按部門等視圖，集中在一個系統管理起來，一個系統全局掌握企業的核心業務分布，數據保護狀態；當出現這類緊急情況后，通過自動化系統，只需要在數十分鐘，有序就恢復了；一切盡在掌握。你說，這樣該有多好??？當然實際攜程的網絡結構會更復雜，對全網實施，需要比較長時間梳理和設計，如5.28這種全網出問題后，恢復的時間會略長。

自動化方案就比較多，做數據管理和保護的IT公司不下500家，像IBM、HP、Dell、EMC、賽門鐵克、康沃、飛康、愛恩鐵山、CA、carbonite這些老牌的上市公司，由于歷史傳統IT基因，這類對互聯網類型基本難適應，互聯網類公司一般也不原意用；還有很多新型的互聯網創業公司，如Datto、code42、durva、Rubrik等企業。深圳的一家企業，多備份，算是后起之秀，互聯網化的產品，全新混合云自動備份保護路線，一站式支持各型主流DB系統，OS，各型類型數據集中管理保護。無論在線，還是內部系統，文件和數量多大，可以對IT運維團隊非常友好，一個面板集中管理起來，更適合攜程這種現象的治理。

那，已經做了，如何？不把雞蛋放在一個籃子

同1個磁盤，同1個節點，同1個機房，同一個人維護，統一鐘存儲設備等都是雞蛋放在籃子的表現，對于重要的數據，這不是良策。不少情況出問題，都由這幾類原因發生。因此

無論如何，一個健壯的數據保護系統，必須要有能力規避掉。多點存儲，異地，交叉檢查，還是要結合用上的。

我經常聽到不少同學提到，我們是用的云，我們是用的這家云，很牛的云，很多案例，但又能怎么樣呢？云不是萬能的，都是人寫代碼，加上機器壘起來的，是人就會犯錯誤，硬件不例外，數據中心也不例外，微軟發生過，AWS也發生過。對于云磁盤本身的快照也只能做到整體恢復，存儲重點也是解決硬件故障。出問題的恢復動作其實滿大的，數據越大，越不容易可控 ， 對于可靠的備份機制來說，細粒度備份和恢復時必要的，備份的場景和恢復的需求太多， 云平臺強項是虛擬化計算和存儲。這就是為什么云平臺包括AWS，阿里云等都有備份保護類的服務。

從另外1個角度看，一個平臺依然存在一個籃子問題，所以我們鼓勵企業在做數據備份的時候，進行交叉部署，交叉備份管理，特別對于關鍵的業務系統和重要數據，尤其要注意，尤其是在關鍵發展階段的企業，即將要上市的企業啊，特別要注意的。

目前此環節，市面上傳統的IT企業推出的硬件方案，比較難做到這點，一般都需要采購一批硬件進行部署，實施的成本還是比較高的。面向云的方案是比較適應這類場景，國外有些企業比如Datto，Rubrik等都是基于云和本地混合保護方案 ； 而在國內，可以根據需要進行異構，異地，異云的交叉組合。

有心無力怎么辦

當然，也有超強備份保護數據意識的企業執行團隊，問題在于數據一大，預算就馬上爬升， 這樣的情況，有心無力，那怎么辦呢？ 其實還有第2個方案，就是基于混合云的技術?；谠频募夹g一次投入超低，幾千塊就起飛了，成本隨企業的發展，其實都已經攤薄，這樣天然就是異地的方案，如果說你擔心安全，其實也沒必要，數據加密上去，退一萬步講，云平臺被入侵了也不擔心，其實國內主流的云平臺都是一線企業，舍他選誰？安全是他們生命，比任何一個企業都在乎；如果這樣你還不放心，你說你數據比銀行要求還機密，這樣一些相對歷史或邊緣的數據，可以選擇加密上云。當然，只有云還不能解決快速恢復的問題，特別對于數據規模比較大的情況下，這時候，就要用本地和云混合的方案來解決。本地用一般的NAS，服務器，或再數據上到10TB級，專業點用SAN，當出現問題后，可以并行從本地往各個節點，系統進行同步恢復。類似攜程這種情況，幾分鐘到幾十分鐘也就OK了，至少對于關鍵幾個業務系統。隨后周邊一些業務在主系統恢復的時候，逐步按批次恢復。基本也就在1-2個小時就全網恢復了。萬一本地的備份系統也被干掉了，那還可以從云端以數Gb級的速度做災難恢復。國內了解到有一些創新型企業都在做此類事情，提供自動化，基于混合云，集中管理的方案，無論多復雜的業務結構，都可以清晰梳理，并有序管理起來，有效規避人為，自然，系統因素。

最后，如何整起？

當然，你說你是很牛的企業，人多，錢多，愿意投入數十人的IT運維工具開發團隊，花幾十到百萬，開發一套系統自動化做這些事情。但是，你愿意不，你能做到不？只有不到1/1000的企業會這樣投入做。當然，你說可以結合開源的工具來做，包括文件同步，數據庫導出工具，甚至二機制日志，也不是不行，最大的問題，還是在于數據量，業務量，網絡結構復雜后，這些都會變成問題 ；逐漸你的企業會變成依賴一個不愿意反復做類似事情的團隊，而不是一套針對性的系統來解決問題。

本文的最后的觀點是：以小投入換基業常青！專業的事，就交給專業的服務去干吧！互聯網的問題，用互聯網的工具來解決！