有底線思維的運維人員，一定會將業(yè)務連續(xù)性或者備份、容災等放在這張圖里，但很可惜，沒有。這只能說明，微盟對IT運維最后一道防線（業(yè)務連續(xù)性）很不重視。
當然，這不是說沒有備份容災機制，實際上是有的。很明顯的證據(jù)是，目前微盟和騰訊云在恢復數(shù)據(jù)，如沒備份，就不會有這個操作，微盟也就直接關門了。
但顯然沒有將備份容災上升到業(yè)務連續(xù)性的高度和廣度，這是觀念的問題。任何一家公司，都需要重視這道防線，無論重視的程度有多高，都不為過。
二、運維權限管理的問題
顯然，一個人就可以造成這樣的后果，運維的權限管理出現(xiàn)了問題。
通過權限的三權分立（操作、授權、審計），不經過審計員監(jiān)控下的安全員的授權，操作人員無權操作，而實際操作只有操作員可以操作，可以直接避免這個事件的發(fā)生。除非團伙做案。
以上二個問題是可以直接得出結論的，不難分析。
下面來做一些更深層次的分析
先看這個
從恢復時間看， 第一階段 已在25日24點恢復系統(tǒng)，新用戶可以使用系統(tǒng)，持續(xù)了53小時。第二階段 將在28日24點恢復老用戶的數(shù)據(jù)，將持續(xù)125小時。
再看看微盟的系統(tǒng)規(guī)模：
個人認為，賀某的操作有二種可能，第一是執(zhí)行了rm -rf /*，但不僅僅對數(shù)據(jù)庫的主備庫的服務器執(zhí)行了操作， 還把其他的應用服務器、Web服務器都做了操作。因為，互聯(lián)網(wǎng)公司的數(shù)據(jù)庫架構，應該是橫向擴展的（上面運維架構圖中的數(shù)據(jù)庫自動擴容功能），可以分鐘級部署一個新的數(shù)據(jù)庫來服務于新增的客戶，也就是說，如果只是數(shù)據(jù)庫出問題，其實只要分鐘級就可以恢復了，不需要53小時（從出問題到可以對新客戶進行服務）
第二種可能是，賀某直接把所有虛擬機干掉了，不管什么服務器，無差別刪除。效果和第一種是一樣的
基于以上系統(tǒng)損壞的覆蓋面的分析基礎，開始存在的問題分析
53小時的第一階段修復，引出了第三個問題
三、應用或者公有云敏捷性問題
第一階段的恢復要53小時那么長的時間，有點出乎我對互聯(lián)網(wǎng)公司的想象
要實現(xiàn)只對新客戶提供服務，不需要恢復到原有的規(guī)模，假定需要恢復到十分之一，即重新部署400套系統(tǒng)、100套數(shù)據(jù)庫，由于采用的都是云原生的基礎架構及管理軟件，53小時顯然過于漫長了（除非我對云原生技術的想象太美好）
造成這種情況的可能性有二種，一是應用開發(fā)沒做到無狀態(tài)化，需要大量的配置，耗費了時間。二是該公有云不夠敏捷或操作不夠熟練
怎么解決呢？這就要提起老生常談的災難恢復演練，基于底線思維，從0狀態(tài)開始演練，從而暴露技術儲備、應用開發(fā)、基礎架構等等方面的種種問題，并加以改進
作為IT運維老大哥的全國4大行經常做容災演練，就是基于這種底線思維?；ヂ?lián)網(wǎng)公司是小青年，有沖勁，有想象力，這非常好，但老大哥們走過的橋（踩過的坑）比小年輕走過的路還長，有必要好好學習的
四、 備份的問題
第二階段的恢復時間很有問題
前面說了，微盟是有備份，否則已經關門了
公有云都提供備份解決方案的，實現(xiàn)原理基本都是對虛擬機做快照，然后將快照數(shù)據(jù)保存到對象存儲內，而作為運行在公有云上SAAS互聯(lián)網(wǎng)公司，一般缺省都會直接使用公有云的備份
4.1 公有云的備份原理造成黃金時間的喪失
在原理上，備份快照可以即時恢復，但如果可以即時恢復，也就沒有第一、第二階段了，顯然，快照失去了作用或者快照內的數(shù)據(jù)是臟數(shù)據(jù)。
這種情況是怎么產生的呢？快照是定期執(zhí)行并有保留周期的，假定每2小時執(zhí)行一次快照，并保留2份快照。那么，從現(xiàn)在開始，我刪除數(shù)據(jù)，過四小時后，快照內的數(shù)據(jù)就是臟數(shù)據(jù)了，因為二份快照都是數(shù)據(jù)被刪除后的虛擬機狀態(tài)，沒用了。所以這四小時，就是“黃金時間”
是否可以延長“黃金時間”呢，很不幸，基于公有云的快照備份原理，如果延長黃金時間，會對生產造成很大的性能影響、成本及數(shù)據(jù)丟失量。有二種調整黃金時間的選擇
1、增加快照的保留份數(shù)：
快照會對生產虛擬機產生性能影響（假定快照采用Copy On Write的機制），保留的份數(shù)越多，性能影響越大，并產生更多費用。因此不會有人保留很多份。
2、延長執(zhí)行快照的時間間隔：
比如一天做一次快照，那么就有二天的黃金時間。但這會造成二天的數(shù)據(jù)丟失量（RPO）。也就是說最近二天的客戶數(shù)據(jù)將無法恢復。在正常情況下，沒人會選擇這么長時間的RPO。當然，微盟現(xiàn)在的心態(tài)，應該很希望用二天的RPO來換小時級的業(yè)務恢復。
具體微盟的黃金時間有多長，我們不知道，從公告中，可以看出，微盟需要和騰訊云技術團隊一起研究數(shù)據(jù)恢復，這一研究，黃金時間就過去了。
如何解決這一問題，建議采用第三方的備份軟件，并直接從數(shù)據(jù)庫層面去備份，而不是對虛擬機做快照。
第三方備份軟件，可以在不影響生產性能的前提下，將備份數(shù)據(jù)的保留周期設置很長。其實，當數(shù)據(jù)庫、應用服務器都出現(xiàn)問題時，備份作業(yè)也就不會發(fā)起，就不會有臟數(shù)據(jù)。
其次，通過對數(shù)據(jù)庫歸檔日志的備份，可以將RPO縮短到分鐘級。
當然，在選擇備份軟件時，RTO必須重點考慮，如果也要125小時，就和公有云的備份效果沒什么區(qū)別了。
4.2 把快照作為備份，違背了備份的鐵律
對虛擬機做快照的備份方式，還隱藏著公有云本身可靠性帶來的風險，如果虛擬機的存儲出現(xiàn)問題，生產數(shù)據(jù)與快照數(shù)據(jù)會一起損壞，專業(yè)備份軟件廠商都不會建議生產存儲的快照作為備份的，這是備份架構設計的鐵律。
去年，某云就因為存儲問題造成某企業(yè)數(shù)據(jù)丟失，當時沸沸揚揚，現(xiàn)在大家可能都忘了吧
公有云公司也都知道這一點，所以，他們都會將快照數(shù)據(jù)保存到對象存儲，甚至再復制一份到另一區(qū)域的對象存儲。
4.3 125小時的對象存儲還原時間
現(xiàn)在微盟正在恢復的數(shù)據(jù)在哪里呢？ 在COS對象存儲或CAS歸檔存儲內。快照執(zhí)行后，快照內的數(shù)據(jù)可以自動放入對象存儲或歸檔存儲內，并設置很長的保留周期
從對象存儲內進行恢復，預估時間是125小時，這個RTO真是長啊，目前還不知道會丟失多少數(shù)據(jù)，我預估在一天，因為從快照到對象存儲的數(shù)據(jù)復制的頻率，不會很頻繁，估計是一天一次
現(xiàn)在要做的操作是：先從對象存儲內將數(shù)據(jù)庫服務器的備份數(shù)據(jù)還原到塊存儲，再基于塊存儲的備份數(shù)據(jù)生成虛擬機，然后就是起數(shù)據(jù)庫，并和第一階段起來的應用服務器進行連接配置
這里，最花時間的就是還原操作，由于對象存儲的特性，這個速度會很慢
我們假定需要恢復125TB的數(shù)據(jù)，125TB怎么來的呢？一般互聯(lián)網(wǎng)公司的單個數(shù)據(jù)庫會保持在500GB，官網(wǎng)上說有1000+個數(shù)據(jù)庫，主備比率假定為1:3。數(shù)據(jù)量為 1000/4*500GB=125TB
如果還原速度是1TB/小時，那就需要125小時
如果還原速度是2TB/小時，那就需要62.5小時
1TB/小時快不快？對于對象存儲來說，其實已經很快了。騰訊云的技術人員肯定在想盡辦法提高這個速度：網(wǎng)絡帶寬、還原并行度等等。這次的服務費應該可以讓一家小公司好好的吃上一年了
有辦法大幅減少這個還原時間嗎？
有，如果備份數(shù)據(jù)，無論是在塊存儲上還是在對象存儲上，都不需要還原操作，直接通過掛載方式恢復數(shù)據(jù)庫。那么，250個數(shù)據(jù)庫（共125TB數(shù)據(jù)庫），很有可能100分鐘內就完成恢復
這種技術就不展開講了，有興趣的人，自會找到誰可以提供
總結一下
其實上述各種問題的引起和解決方案，20年前就廣泛提倡的業(yè)務連續(xù)性管理，就是答案。底線思維、領導意識、備份、容災、RTO、RPO、災難恢復演練等等，都包含在業(yè)務連續(xù)性管理的框架中
領導重視，然后有頂層設計，全面審視業(yè)務連續(xù)性方面可能存在的問題，再建設應對方案。就能消滅年年都在媒體上曝光的這類事件
希望微盟能順利恢復
發(fā)展很重要，但后方安穩(wěn)才是你前進的基礎。
秦人不暇自哀，而后人哀之；后人哀之而不鑒之，亦使后人而復哀后人也
