發生嚴重故障時的復原策略

  • 災難復原必須與業務連續性結合,為每個關鍵系統定義復原時間目標 (RTO) 和復原點目標 (RPO)。
  • 有效的災難復原計畫 (DRP) 結合了預先準備好的架構、強大的備份、自動化和明確的團隊角色。
  • 雲端技術、資料複製和定期演練有助於在發生嚴重故障時減少停機時間和資料遺失。

發生嚴重故障時的復原策略

當我們談論災難復原策略時,我們實際上指的是比簡單備份更廣泛的內容:我們指的是公司在一切崩潰時維持營運的真正能力。資料中心火災、勒索軟體加密所有伺服器、大規模網路中斷或長時間斷電,如果沒有周密且經過測試的計劃,都可能導致企業徹底癱瘓。

好消息是,如今我們擁有成熟的方法、框架和技術(包括本地部署、雲端和混合部署),可以建立穩健的災難復原計畫 (DRP) 和業務連續性計畫 (BCP)。關鍵在於積極主動:提前記錄要做什麼、由誰來做、使用什麼工具以及在什麼時間範圍內完成,而不是在危機發生時暫時應對。在接下來的章節中,您將全面且實用地了解設計、實施和維護真正有效的災難復原策略所需的一切,而不僅僅是一份「走過場」的文件。

業務連續性與災難復原:如何整合各個環節

在深入探討各種計劃和技術之前,區分兩個經常被混淆的概念至關重要:業務連續性計劃 (BCP) 和災難復原計劃 (DRP)。業務連續性計畫定義了組織如何在重大事件發生期間和之後維持其關鍵功能;而災難復原計畫則著重於如何復原支援這些功能的 IT 基礎架構和資料。

業務連續性涉及流程、人員、地點和供應商。它包括諸如總部無法使用時員工在哪裡辦公、必須立即維持哪些最低限度的服務以及如何優先保障關鍵客戶的服務等決策。另一方面,災難復原計畫 (DRP) 則著重於伺服器、網路、資料庫、雲端系統、備份和技術復原流程。

這兩個計劃必須相輔相成:如果沒有完善的災難復原計劃 (DRP),業務連續性計劃 (BCP) 就無法發揮作用,因為系統不可用時,業務流程將無法執行;但同時,即使製定了完美的 DRP,如果忽略了對營運的影響,也無法解決問題。理想情況下,這兩個計劃應該協同設計,共享業務影響分析 (BIA)、復原時間目標 (RTO) 和風險感知目標 (RPO)。

此外,業務連續性和災難復原計畫 (DRP) 與公司的整體風險管理一致:它們有助於減少財務損失、避免監管處罰、保護聲譽,並最終確保組織在面對嚴重危機時能夠生存下去。

什麼是災難復原計畫 (DRP)?為什麼它是不可協商的?

災難復原計畫是一份正式、結構化且可操作的文件,它定義了組織在技術系統嚴重中斷時應如何應對。它不僅僅是一份美好的願望清單,而是一套詳細的流程、聯絡人、職責和資源,用於在可接受的時間範圍內恢復服務和資料。

有效的災難復原計畫 (DRP) 會明確哪些系統至關重要,以及如何保護、備份和重建這些系統,以應對全部或部分故障。這包括從啟用備用資料中心或輔助雲端區域到使用快照、持續資料複製、資料庫復原以及有序啟動虛擬機器和應用程式等所有環節。

其主要目標是最大限度地減少停機時間和資料遺失,並在整個過程中維護資訊的完整性和安全性。而且,非常重要的是,它還涵蓋組織方面:誰宣布災難發生,誰協調技術回應,誰與客戶、媒體或當局溝通,以及如何記錄決策。

在日益數位化的環境中,依賴單一資料中心或缺乏冗餘的系統無異於玩火。任何組織都無法完全避免硬體故障、人為失誤、網路攻擊或極端自然災害。制定並實施最新且經過測試的災難復原計畫 (DRP) 已不再是可選項,而是策略性要求,不僅關乎韌性、合規性,也關乎與客戶和合作夥伴建立信任。

威脅企業的主要技術災難類型

要製定有效的嚴重故障復原策略,首先要從最簡單的事情開始:了解哪些環節可能故障以及故障原因。科技災難的範圍很廣,從純粹的實體事故到複雜的網路攻擊,再到可能造成巨大後果的簡單人為錯誤,都屬於此類。

最常見的災難類型包括硬體故障:伺服器過熱燒毀、儲存陣列停止回應以及路由器或防火牆突然失效。如果磁碟遺失或損壞而沒有足夠的備份,關鍵系統可能會癱瘓數小時甚至數天。

