其實2010年之前，大量的企業有它的核心業務，并不完全由IT支撐，比如說據我所知保險就不是由IT支撐的，是靠保單做的。隨著IT和信息的進步，很多東西都往上走，需要IT支撐。企業已經有offline做的很好，缺的是online。不管是電信還是金融。

舉一個例子，移動的一個中等規?；蛘咧械绕率?，一個月需要處理接近500億筆交易，事實上就是這樣的。

比如說像流量計費4G的業務，大家使用手機的時候，移動每隔一分鐘或者隔30秒計一次費，發一條微信或者聊天的話可能產生五六筆交易?？匆黄L微博需要17筆交易。

現在大銀行是每天計息的，因為資金流轉速度快，每天計息，精度高，銀行后臺系統的處理能力要提高20多倍。

傳統企業對IT的需求能力，有的時候超過人的想象。IT系統的連續性要求。要求更高，但問題是企業還面臨著一個沖突，企業架構在發生劇烈的變化，要求性能高，大規模，連續性還在提升。任何一個小BUG導致停機后，所有人都在指責。

IT規模不夠大的時候，大部分企業一個數據中心就夠了，如果為這一個數據中心提高可靠性的話，異地再建一個，兩地三中心，在同城建一個接近1：1的。從2005年開始，各個大型企業都在這么干，完全是1：1的，或者1：3的去建，兩地三中心就是1：3。

由于規模越來越大，一個數據中心扛不住企業的業務量，就像我說的，如果你算一個月幾百億筆交易，一個數據中心扛不住，樓都塞滿了，沒有地方放機器了，就需要多個數據中心。

數據中心面臨分散，浙江移動有6個數據中心，廣東移動有3個省的數據中心，然后再加每3個省的數據中心掛6-7個分數據中心，加起來一個省可能是二三十個數據中心，企業的業務橫跨所有的數據中心，每個數據中心都要承擔企業一部分的業務，這是企業面臨的挑戰。

企業的IT不能很自主設計IT架構的原因在于，傳統企業有自己的一套業務流程，這個業務流程最大的問題都涉及到閉環，甚至沒有一個人搞IT的，產生的問題是依賴。

互聯網企業，一個高并發，幾萬個應用，彼此之間沒有太強的依賴性。企業的數據中心里面的各個模塊之間，依賴性是非常強的，典型的是三層的，蜘蛛網式的，把蜘蛛網撐到多個數據中心，就有點麻煩了。容災或者業務持續性，或者故障發生的時候，要想到這個站點和業務其他業務系統的聯系。

企業建了大量的私有云，中國移動建十幾個基地，中國電信業建十幾個基地，原來在各個分省之間的業務系統，改用一個有規模效益的巨大的數據中心，將企業原來各個部門的IT資源和交易記錄全部搬過來，這時候就變成一個資源池了，承載的是各種各樣的業務系統，比如說IAAS，跟自己企業內部的數據中心又存在依賴的關系。

很多現在大型企業，受政策的影響，很多東西要往云上放，很多輕量級的應用，或者類似發布這樣的東西都往阿里云簽，阿里云還要和各個政府談，要把政務系統或者各種各樣的系統往阿里云上遷，企業要把其他的東西遷到阿里云上。而原有的數據中心，跟他們自己資源池的關系和公共云的關系，是很復雜的。

復雜的情況有幾點。

一是當業務出了問題以后，怎么檢查？你的選擇很多。我的模塊可能放在A數據中心，B數據中心，資源池還有一塊，它們三個組成一個業務組，業務出現問題了，檢查起來就很復雜了?，F在一個業務底下支撐可能有不同的支撐組管理，這個時候我要恢復它的時候就要靠流程驅動了，有的時候會造成很多麻煩，服務的檢查是很麻煩的。

第二個是風險。原來企業做容災或者考慮業務一致性的時候，首先有一個BCP的東西，這個跟IT沒有任何關系，是講企業依賴的東西受到危險的時候，哪些業務有風險，然后怎么滿足?？紤]最大的問題就是地震，數據沒了，怎么檢查它?，F在全部分散的話，有可能資源池出問題，業務受影響，公有云出問題受影響，自己的系統出問題業務受影響。這時候很難分析出來。

