想像一下：您正在為一家大型購物中心的 IT 基礎架構提供服務。城裡開始下雨了。傾盆大雨衝破屋頂，零售店內積水齊腳踝。我們希望您的機房不要在地下室，否則問題無法避免。
所描述的故事不是幻想，而是2020年幾件事的集體描述。在大公司中，針對這種情況總是準備有災難復原計畫 (DRP)。在公司中，這是業務連續性專家的職責。但對於中小型企業來說，解決這類問題就落在了IT服務的肩上。您需要自己了解業務邏輯，了解什麼可能會失敗以及在哪裡失敗，提出保護並實施它。
如果 IT 專家能夠與企業進行協商並討論保護需求，那就太好了。但我不只一次看到一家公司如何吝惜災難復原 (DR) 解決方案，因為它認為它是多餘的。當事故發生時，漫長的恢復期可能會造成損失，而企業還沒有做好準備。你可以隨心所欲地重複：“我告訴過你了”，但 IT 服務仍然必須恢復服務。
我從架構師的角度來告訴大家該如何避免這種情況。在文章的第一部分，我將展示準備工作：如何與客戶討論選擇安全工具的三個問題：
- 我們在保護什麼？
- 我們要防範什麼？
- 我們保護多少？
在第二部分中，我們將討論回答這個問題的選項：如何保護自己。我將舉例說明不同客戶如何建立保護。
我們保護什麼：識別關鍵業務功能
最好透過與業務客戶討論緊急情況後的行動計劃來開始準備。這裡的主要困難是找到共同語言。客戶通常不關心 IT 解決方案如何運作。他關心的是該服務能否履行業務功能並帶來收入。例如：如果網站正常運行，但支付系統癱瘓，客戶沒有收入，「極端分子」仍然是IT專家。
IT 專業人員在此類談判中可能會遇到困難，原因如下：
- IT服務並沒有完全理解資訊系統在業務中的作用。例如，如果沒有可用的業務流程描述或透明的業務模型。
- 並非整個流程都依賴 IT 服務。例如，當部分工作由承包商執行時，IT 專家對他們沒有直接影響。
我會這樣建構對話：
- 我們向企業解釋，事故每個人都會發生，恢復需要時間。最好的方法是展示具體情況、這種情況是如何發生的以及可能產生的後果。
- 我們表明，並非一切都取決於 IT 服務，但您已準備好在您的職責範圍內協助制定行動計劃。
- 我們請業務客戶回答：如果末日發生，應該先恢復哪個流程？誰參與以及如何參與？
企業需要一個簡單的答案，例如：呼叫中心需要24/7繼續註冊應用程式。
- 我們要求一兩個系統使用者詳細描述這個過程。
如果您的公司有分析師，最好聘請分析師來提供協助。首先，描述可能如下所示：呼叫中心透過電話、郵件和網站訊息接收請求。然後他透過網路介面將它們輸入 1C，生產以這種方式將它們從那裡獲取。
- 然後我們看看有哪些硬體和軟體解決方案支援該過程。為了實現全面保護，我們考慮三個層面：
- 站點內的應用程式和系統（軟體層級），
- 系統運作的站點本身（基礎設施層級），
- 網路（他們經常忘記它）。
- 我們找出可能的故障點：服務效能所依賴的系統節點。我們單獨註明其他公司支援的節點：電信業者、託管供應商、資料中心等。這樣，您就可以返回業務客戶進行下一步。
我們防範什麼：風險
接下來，我們從商業客戶那裡了解我們首先要保護自己免受哪些風險。所有風險可分為兩類：
- 因服務停機而造成的時間損失；
- 因物理影響、人為因素等造成的資料遺失。
企業擔心丟失資料和時間 - 所有這些都會導致金錢損失。因此，我們再次針對每個風險組提出問題：
- 對於這個過程，我們能否估算一下資料遺失和時間損失的成本是多少？
- 哪些資料是我們不能遺失的？
- 哪些地方不能允許停機？
- 哪些事件最有可能發生，對我們威脅最大？
經過討論，我們將了解如何對故障點進行優先排序。
我們保護多少：RPO 和 RTO
當關鍵故障點明確後，我們計算RTO和RPO指標。
我記得， RTO（復原時間目標） ——這是從事故發生到服務完全恢復的允許時間。用商業語言來說，這是可以接受的停機時間。如果我們知道這個過程帶來了多少錢，我們就可以計算出每分鐘停機的損失，並計算出可接受的損失。
RPO（復原點目標） — 有效的資料復原點。它決定了我們可能丟失資料的時間。例如，從商業角度來看，資料遺失可能會導致罰款。這種損失也可以轉化為金錢。
需要為最終用戶計算恢復時間：他能夠登入系統多長時間。因此，我們首先將鏈中所有環節的恢復時間相加。這裡經常犯一個錯誤：他們從 SLA 中獲取提供者的 RTO，而忘記了其餘條款。
我們來看一個具體的例子。使用者登入 1C，系統開啟時出現資料庫錯誤。他聯絡系統管理員。資料庫位於雲端，系統管理員將問題報告給服務提供者。假設所有通信需要 15 分鐘。在雲端中，這種規模的資料庫將在一個小時內從備份中恢復，因此服務提供者端的RTO是一個小時。但這並不是最終期限；對使用者來說，還增加了 15 分鐘來檢測問題。
接下來，系統管理員需要檢查資料庫是否正確，將其連接到1C並啟動服務。這還需要一個小時，這意味著管理員這邊的RTO已經是2小時15分鐘了。用戶還需要 15 分鐘：登錄，檢查必要的交易是否已出現。本例的總服務恢復時間為2小時30分鐘。
這些計算將向企業顯示恢復期取決於哪些外部因素。例如，如果辦公室被水淹沒，您首先需要找到洩漏點並進行修復。這需要時間，不取決於 IT。
我們如何保護：針對不同風險選擇工具
討論完所有要點後，客戶已經了解了事故為企業帶來的成本。現在您可以選擇工具並討論預算。透過客戶案例的範例，我將向您展示我們為不同任務提供的工具。
讓我們從第一組風險開始：服務停機造成的損失。此問題的解決方案應該提供良好的 RTO。
- 在雲端中託管應用程式
首先，您可以簡單地遷移到雲端 - 提供者已經考慮了高可用性問題。虛擬化主機組裝成集群，預留電源和網絡，資料儲存在容錯儲存系統上，服務提供者對停機時間承擔經濟責任。
例如，您可以在雲端中託管具有資料庫的虛擬機器。應用程式將透過已建立的通道或從同一雲端從外部連接到資料庫。如果叢集中的一台伺服器出現問題，虛擬機器將在不到 2 分鐘的時間內在相鄰伺服器上重新啟動。之後，DBMS 將在其中啟動，幾分鐘後資料庫將變得可用。
RTO: 以分鐘為單位。這些條款可以在與提供者的協議中指定。
成本：我們計算您的應用程式的雲端資源成本。
它不能保護您免受什麼侵害：例如，由於城市層級的事故，導致提供者站點發生大規模故障。 - 叢集應用程式
如果你想提高RTO，你可以加強先前的選項，立即將叢集應用程式放置在雲端。
您可以採用主動-被動或主動-主動模式實現叢集。我們根據供應商的要求建立多個虛擬機器。為了提高可靠性，我們將它們分散在不同的伺服器和儲存系統上。如果其中一個資料庫的伺服器發生故障，備份節點會在幾秒鐘內接管負載。
RTO：以秒為單位。
成本：比普通雲稍微貴一點，叢集需要額外的資源。
它不能保護您免受什麼侵害：仍然無法防止大規模現場故障。但局部幹擾不會持續那麼久。來自實踐：零售公司擁有多個資訊系統和網站。所有資料庫均位於公司本地辦公室。直到辦公室連續幾次斷電後才考慮災難復原。客戶對網站崩潰感到不滿。
上雲後解決了服務可用性的問題。此外，我們還透過平衡節點之間的流量來優化資料庫的負載。 - 遷移到防災雲
如果你需要確保即使主站點發生自然災害也不會影響你的工作，你可以選擇抗災雲，在這個選項中，供應商將虛擬化叢集分佈在2個資料中心。資料中心之間發生持續的同步複製，一對一。資料中心之間的通道是預留的，走不同的路線，這樣的叢集就不怕網路問題。
RTO: 趨於0。
成本：最昂貴的雲端選項。
它不能保護您免受什麼侵害：對於防止資料損壞以及人為因素沒有幫助，所以建議同時進行備份。來自實踐：我們的一位客戶制定了全面的災難復原計畫。這是他選擇的策略：
- 容災雲可以保護應用程式免受基礎架構層級的故障影響。
- 兩級備份可在出現人為錯誤時提供保護。有兩種類型的備份：「冷」和「熱」。 「冷」備份處於停用狀態，需要時間部署。 「熱」備份已經可供使用，且復原速度更快。它儲存在專門的儲存系統上。第三個副本錄製在磁帶上並存放在另一個房間。
客戶每週一次測試保護並檢查所有備份（包括磁帶備份）的功能。該公司每年都會測試整個抗災雲。
- 組織複製到另一個站點
如何避免主站點出現全域問題的另一種選擇：提供地理預訂。換句話說，在另一個城市的網站建立備份虛擬機器。災難復原的特殊解決方案適合於此：在我們公司，我們使用 VMware vCloud Availability (vCAV)。借助它的幫助，您可以在多個雲端提供者網站之間配置保護或從本機網站還原到雲端。我已經更詳細地討論了使用 vCAV 的方案 .
RPO 和 RTO: 5 分鐘起。
成本：比第一個選項更昂貴，但比防災雲端中的硬體複製便宜。價格包括 vCAV 授權成本、管理費、雲端資源成本以及根據 PAYG 模型保留資源（關閉虛擬機器的工作資源成本的 10%）。
來自實踐：客戶在莫斯科的雲端保留了 6 個具有不同資料庫的虛擬機器。起初，保護是透過備份提供的：一些備份副本儲存在莫斯科的雲端中，有些則儲存在我們的聖彼得堡站點上。隨著時間的推移，資料庫的大小不斷增大，從備份還原開始需要更多的時間。
備份中新增了基於 VMware vCloud Availability 的複製。虛擬機器的副本儲存在聖彼得堡的備份站點上，每 5 分鐘更新一次。如果主站點發生故障，員工可以獨立切換到聖彼得堡的虛擬機器副本並繼續使用它進行工作。
所有考慮的解決方案都提供高可用性，但不能防止因勒索軟體病毒或員工意外錯誤而導致的資料遺失。在這種情況下，我們需要能夠提供所需 RPO 的備份。
5.不要忘記備份
每個人都知道您需要備份，即使您擁有最酷的防災解決方案。所以我就簡單提醒大家幾點。
嚴格來說，備份並不是災難復原。這就是為什麼：
- 很久了。如果資料以 TB 為單位，復原將需要一個多小時。您需要恢復、分配網路、檢查它是否開啟、查看資料是否正常。因此，只有在數據很少的情況下，您才能提供良好的 RTO。
- 第一次可能無法恢復數據，您需要留出時間重複該操作。例如，有時我們無法確切知道資料何時遺失。假設在 15.00 點發現遺失，並且每小時製作一份副本。從 15.00:14 開始，我們查看所有恢復點：00:13、00:XNUMX 等。如果系統很重要，我們會盡量縮短恢復點的壽命。但如果新備份不包含必要的數據，我們就採取下一點 - 這是額外的時間。
在這種情況下，備份計劃可以提供所需的 RPO。對於備份來說，在主站點出現問題時提供地理保留非常重要。建議單獨儲存一些備份副本。
最終的災難復原計畫應至少包含 2 個工具：
- 選項 1-4 之一，它將保護系統免受故障和跌落的影響。
- 備份以防止資料遺失。
也值得注意備用通訊管道，以防主要網路供應商故障。而且 - 瞧！ — 最低工資 DR 已經準備就緒。
來源： www.habr.com