有底線思維的運(yùn)維人員，一定會(huì)將業(yè)務(wù)連續(xù)性或者備份、容災(zāi)等放在這張圖里，但很可惜，沒有。這只能說明，微盟對IT運(yùn)維最后一道防線（業(yè)務(wù)連續(xù)性）很不重視。

當(dāng)然，這不是說沒有備份容災(zāi)機(jī)制，實(shí)際上是有的。很明顯的證據(jù)是，目前微盟和騰訊云在恢復(fù)數(shù)據(jù)，如沒備份，就不會(huì)有這個(gè)操作，微盟也就直接關(guān)門了。

但顯然沒有將備份容災(zāi)上升到業(yè)務(wù)連續(xù)性的高度和廣度，這是觀念的問題。任何一家公司，都需要重視這道防線，無論重視的程度有多高，都不為過。

二、運(yùn)維權(quán)限管理的問題

顯然，一個(gè)人就可以造成這樣的后果，運(yùn)維的權(quán)限管理出現(xiàn)了問題。

通過權(quán)限的三權(quán)分立（操作、授權(quán)、審計(jì)），不經(jīng)過審計(jì)員監(jiān)控下的安全員的授權(quán)，操作人員無權(quán)操作，而實(shí)際操作只有操作員可以操作，可以直接避免這個(gè)事件的發(fā)生。除非團(tuán)伙做案。

以上二個(gè)問題是可以直接得出結(jié)論的，不難分析。

下面來做一些更深層次的分析

先看這個(gè)

從恢復(fù)時(shí)間看， 第一階段 已在25日24點(diǎn)恢復(fù)系統(tǒng)，新用戶可以使用系統(tǒng)，持續(xù)了53小時(shí)。第二階段 將在28日24點(diǎn)恢復(fù)老用戶的數(shù)據(jù)，將持續(xù)125小時(shí)。

再看看微盟的系統(tǒng)規(guī)模：