一個大型能源企業做了私有云以后，是兩地三中心加一個私有云的系統，會涉及到很多網絡或者什么樣的東西，大家仔細想一下，把遷到云以后會有什么樣的風險很難說，也不可能用以前很簡單的思路，覺得有風險就再建一套備用。

要分析私有云和公有云內部有什么風險，這個難度就太大了，因為這是分散的主體。

最大的問題是業務的可視性以及風險的分析和服務的檢查。

云計算和業務連續性，我個人認為有以下幾點值得注意。

一是基礎架構和數據。只要是支撐系統，數據遠比其他的東西更重要。數據是和消費對象發生交易，交易是唯一記錄，這就是數據如此之重要的也原因，因為它記錄著跟用戶發生的事情。

原來數據很簡單，存儲陣列維持業務的高可用，機器都宕了無所謂，因為有備份，有容災，數據復制了三份（同城復制一份，異地復制一份），通過種種方式集中起來，用比較簡單的方式做加工。但是現在虛擬化了，軟件定義了。

有用戶說，數據正在像癌癥一樣在整個數據中心擴散，原來是一個點，現在是無數個點，而且原來訪問數據是比較簡單的，就是讀盤?，F在訪問數據的方式不再是讀盤。企業在采購設備的時候，廠商把可靠性的故事說圓了就認為是可靠的。但是如果不可靠，該會怎么辦呢？不知道怎么辦。

在應用和業務的方面，面對開源和新型的應用，突然冒出上百種選擇，各種選擇有它的好處和缺點。

以前企業招標的時候，對需要采購的技術需要對應有一個標的，產品有很多功能，在市場上可以找到三四個差不多的供應商?，F在做高可用，或者做各種分析，對底層依賴不一樣，這最麻煩的事。

還有分布式的設計，分布式自稱是可以高可用的，但企業不是這么想這個事情的。如果系統不可用了怎么辦。企業想為什么要做容災，哪一天你這個東西不能用的時候怎么辦？容災本質上就是干這件事的。

分布式架構1200個節點，構成一個Hadoop的系統。分布式有分布式的好處，但是分布式其實是可靠性架構設計的災難。如果有一天不能用怎么辦？這是很嚴重的問題。

第三方面就是企業自己內部做Iaas，會發現Iaas本身沒有容災架構。原來做Oracle的時候可以做容災架構。IaaS各個模塊有容災能力，我選擇不同的IaaS來做的話，容災方案就不一樣了，模塊選擇不一樣，容災方案也不一樣。

另外，外部云，云的災備怎么辦？阿里云是國內做的最好的了，阿里云宕機怎么辦？相當于整個系統包給別人以后，變成一個黑盒子了，怎么把數據接回來？

我個人認為，技術的進步雖然帶來了挑戰，但是事實上也是一種提升，或者是一種機會。

原來的企業架構多么成熟，或者原來的容災架構多么簡單，多好設計，簡單帶來的問題是成本，的確有一個很成熟的可以遵循，但是如果全部做完以后，你發現你賺的錢全部給Oracle了，或者全部給IBM、EMC了。

最早的時候，江蘇移動做容災，容災最后總的數據量，印象中是實際生產數據量的7倍，這就是做傳統做法需要面臨的代價。很多企業做容災，針對薄弱環節做補充。有了云計算、有了IaaS這樣的東西，干的就是不停的封裝。原來的業務系統，可能完全是在磁盤陣列這塊，但是當有各種各樣的技術以后，可以在不同的層面進行封裝。建一個容災系統成本可能比以前更低，因為IT資源的成本，封裝的調度更加容易。所以只要能夠弄清楚商務和IT映射承載之間的關系弄清楚，的成本是很低的。

以前做容災，關注的都是各種各樣的復制、冗余，關注的是產品點的層面，在新的形式下做容災，要重新改變一下視角。從管理、協調，然后強調保護。最早的時候做容災，強調的就是保護。因為數據就放在那一個點上，所以只需要做好保護就可以了?，F在我們做容災還要做協調。

什么是業務連續性？業務連續性在傳統的形式下很簡單，將承載平臺再復制一遍，成本高。但很難把一個平臺再復制一遍。

