BCP的最簡(jiǎn)說(shuō)就是“什么都是兩份”。但你研究越深，它就越難:兩個(gè)服務(wù)器，兩個(gè)交換機，兩個(gè)上行線(xiàn)路，兩個(gè)配電裝置，兩個(gè)路由器，兩個(gè)完全獨立的、觸及全部信息點(diǎn)的網(wǎng)絡(luò )平面?當然兩套設備間的失效轉移必須完全自動(dòng)化的，因為人的響應時(shí)間以互聯(lián)網(wǎng)的速度來(lái)衡量是極度緩慢的。當你開(kāi)始加入越來(lái)越多的冗余和越來(lái)越多的自動(dòng)化的時(shí)候，復雜度也就上升了。到某一點(diǎn)上，系統是如此的復雜，以至于你只能放棄加入更多的故障點(diǎn)。隨著(zhù)系統向上擴展，收益逐漸減少，最終將到達這樣的點(diǎn)，你的投資收益變成負值。



該問(wèn)題的答案可以在宏觀(guān)層面上找到。你需有計劃應對可能影響區域服務(wù)的災難一一地震、限風(fēng)，等等。因此你需要把服務(wù)布署在分開(kāi)的地理區域中。至關(guān)重要的是:當下次大地震毀掉硅谷的數據中心時(shí)，必須有自動(dòng)的方式將你的流量切換到東部海岸。一旦你解決了這個(gè)問(wèn)題，所有的小事情都變得不重要了。如果一個(gè)數據中心的配電裝置、路由器或交換機失效，你的流量將自動(dòng)地轉移到其他的大都市。很明顯，為了防止流量在不同的地方來(lái)回折騰，某種程度的本地冗余是需要的，但你不需要將之進(jìn)行到收益減少或者負收益的程度。

與人們的普遍看法相反，數據中心的確會(huì )有故障，有時(shí)原因很古怪。有一天我在參加一個(gè)會(huì )議時(shí)，接到運維中心的電話(huà)，通知我說(shuō):一個(gè)主要的數據中心運行中斷。擔心在我們處理問(wèn)題時(shí)，這個(gè)事事件會(huì )段掉我的會(huì )議，我立即打電話(huà)給我的同事了解影響的程度。使我放心的是:她告知，所有網(wǎng)站都已轉出那個(gè)地點(diǎn)，流量已轉移到另外的數據中心，她正期待著(zhù)“烤松鼠”的晚餐，原因是一個(gè)壞蛋爬進(jìn)了配電箱，咬穿了主要的配電電纜。松鼠沒(méi)能活過(guò)那天，不過(guò)我們安然無(wú)恙地度過(guò)了那一天。

正如前面提到的，BCP對于不同的人有許多不同的含義。讓我們看一下這些術(shù)語(yǔ)以及它們對你的站點(diǎn)而言意味著(zhù)什么。開(kāi)始時(shí)，我先去掉該術(shù)語(yǔ)的一大部分一一人員和地點(diǎn)。管理員工是一個(gè)完整BCP計劃的重要組成部分。如果你的辦公大樓燒毀了，所有的人到哪里工作?我是一個(gè)工程師，那不是我的領(lǐng)域，所以我將集中于BCP計劃的高可用性部分:保證站點(diǎn)正常工作。即使在高可用性領(lǐng)域，也有各種各樣的技術(shù)，從熱/熱(Hot/Hot)、熱暖(Hot/Warn)、熱冷(Hot/Cold)到災難恢復。

熱/熱(Hot/Hot)是高可用性的最高級別。用戶(hù)可以從任意的數據中心使用全部的應用程序。讀和寫(xiě)可以發(fā)生在任何地方。這讓自動(dòng)的故障轉移變得非常簡(jiǎn)單，但它不是萬(wàn)能的。
 