另一個方面是軟體問題:測試不充分的更新導致業務應用程式崩潰、作業系統版本與企業軟體不相容、導致資料損壞的漏洞,或導致進程凍結和阻止交易。

我們不能忽視網路攻擊這個類別:勒索軟體會加密所有檔案和資料庫,網路釣魚活動會竊取特權存取憑證,DDoS 攻擊會癱瘓網路連接,入侵會竊取敏感訊息,或是內部破壞活動。在這些情況下,除了恢復之外,還需要透過攻擊模擬器來遏制、調查和加強安全防護。

人為錯誤仍然是事故的持續來源:意外刪除資料庫、配置變更錯誤、將關鍵資訊傳送給錯誤的接收者,或無意中停用安全措施。

最後,網路中斷和資料中心災難也會造成影響:例如,網路服務供應商長時間斷網、電力故障且沒有足夠的UPS系統、火災、洪水,或本地或雲端服務供應商的設施遭受物理損壞。任何此類事件都可能導致關鍵應用程式或本地與雲端之間分散式業務資料無法存取。

災難復原策略的關鍵組成部分

一個完善的恢復策略不僅僅是說「我們做備份」。它必須涵蓋從風險評估到測試和培訓、IT架構、團隊組織以及內部和外部溝通的方方面面。

首先要進行全面的風險評估和業務影響分析 (BIA)。這包括識別與組織相關的威脅、分析漏洞(技術、物理和組織層面),並計算每次系統故障對營運、財務和聲譽的影響。此流程將得出每項服務的復原時間目標 (RTO) 和復原點目標 (RPO)。

基於此,制定了業務連續性計劃,概述了在常用資源不可用時如何維持關鍵功能的運作。這可能包括啟用備用辦公地點、廣泛開展遠端辦公、與外部供應商達成協議、臨時流程變更或有控制地降低非關鍵服務的等級。

另一個關鍵要素是資料備份和復原策略:備份哪些資料、備份到哪裡、備份頻率、備份時長以及使用哪些技術(完整備份、增量備份、差異備份、快照、熱複製等)。此外,還必須考慮恢復到特定時間點,以撤銷因資料損壞或攻擊造成的損害。

該策略還包括一個結構完善的溝通計劃(誰通知誰以及透過哪個管道通知),一個定期測試和演練的計劃,以驗證一切在壓力下都能正常運作,以及一個培訓和意識提升方案,以便團隊知道在緊急情況下該怎麼做。

全面業務連續性和災難復原計畫的五個主要組成部分

現代業務連續性方法通常圍繞著五個相互協調的主要計劃來建構。每個計劃涵蓋應對嚴重故障的不同方面,它們共同構成一個連貫的行動框架。

首先是業務連續性計劃,它概述了在發生重大中斷後恢復「正常」營運的步驟。這包括損失評估、系統和資料復原、流程優先排序、服務等級驗證以及正式的事件結束。

第二項是應急計劃,重點在於事件發生時的立即反應:保護人員、啟動疏散協議、與緊急服務部門聯繫、保護有形資產以及進行基本協調,直到局勢穩定。

第三點是業務連續性計劃,它定義了在危機持續時間較長的情況下如何維持關鍵職能。這包括備用辦公地點(熱備、中備和冷備地點)、遠端辦公、減少但充足的IT資源、重新分配角色以及與供應商制定緊急應變計畫。

第四部分是事件管理計劃,其中概述了任何相關事件的檢測、分類、升級和後續行動。它定義了危機小組的角色、宣布災難的標準、「作戰室」的使用、溝通管道以及決策的記錄方式。

最後,災難復原計畫重點關注技術方面:重建基礎設施、啟動副本、復原資料以及驗證資訊和安全控制措施是否完好無損。各種災難復原模式(本地部署、雲端部署、虛擬化、災難復原即服務等)都在此階段得到應用。

災難復原類型和成熟度級別

組織可以結合多種技術來保護自己免受災害影響。從最基本的措施到幾乎不間斷的環境,存在著一系列策略和不同程度的韌性。

核心在於簡單的資料備份:建立副本並將其儲存在其他媒體或位置。這固然重要,但還不夠,因為它不包含快速恢復服務所需的必要基礎設施。除了這種基本方法之外,還有諸如災難復原即服務 (DRaaS)之類的解決方案,在這種方案中,雲端供應商會複製並託管實體和虛擬伺服器,並透過合約(服務等級協議,SLA)承諾在災難發生時啟動這些伺服器。

快照可讓您擷取系統或資料磁碟區在特定時間點的狀態。它們對於在資料損壞或意外變更後恢復到先前的狀態非常有用,但其有效性取決於快照的建立頻率以及它們是否儲存在未受事件影響的位置。

