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

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

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

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

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

全程自動化，系統(tǒng)化，數(shù)據(jù)大、業(yè)務多、團隊大的場景，更鼓勵用此方案

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

實際場景會更復雜，在線系統(tǒng)，內(nèi)部研發(fā)系統(tǒng)，關鍵業(yè)務支撐系統(tǒng)等，加上團隊規(guī)模一大，基本上這塊事情就變復雜了。

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

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

那，已經(jīng)做了，如何？不把雞蛋放在一個籃子

同1個磁盤，同1個節(jié)點，同1個機房，同一個人維護，統(tǒng)一鐘存儲設備等都是雞蛋放在籃子的表現(xiàn)，對于重要的數(shù)據(jù)，這不是良策。不少情況出問題，都由這幾類原因發(fā)生。因此

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

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

從另外1個角度看，一個平臺依然存在一個籃子問題，所以我們鼓勵企業(yè)在做數(shù)據(jù)備份的時候，進行交叉部署，交叉?zhèn)浞莨芾恚貏e對于關鍵的業(yè)務系統(tǒng)和重要數(shù)據(jù)，尤其要注意，尤其是在關鍵發(fā)展階段的企業(yè)，即將要上市的企業(yè)啊，特別要注意的。

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

有心無力怎么辦

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

最后，如何整起？

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

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