你必須認真思考如何處理數據一致性的問(wèn)題。如果一個(gè)數據同時(shí)寫(xiě)入兩個(gè)地點(diǎn)，在復制過(guò)程中將出現沖突。哪個(gè)寫(xiě)入是正確的?互聯(lián)網(wǎng)是非常動(dòng)態(tài)的媒介，在很多情況下這并不要緊，不過(guò)應確保你有所計劃。

熱/暖(Hot/Warm)是一種很好的方式，如果你不能容忍數據的不一致性的話(huà)。很多應用有大量的讀操作，僅偶爾(但很重要)寫(xiě)一下。在這種情況下，區別處理這兩種操作是有意義的。讀操作使用熱熱的方式，可由任何數據中心提供，具有快速自動(dòng)的故障轉移，這使大部分應用具有很高的可靠性。但一次只寫(xiě)入一個(gè)數據中心，這保證了數據的一致性，代價(jià)是一小部分應用的故障轉移會(huì )慢一些。假設可以降低網(wǎng)站性能的話(huà)，就不用同步數據復制。在2寫(xiě)操作發(fā)生時(shí)，盡最大努力將數據盡快傳到其他地點(diǎn)，但沒(méi)有擔保。復制延遲可能是幾秒、幾分鐘到幾小時(shí)不等。因此，當在一個(gè)地點(diǎn)進(jìn)行寫(xiě)操作而緊跟著(zhù)在另一地點(diǎn)進(jìn)行讀取時(shí)，會(huì )發(fā)生什么呢?更新可能還沒(méi)到達，你會(huì )得到過(guò)期的數據。我們稱(chēng)之為臨界讀(critical reads)。你需要識別，以及通過(guò)錯誤處理或將讀操作引至源站點(diǎn)，來(lái)減少臨界讀。

熱/冷(1 Hot/Cold)讓我害怕。這種架構將讀寫(xiě)流量送到單一地點(diǎn)，而讓另一個(gè)相同的部署在遙遠的地平線(xiàn)上閑置。它容易建立，但價(jià)值很低。當災難襲來(lái)時(shí)，你就會(huì )質(zhì)疑計劃是否明智。它真的行得通嗎?軟件版本是最新的嗎?最后一次登錄到這個(gè)冷站點(diǎn)是什么時(shí)候?情況往往是，這個(gè)冷站點(diǎn)會(huì )被閑置不用一年或更長(cháng)的時(shí)間。當你需要時(shí)，它可能已遺憾地過(guò)時(shí)了。擔心、不確定和懷疑都不可避免地會(huì )延長(cháng)宕機時(shí)間。我見(jiàn)過(guò)無(wú)數次的事故，其冷情況下你不能使用冷站點(diǎn)，其意義何在? 
 
站點(diǎn)是如此不可信，以至于我們寧愿有幾小時(shí)的宕機時(shí)間，也不用故障轉移。如果在緊急災難恢復是最差的技術(shù)，本質(zhì)上是霧件(vaporware)。它的本意不是在平常的時(shí)候保護你，而是在大的災難發(fā)生時(shí)給你提供重建的選項。我們收購的一家公司有災難恢復計劃，它每月需要向第三方公司付“保險”費，該第三方公司維護了一個(gè)大型的數據中心，里面充滿(mǎn)了閑置的服務(wù)器和存儲設備。如果我們們的數據中心發(fā)生故障，我們可以用他們的。當然，如果有大的災難，我們就會(huì )和他們的其他所有客戶(hù)競爭資源。并沒(méi)有實(shí)際的計劃，也沒(méi)有做過(guò)任何測試。在開(kāi)始探索實(shí)際的故障轉移會(huì )怎么樣的時(shí)候，我們發(fā)現了一些令人驚駭的問(wèn)題。結果是服務(wù)器和存儲有各自不同部門(mén)，網(wǎng)站建設服務(wù)器群在一棟樓，而存儲在另一棟。兩棟樓之間有一根千兆以太線(xiàn)路連接，這明顯不能工作。在我們決定自己干時(shí)，他們允諾再建第二條千兆的以太線(xiàn)路。