虛擬復原將 IT 基礎架構複製到外部虛擬機器(本地或雲端)。發生災難時,這些虛擬機器可以快速部署到生產環境。然而,這需要頻繁的複製、足夠的頻寬以及對副本的持續管理。

從經典的災難復原框架來看,我們可以從0級(無異地資料或計畫)到7級(高度自動化、以業務為中心的復原)。中間層級包括手動備份、自動備份、電子保險庫、大量使用快照、交易完整性(在金融環境中至關重要),以及在6級和7級時,實現近乎即時的資料複製,最大限度地減少或避免資料遺失,並實現幾乎完全自動化的故障轉移流程。

選擇合適的等級並非技術上的隨意之舉,而是需要在成本、風險和業務需求之間取得平衡。銀行或醫院哪怕幾分鐘的停機或資料不一致都無法承受,而中小企業則可以容忍幾個小時的停機和部分近期資料的遺失,前提是避免停機的成本遠低於遺失資料的成本。

架構設計與故障轉移模式

發生嚴重故障時的復原策略

技術架構必須從一開始就設計成便於復原的,僅僅在專案後期添加災難復原功能是不夠的。必須選擇與復原時間目標/復原點目標以及可用預算相符的主動-被動和多區域部署模式。

在冷備用配置中,備用區域或站點僅部署最少的基礎設施,直到災難發生才會啟用。這種配置成本低廉,但故障轉移速度較慢,因為幾乎所有東西都需要同時部署。

在熱備模式下,備用區域部署的資源以較低的容量運行,從而實現更快的故障轉移。在雙活模式下,兩個區域共同處理流量並分擔負載,最大限度地提高可用性,但會增加資料一致性的複雜性並提高成本。

此外,明確定義資訊複製方式至關重要:同步複製(零資料遺失,但站點間延遲較高)或非同步複製(資料遺失有限,但延遲較低)。典型的做法是在同一區域或可用區內使用同步複製,在地理位置相距較遠的區域之間使用非同步複製。

備用區域的全面設計必須包含必要的運算層、網路拓撲(虛擬網路、子網路、路由、防火牆、安全群組)、複製的身份和存取服務、監控和警告系統,以及所有應用程式和資料元件。網路或安全基礎設施不能在危機期間臨時搭建;所有組件都必須預先配置和測試。

在概念上,將故障轉移(將工作負載遷移到備份區域)與故障復原(在主區域復原後返回主區域)區分開來至關重要。這是兩個不同的過程,風險也不同,兩者都應盡可能地進行文件記錄和自動化。

資料中心的備份、復原時間目標 (RTO)、復原點目標 (RPO) 和具體策略

任何災難復原計畫 (DRP) 的核心都在於如何管理備份以及如何應用復原時間目標 (RTO) 和復原點目標 (RPO)指標。如果沒有這些目標,就無法判斷備份策略是否充分。

恢復時間目標 (RTO) 表示系統在不造成不可接受的損害的情況下可以停機多久。恢復點目標 (RPO) 表示可以容忍的資料遺失量(以分鐘、小時或天為單位)。高容量計費應用程式可能需要幾分鐘的 RPO 和不到一小時的 RTO,而內部報告系統可能允許每天的 RPO 和幾個小時的 RTO。

在專有資料中心中,災難復原計畫必須特別詳細:全面的資產清單(硬體、軟體、許可證、依賴項)、影響分析、實體風險(火災、洪水、電力故障)和邏輯風險(網路攻擊、配置錯誤)評估、實體冗餘(UPS、發電機、雙重冷卻、冗餘網路連結)和邏輯冗餘(重複的伺服器和邏輯服務、主動-主動-被動-被動-被動-站點)和邏輯裝置、主動-主動的伺服器和邏輯服務、

備份管理必須明確規定備份類型(完整備份、增量備份、差異備份)、備份視窗、備份位置(本地、異地、雲端、冷儲存)、磁碟加密、保留期限、存取策略和完整性驗證程序。如果十年來的備份都未經測試且無法及時恢復,那麼即使擁有十年的備份也毫無用處。

此外,還需要製定針對資料中心事件的具體溝通計畫(通知託管客戶、與能源或電信供應商協調、回報管理階層),確保事件期間和事件後安全的機制(呼吸隔離、恢復存取控制、驗證復原的資料是否被篡改),以及明確的演練和稽核計畫。

災難復原計畫復原與治理團隊組織

災難復原計畫 (DRP) 並非自動運作。它需要一個職責明確、協調管道暢通的團隊。根據組織規模的不同,團隊成員的專業程度也會有所不同,但有些角色是共通的。

