既然如此，我們就拿出一些我們親身經歷的實際案例，當做小白鼠與大家分享，希望能夠對大家研究規劃和管理自己的容災系統有所幫助。這個案例從很多角度看并不算一個特別完美的宣傳樣板，但是正因如此，才更具有實際的代表性，更有分享的價值。
特別要聲明，為了避免不必要的麻煩，本文隱去當事人和單位名稱，除此以外，完全真實。
“案情”
今年4月21日，14:00左右，一家列入世界500強的大型國企，業務部門反映人力資源系統無法辦理業務。IT部門馬上開始故障排查，發現故障原因是由于誤刪除導致了數據庫故障，導致相關系統無法運行。數據庫容量約1.4TB。于是17:30左右開始啟動災難恢復機制。
17:30：首先，IT主管決定提取了上午10點的歷史時間點快照進行數據驗證。結論是數據庫可以正常啟動。于是開始向主存儲上恢復數據。
20:30左右：數據恢復完成。
21:00：啟動數據庫，數據庫可以正常啟動。然后應用廠商調試相關的應用軟件。
23:30：應用廠商驗證數據時，發現數據庫有一個表的索引仍然存在問題，需要手動對索引進行調整。調整所需要的時間很難確定，為了減少恢復時間，IT主管決定重新提取CDP快照數據，改為提取上午9:00的快照。
0:00左右：驗證了9點快照數據庫可以啟動。
0:00-1:45：對9:00的快照進行驗證，驗證結果正常。
凌晨2:00左右：快照數據恢復到主存儲。數據庫正常運行，業務系統恢復運行，系統恢復完成。
這是一個通過容災系統成功恢復數據的典型場景。由于人為錯誤導致的停機，通過CDP進行恢復，首次恢復時的時間點選擇不對，但是直到恢復之后才發現，于是選擇了更早的時間點終于恢復成功。整個系統停機時間約12個小時。
分析
下面我們對這個案例的一些特別值得關注的細節進行一下分析：
- 故障原因：不明的人為操作導致的數據庫崩潰。人們總是過分相信自己，而對機器這樣冷冰冰的東西充滿不信任。而實際上，我們經歷的至少三分之二的災難是由人為操作導致的。誤刪除、惡意攻擊、或者一次失敗的程序更新，等等。相比而言，硬件故障、火災、地震、恐怖襲擊發生的概率，要小得多。而不明的人為操作是最常見而且最棘手的災難。這樣看來，現在國內大量的容災項目以雙活或者多活為基礎，就是個錯誤了。所有的錯誤操作，都會同時復制到遠端。雙活就是雙死，多活就是多死。不論有多少災備站點，有一個算一個，要死大家一起死。雙活面對本案例中的這個場景，完全束手無策，只有CDP才能解決；
- 容災的第一步：故障定位。并不是所有的災難都會出故障時馬上崩潰。特別是人為故障更是如此。甚至于，很可能首先發現故障的系統并不是故障的本源，而只是表征。這時候，定位故障原因是第一位的，而不是迅速由容災端接管。否則，災難不能解決，反而往往會擴大。本案例中就是如此，下午2點發現故障，但上午10點時系統就已經不正常了。IT部門用了約三個半小時定位了故障點，在現實中，這個速度不算慢了。如果應用系統相互依賴關系錯綜復雜，很有可能需要更長的時間才能定位。
- 自動化與人工：容災離不開人工。容災預案的啟動，需要很多人工判斷的決策，這是不能簡單地交給容災系統自動完成的。很多容災廠商都向客戶描述一個如同科幻電影般的理想場景，仿佛出現災難后，只需要按下一個“災難恢復”的紅色按鈕，自動化機制就會去處理，遠端容災系統一接管，就一切修復了。甚至于有的用戶會希望連那個按鈕都沒有，系統應該可以自動判斷系統故障，然后啟動接管過程。也許對于一個簡單的硬盤故障，這種自動化方法還可行，但是對于如今無比復雜的企業級IT系統，災難恢復這么重大的事件，自動化的價值是十分有限的，人工的決策是必需的，甚至是決定性的。
- RTO和RPO（恢復時間和恢復點）: 我們認為，RTO和RPO為零只是一個理想，特別是面對人為錯誤。所有的容災系統都在追求RTO和RPO的最小化，一直趨近于零，也就是要在瞬間恢復到系統故障前那個狀態。這是一個特別理想化的目標。任何容災系統，也不可能保證在任何情況下，都能把系統瞬間恢復到那個狀態。說到這里，可能大家發現，硬件故障，不論多么嚴重的硬件故障，即使是機房整個被炸掉，反倒都是比較容易解決的場景了，因為這種情況有一個很明確的故障點，我們只要恢復到那個時間點之前的狀態，一定可以正常運行。而人為操作導致的崩潰，故障的時間點是未知的。這時候，容災的決策實際上是在RTO和RPO之間進行取舍：是犧牲更多的停機時間來找到更近的恢復點；還是快速找到一個肯定可用的恢復點馬上恢復系統，從而減少停機時間？怎樣選擇，都沒有完美的答案。在本案例中，如果一開始就決策采用9點的快照，可能可以減少好幾個小時的停機時間，但是這都是馬后炮，決策的時候，你怎么可能事先知道呢？實際上如果IT部門從13點的快照開始逐個驗證，可能要花多得多的時間才能輪到驗證9點這個快照。在這個案例中，總停機時間約12小時，恢復點在上午9點，IT部門已經通過自己的經驗和判斷大大縮減停機時間了。
- 數據驗證的重要性。在這個案例里，我們發現停機的絕大部分時間都是用來進行驗證。系統是2點鐘發現故障的，但是上午10點時數據庫就已經不正常了。IT團隊花了兩個多小時驗證10點的快照，但是這個錯誤還很難發現，因為用10點的快照，數據庫是可以啟動的，只是有一個表不正常。恢復和比對分析需要大量的時間，而且是完全必要的。我們試想一下，如果沒有進行驗證，就把10點的快照恢復完直接上線，會發生什么情況。剛一開始系統可以運行，大家都松了一口氣以為大功告成，然而幾個小時后系統再次崩潰。這時候IT團隊所面臨的壓力要比前一次故障時大得多，因為系統的總停機時間已經超過10個小時，而一切都要重新開始。而他還能對自己的經驗和判斷有信心嗎？
這個案例雖然不是如同產品演示一樣完美，停機時間也比較長，但是就當時的條件和具體情況而言，算是一次成功的災難恢復。試想如果同樣的災難發生在那些把希望寄托在雙活和異地容災上的用戶，很有可能根本無法恢復系統運行；如果使用磁帶庫和備份軟件恢復，可能要花多得多的時間才能把1.4TB的數據庫恢復到更早的一個時間點。相比之下，在此案例中，因為采用了CDP，每次實際數據恢復的時間只有15分鐘左右。也正因為用戶把CDP的快照頻率設為一小時，才有可能相對較快地恢復到相對較近的時間點。雖然IT沒能一開始就準確決策應該采用哪個快照，但是發現問題后迅速調整，有效減少了停機時間。因此，我們覺得，這是一次成功的案例，而且遇到了很多典型的困難，特別值得拿出來和大家分享。希望大家能夠從中有所收獲。
京公網安備 11010502049343號