第一保護層次，APP可能有多的級別，發生在不同的站點很復雜，基礎平臺保護也很很難，原來只是一臺主機，保護很簡單，最原始的保護是做一個冷備，這個機器出問題了就把那個機器提起來，也可以熱備也可以遠程的。

現在虛擬化的平臺，因為封裝層面不一樣，把它保護起來就用別的方法。但是可以看到原來的保護手段成本很高，新的保護手段，成本是原來的幾分之一，甚至十分之一。

傳統容災關注哪幾件事？第一，系統是不是可靠，以及構成它的基本元素，第二，跟系統相關的業務數據有沒有兩份或者多份。第三是我的性能怎么樣。

為了保證系統的可靠性，我們備份做數據，為了保證性能，我們預留50%的處理能力。

企業里大部分的主機運行超過60%就要報警，互聯網企業說超過90%不可能，一般就是30%，超過30%的壓力，系統管理員就坐不住了。

混合的情況下應該關注什么？面對傳統的要求，要有一個可預測的SLA，所謂的SLA無外乎就是接管以后的時間，數據丟失點以及性能，要靠自動化的機制，靠接口。原來沒有接口可言，靠工作流，對接是人對人的，有一套規范?；旌锨闆r下，數據中心有同城和異地。這時候需要的無外乎就是幾件事，一是IT能力或者IT基礎，將它封裝以后，需要有一個可預測，可以自動進行調動，最好簡單一點。

坦率來說，在混合云情況下保持業務連續性，還處在摸著石頭過河的階段。怎么做呢？面向服務。原來面向基礎架構自底向上?，F在的時代再想把它做的很可靠這件事不靠譜。事實上應用高可用的需求，或者實現高可用的功能，可以包裝成一種服務。在邏輯上對它進行封裝，強調虛擬化和云，是在物理上進行封裝，把其中的高可用或者高可靠抽出來，在邏輯上進行包裝。

第一用虛擬化的技術，虛擬化有一個資源調度的接口，可以封裝成回滾等，可以自動化的去做網絡。原來調度的時候是一個虛擬機，如果是一個業務的話，可以把它整個包起來，然后調度成一組虛擬機，底層數據上可以用陣列或者其他的復制手段，保證數據可用就行了，技術上是可以實現的。

企業還有自己的物理環境，傳統的是用cluster，cluster已經很成熟了，做一個封裝，把cluster封裝起來。cluster本身也有，可切回，cluster保證對應用的調度。在跨平臺的時候，你就要用service做成一個組，它的高可用涉及這個組里面的每個組建。通過調度的形式進行封裝，實現容災的基本功能。

接下來簡單介紹一下在這個思路下Veritas怎么做這件事。無外乎是虛擬化，跟cluster、磁盤陣列，做成組件進行封裝然后內部形成service，然后對它進行調度，做discover的發現。

針對虛擬機，我們有VBS的軟件，可以對多個層次的模塊合在一起進行切換。我們可以把云上承載的業務系統進行細分，在這個基礎上，可靠性就變成一種服務了。已有的基于地域和遠程異地各種各樣的復制。只要改變了這個思路，從業務的角度，或者從頂層的角度上，對它用封裝的形式來做，問題其實是可以解決的，至少是可以想明白的。

我們提出了VRA，這就是在混合環境下風險的分析問題，這是我們目前具備的能力，我們可以做數據的的驗證，做主機配置的驗證，做cluster的驗證等，幾乎所有業務涵蓋的IT環境。VRP可以通過API驅動，高函數可組合，是我們的系統架構。虛擬用可以用Hypervisor，也可以用物理陣列，兩邊有數據就可以了，上面進行封裝，保留內部高能耗，基本邏輯就在于封裝。

介紹一個成功案例。HP有公有云，我們跟HP合作，用戶有數據中心，我們在私有云上為用戶提供容災。

如果想在新的混合環境下建立一個面向業務連續性的云，一定要有面向服務的理念，建設高可用的系統。以前希望用簡單的模式來把IT系統做容災，在新的技術沖擊下，已經越來越難了，還是得通過面向業務、依賴服務的方式，通過服務的封裝，把高可用作為單獨的實現層次抽離出來。

這個過程是比較漫長的，但是前途還是比較光明的。謝謝大家！

（根據現場速記整理，未經本人審定）