大型企業通常會設立首席資訊安全長 (CISO),負責網路安全策略,並在事件復原中發揮核心作用,包括推廣多因素身份驗證。 IT 安全團隊通常圍繞 CISO 運作,負責監控網路和系統、偵測入侵、協調事件回應,並在災難發生時提供關鍵資訊。

系統和網路管理員了解基礎設施的技術細節:伺服器、儲存、通訊、VPN、防火牆、目錄服務等等。沒有他們,在故障轉移期間恢復複雜服務或診斷瓶頸將非常困難。

許多組織也擁有IT 營運和技術支援團隊,雖然這些團隊不總是負責管理安全,但在故障排除、使用者支援、工單管理以及復原期間執行重複性技術任務方面至關重要。

風險管理和合規性方面的資料非常豐富,有助於確保災難復原和業務連續性策略符合行業(金融、醫療、公共管理等)的監管要求,並符合保險單或與客戶的合約協議。

此外,在具有外部影響的危機中,溝通和公共關係領域至關重要:它負責向客戶、合作夥伴、媒體和當局傳達一致的訊息,避免矛盾和洩密,從而加劇聲譽損害。

最後,許多公司會任命一名專門的業務連續性經理(BCP 經理),負責協調各種計劃,確保這些計劃得到測試、更新並融入日常運營,並在演習和實際危機期間作為參考點。

流程、自動化與模擬:從理論到實踐

一個非常常見的誤解是認為僅僅編寫計劃就足夠了。事實上,災難復原計畫 (DRP) 只有在真實環境下進行測試、盡可能自動化並保持有效運作的情況下才能發揮作用。否則,一旦災難來臨,要不是沒人知道該怎麼做,就是流程已經過時。

流程編寫應確保任何受過訓練的操作人員即使在壓力下也能遵循。建議按層級建立流程:元件級步驟(例如,還原特定資料庫)、資料資產級步驟(相關係統集)和工作負載級步驟(具有多個相依性的完整應用程式)。流程還應包含在入侵事件發生後檢查帳戶是否已被盜用的操作。

自動化是一項強大的助力:用於部署基礎設施的聲明式和冪等腳本、在所有區域都已就緒的 CI/CD 管線、能夠執行帶有重試邏輯和熔斷器的任務序列的編排器、PaaS 或 IaaS 服務的自動故障轉移等等。當然,這一切始終都在人工監督之下,並在風險必要時設定人工審批環節。

演練應成為組織日常工作的一部分。將桌面演練(對場景和角色進行理論回顧)、非生產環境中的技術測試(在無風險的情況下檢測流程缺陷)以及在成熟度允許的情況下精心策劃的生產演練結合起來,有助於驗證在實際場景中是否能夠滿足恢復時間目標 (RTO) 和恢復點目標 (RPO)。

每次演練都應總結經驗教訓:審查文件、調整程序、改進自動化流程,並為提出疑問的員工提供額外培訓。最終目標是使災害應變成為近乎常規的流程,無需臨時應對。

持續更新、可存取性和雲端使用,以加強災難復原

系統、威脅以及組織本身都在快速變化。因此,恢復計劃必須被視為一份動態文件。如果三年前完善的復原計劃,在那時一半的基礎設施已經遷移到雲端、新增了SaaS應用或關鍵流程發生了變化,那麼該計劃就毫無用處了。

建議至少每六個月審查一次災難復原計畫 (DRP),或在發生重大變更(例如遷移項目、新增業務線、重大監管變更、嚴重事故)後進行審查。每次審查都應包括對啟動標準、程序、責任方以及必要時對恢復時間目標 (RTO)/恢復點目標 (RPO) 本身進行調整。

在系統中斷期間,恢復計劃和工具的可訪問性至關重要。執行災難復原所需的文件、腳本、憑證和憑證應儲存在高可用性位置,並在不同區域進行複製,同時也應備有離線副本甚至列印副本,以應對無法存取正常系統的極端情況。

最後,雲端已成為許多災難復原策略的核心組成部分:從多區域儲存備份到完整的災難復原即服務 (DRaaS),再到將虛擬機器和資料庫複製到輔助區域。與完全本地部署的備份基礎架構相比,這些服務顯著降低了成本和複雜性,同時也能隨著業務需求的成長而擴展。

當所有這些結合起來——嚴謹的影響分析、預先準備好的架構、清晰的計劃、明確的角色、智能自動化、頻繁的模擬以及對雲的戰略性使用——組織就能從祈禱好運轉變為真正有能力應對嚴重的故障,保護其數據、聲譽,以及最重要的,即使在最糟糕的情況下也能繼續運營的能力。

用於建立備份的軟體
相關文章:
備份軟體:能夠應對真正故障的解決方案

在 Google 中將其新增為首選來源