個(gè)人認(rèn)為，賀某的操作有二種可能，第一是執(zhí)行了rm -rf /*，但不僅僅對數(shù)據(jù)庫的主備庫的服務(wù)器執(zhí)行了操作， 還把其他的應(yīng)用服務(wù)器、Web服務(wù)器都做了操作。因?yàn)椋ヂ?lián)網(wǎng)公司的數(shù)據(jù)庫架構(gòu)，應(yīng)該是橫向擴(kuò)展的（上面運(yùn)維架構(gòu)圖中的數(shù)據(jù)庫自動(dòng)擴(kuò)容功能），可以分鐘級部署一個(gè)新的數(shù)據(jù)庫來服務(wù)于新增的客戶，也就是說，如果只是數(shù)據(jù)庫出問題，其實(shí)只要分鐘級就可以恢復(fù)了，不需要53小時(shí)（從出問題到可以對新客戶進(jìn)行服務(wù)）

第二種可能是，賀某直接把所有虛擬機(jī)干掉了，不管什么服務(wù)器，無差別刪除。效果和第一種是一樣的

基于以上系統(tǒng)損壞的覆蓋面的分析基礎(chǔ)，開始存在的問題分析

53小時(shí)的第一階段修復(fù)，引出了第三個(gè)問題

三、應(yīng)用或者公有云敏捷性問題

第一階段的恢復(fù)要53小時(shí)那么長的時(shí)間，有點(diǎn)出乎我對互聯(lián)網(wǎng)公司的想象

要實(shí)現(xiàn)只對新客戶提供服務(wù)，不需要恢復(fù)到原有的規(guī)模，假定需要恢復(fù)到十分之一，即重新部署400套系統(tǒng)、100套數(shù)據(jù)庫，由于采用的都是云原生的基礎(chǔ)架構(gòu)及管理軟件，53小時(shí)顯然過于漫長了（除非我對云原生技術(shù)的想象太美好）

造成這種情況的可能性有二種，一是應(yīng)用開發(fā)沒做到無狀態(tài)化，需要大量的配置，耗費(fèi)了時(shí)間。二是該公有云不夠敏捷或操作不夠熟練

怎么解決呢？這就要提起老生常談的災(zāi)難恢復(fù)演練，基于底線思維，從0狀態(tài)開始演練，從而暴露技術(shù)儲(chǔ)備、應(yīng)用開發(fā)、基礎(chǔ)架構(gòu)等等方面的種種問題，并加以改進(jìn)

作為IT運(yùn)維老大哥的全國4大行經(jīng)常做容災(zāi)演練，就是基于這種底線思維?；ヂ?lián)網(wǎng)公司是小青年，有沖勁，有想象力，這非常好，但老大哥們走過的橋（踩過的坑）比小年輕走過的路還長，有必要好好學(xué)習(xí)的

四、 備份的問題

第二階段的恢復(fù)時(shí)間很有問題

前面說了，微盟是有備份，否則已經(jīng)關(guān)門了

公有云都提供備份解決方案的，實(shí)現(xiàn)原理基本都是對虛擬機(jī)做快照，然后將快照數(shù)據(jù)保存到對象存儲(chǔ)內(nèi)，而作為運(yùn)行在公有云上SAAS互聯(lián)網(wǎng)公司，一般缺省都會(huì)直接使用公有云的備份

4.1 公有云的備份原理造成黃金時(shí)間的喪失

在原理上，備份快照可以即時(shí)恢復(fù)，但如果可以即時(shí)恢復(fù)，也就沒有第一、第二階段了，顯然，快照失去了作用或者快照內(nèi)的數(shù)據(jù)是臟數(shù)據(jù)。

這種情況是怎么產(chǎn)生的呢？快照是定期執(zhí)行并有保留周期的，假定每2小時(shí)執(zhí)行一次快照，并保留2份快照。那么，從現(xiàn)在開始，我刪除數(shù)據(jù)，過四小時(shí)后，快照內(nèi)的數(shù)據(jù)就是臟數(shù)據(jù)了，因?yàn)槎菘煺斩际菙?shù)據(jù)被刪除后的虛擬機(jī)狀態(tài)，沒用了。所以這四小時(shí)，就是“黃金時(shí)間”

是否可以延長“黃金時(shí)間”呢，很不幸，基于公有云的快照備份原理，如果延長黃金時(shí)間，會(huì)對生產(chǎn)造成很大的性能影響、成本及數(shù)據(jù)丟失量。有二種調(diào)整黃金時(shí)間的選擇

1、增加快照的保留份數(shù)：

快照會(huì)對生產(chǎn)虛擬機(jī)產(chǎn)生性能影響（假定快照采用Copy On Write的機(jī)制），保留的份數(shù)越多，性能影響越大，并產(chǎn)生更多費(fèi)用。因此不會(huì)有人保留很多份。

2、延長執(zhí)行快照的時(shí)間間隔：

比如一天做一次快照，那么就有二天的黃金時(shí)間。但這會(huì)造成二天的數(shù)據(jù)丟失量（RPO）。也就是說最近二天的客戶數(shù)據(jù)將無法恢復(fù)。在正常情況下，沒人會(huì)選擇這么長時(shí)間的RPO。當(dāng)然，微盟現(xiàn)在的心態(tài)，應(yīng)該很希望用二天的RPO來換小時(shí)級的業(yè)務(wù)恢復(fù)。

具體微盟的黃金時(shí)間有多長，我們不知道，從公告中，可以看出，微盟需要和騰訊云技術(shù)團(tuán)隊(duì)一起研究數(shù)據(jù)恢復(fù)，這一研究，黃金時(shí)間就過去了。

如何解決這一問題，建議采用第三方的備份軟件，并直接從數(shù)據(jù)庫層面去備份，而不是對虛擬機(jī)做快照。

第三方備份軟件，可以在不影響生產(chǎn)性能的前提下，將備份數(shù)據(jù)的保留周期設(shè)置很長。其實(shí)，當(dāng)數(shù)據(jù)庫、應(yīng)用服務(wù)器都出現(xiàn)問題時(shí)，備份作業(yè)也就不會(huì)發(fā)起，就不會(huì)有臟數(shù)據(jù)。

其次，通過對數(shù)據(jù)庫歸檔日志的備份，可以將RPO縮短到分鐘級。

當(dāng)然，在選擇備份軟件時(shí)，RTO必須重點(diǎn)考慮，如果也要125小時(shí)，就和公有云的備份效果沒什么區(qū)別了。

4.2 把快照作為備份，違背了備份的鐵律

對虛擬機(jī)做快照的備份方式，還隱藏著公有云本身可靠性帶來的風(fēng)險(xiǎn)，如果虛擬機(jī)的存儲(chǔ)出現(xiàn)問題，生產(chǎn)數(shù)據(jù)與快照數(shù)據(jù)會(huì)一起損壞，專業(yè)備份軟件廠商都不會(huì)建議生產(chǎn)存儲(chǔ)的快照作為備份的，這是備份架構(gòu)設(shè)計(jì)的鐵律。

去年，某云就因?yàn)榇鎯?chǔ)問題造成某企業(yè)數(shù)據(jù)丟失，當(dāng)時(shí)沸沸揚(yáng)揚(yáng)，現(xiàn)在大家可能都忘了吧 

公有云公司也都知道這一點(diǎn)，所以，他們都會(huì)將快照數(shù)據(jù)保存到對象存儲(chǔ)，甚至再復(fù)制一份到另一區(qū)域的對象存儲(chǔ)。

4.3  125小時(shí)的對象存儲(chǔ)還原時(shí)間

現(xiàn)在微盟正在恢復(fù)的數(shù)據(jù)在哪里呢？ 在COS對象存儲(chǔ)或CAS歸檔存儲(chǔ)內(nèi)?？煺請?zhí)行后，快照內(nèi)的數(shù)據(jù)可以自動(dòng)放入對象存儲(chǔ)或歸檔存儲(chǔ)內(nèi)，并設(shè)置很長的保留周期

從對象存儲(chǔ)內(nèi)進(jìn)行恢復(fù)，預(yù)估時(shí)間是125小時(shí)，這個(gè)RTO真是長啊，目前還不知道會(huì)丟失多少數(shù)據(jù)，我預(yù)估在一天，因?yàn)閺目煺盏綄ο蟠鎯?chǔ)的數(shù)據(jù)復(fù)制的頻率，不會(huì)很頻繁，估計(jì)是一天一次

現(xiàn)在要做的操作是：先從對象存儲(chǔ)內(nèi)將數(shù)據(jù)庫服務(wù)器的備份數(shù)據(jù)還原到塊存儲(chǔ)，再基于塊存儲(chǔ)的備份數(shù)據(jù)生成虛擬機(jī)，然后就是起數(shù)據(jù)庫，并和第一階段起來的應(yīng)用服務(wù)器進(jìn)行連接配置

這里，最花時(shí)間的就是還原操作，由于對象存儲(chǔ)的特性，這個(gè)速度會(huì)很慢

我們假定需要恢復(fù)125TB的數(shù)據(jù)，125TB怎么來的呢？一般互聯(lián)網(wǎng)公司的單個(gè)數(shù)據(jù)庫會(huì)保持在500GB，官網(wǎng)上說有1000+個(gè)數(shù)據(jù)庫，主備比率假定為1:3。數(shù)據(jù)量為 1000/4*500GB=125TB

如果還原速度是1TB/小時(shí)，那就需要125小時(shí)

如果還原速度是2TB/小時(shí)，那就需要62.5小時(shí)

1TB/小時(shí)快不快？對于對象存儲(chǔ)來說，其實(shí)已經(jīng)很快了。騰訊云的技術(shù)人員肯定在想盡辦法提高這個(gè)速度：網(wǎng)絡(luò)帶寬、還原并行度等等。這次的服務(wù)費(fèi)應(yīng)該可以讓一家小公司好好的吃上一年了

有辦法大幅減少這個(gè)還原時(shí)間嗎？

有，如果備份數(shù)據(jù)，無論是在塊存儲(chǔ)上還是在對象存儲(chǔ)上，都不需要還原操作，直接通過掛載方式恢復(fù)數(shù)據(jù)庫。那么，250個(gè)數(shù)據(jù)庫（共125TB數(shù)據(jù)庫），很有可能100分鐘內(nèi)就完成恢復(fù)

這種技術(shù)就不展開講了，有興趣的人，自會(huì)找到誰可以提供

總結(jié)一下

其實(shí)上述各種問題的引起和解決方案，20年前就廣泛提倡的業(yè)務(wù)連續(xù)性管理，就是答案。底線思維、領(lǐng)導(dǎo)意識、備份、容災(zāi)、RTO、RPO、災(zāi)難恢復(fù)演練等等，都包含在業(yè)務(wù)連續(xù)性管理的框架中

領(lǐng)導(dǎo)重視，然后有頂層設(shè)計(jì)，全面審視業(yè)務(wù)連續(xù)性方面可能存在的問題，再建設(shè)應(yīng)對方案。就能消滅年年都在媒體上曝光的這類事件

希望微盟能順利恢復(fù)

發(fā)展很重要，但后方安穩(wěn)才是你前進(jìn)的基礎(chǔ)。

秦人不暇自哀，而后人哀之；后人哀之而不鑒之，亦使后人而復(fù)哀后人也

崔歡歡