作為一家社區銀行的災難恢復和信息安全負責人，James Hinks對災難恢復有一些心得。他帶領的團隊正在為伊利諾伊州的First Mid銀行信托公司(First Mid Bank&Trust)提高災難恢復基礎設施的自動化程度，并將整合更多的云計算服務。
Hinks說，“我們是一家社區銀行，因此必須為客戶著想。這需要很高的服務水平協議(SLA)，并且在發生災難事件的情況下，我們必須提供更加安全的災難恢復設置。”
為了繼續提供客戶期望的服務水平，Hinks帶領的團隊推動銀行災難恢復方法的現代化是有意義的。對大多數企業來說，這并不是應該重新審視災難恢復計劃和技術的問題，而是時間的問題。
標準普爾全球分公司451 Research公司的高級分析師Steven Hill表示：“隨著混合技術的應用，企業IT的發展比以往任何時候都快，而且災難恢復計劃過時的時間實際上并不需要很長時間。系統、應用程序、人員總是在不斷變化，因此制定一個良好的計劃需要不斷反映這些變化，并進行調整以滿足數據治理和行業合規性不斷發展的需求。”
對于大多數企業來說，自從他們建立了原始的災難恢復計劃和技術以來，可能已經發生了很多變化。首先，虛擬化和云計算時代已將中斷的容忍度降低到幾乎為零。根據Forrester Research公司和Disaster Recovery Journal公司最近的一項研究，提高災難恢復能力的主要原因是保持基礎設施全天候在線運營。
另一個重要因素是從關注組件故障到關注服務連續性的轉變。與傳統的災難恢復方法不同，當今災難恢復方法要求每個組件都具有備份和恢復功能，而更多的是企業要了解關鍵業務服務。
德勤會計師事務所總經理兼技術彈性實踐部門的負責人Pete Renneker說：“企業需要了解這些服務的依賴性，才能確定其是否在整個過程中提供了適當的彈性水平。例如，企業是否需要證明能夠滿足50個應用程序的4小時恢復時間目標(RTO)，還是更重要的是選擇一個關鍵業務流程并在其中提高恢復能力?”
Renneker還指出，網絡安全在災難恢復中的重要性與日俱增。雖然傳統的災難恢復側重于最大限度地提高系統、應用程序和數據的可用性，但在高度復制和冗余的環境中存在惡意軟件可能會導致真正的問題。
多年來，人們一直認為，如果有適當的災難恢復設置，則應該能夠從網絡事件中恢復。企業的運營環境越關鍵，就越有可能將主動復制用作其主要恢復功能。反過來，這意味著事件將對運營環境造成更大的負面影響。
Renneker說：“企業一直將災難恢復視為只是可用性的挑戰，但是我們看到基于完整性的事件可以使備份功能成為攻擊武器，并最終使系統癱瘓。”
情況越來越糟，而不是好轉
應對這些新的情況(例如對宕機時間容忍度很低和網絡威脅增加)需要一種新的方法。通過從場景規劃的角度考慮技術彈性，企業將能夠更好地根據風險和影響確定優先級。而關注最壞的情況對于不同的企業來說，這些可能會有所不同。
Renneker說，“企業最關心的場景是什么?當前的程序如何使人們對災難恢復更有信心?如果不能從專注于單一場景的傳統程序轉變為提供始終在線體驗的完全冗余的彈性網絡，那么需要考慮如何改變流程和程序。”
例如，如果大多數具有高影響力的方案都圍繞著網絡威脅，則可以考慮將網絡恢復功能引入災難恢復基礎設施中。這種技術通常將關鍵數據存儲在一個獨立的安全存儲庫中，該存儲庫以不可變形式處于脫機狀態，并受到監視和掃描，以查找數據的任何潛在更改。Renneker解釋說，盡管惡意軟件仍然有可能進入環境，但這種類型的“網絡保險庫”即使在惡意軟件提供有效載荷的情況下也可以防止竊取數據或遭到破壞。
一旦災難事件結束，并且災難恢復團隊了解其運營環境中引入了什么內容，團隊就可以訪問保險庫，將數據清理到經過正常狀態，然后恢復生產。
對于當今的許多企業而言，更加緊迫的情況可能集中在當前冠狀病毒疫情所引起的在家工作模式上。例如，許多企業已經轉向虛擬桌面基礎設施(VDI)之類的技術，以使員工能夠在家中工作。如果這對企業來說是新技術，那么這些虛擬桌面基礎設施(VDI)設置可能會帶來風險。如果虛擬桌面基礎設施(VDI)實例成為單點故障，則虛擬桌面基礎設施(VDI)出現故障或遭受服務器攻擊時，將會導致企業的員工無法工作。
Forrester公司基礎設施和運營高級分析師Naveen Chhabra表示，這些事情使得審查現有的業務和IT風險比以往任何時候都更加重要。每次對其進行審核時，都必須對災難恢復功能進行修訂，以符合新的風險或現有風險的形式和方式的變化。
Hinks對此表示認同，并認為管理災難恢復本質上是技術風險管理。他說，“我有一個計劃，在這個計劃中，我們有‘X’美元來降低風險，以實現企業的內部服務等級協議(SLA)、恢復點目標RPO()和恢復時間目標(RTO)。”
對于最重要的場景進行規劃，同樣重要的是使災難恢復和生產環境保持同步。Chhabra指出，大多數企業都無法做到這一點。
他解釋說：“假設企業更新了Oracle部署。在通常情況下，看到這些更改僅應用于主站點，而不是災難恢復站點。這可能是失敗的原因，因為除非源站點和目標站點同步，否則即使恢復成功，災難恢復也需要更長的時間。”
Chhabra建議說，“企業在每次進行重大更改時都進行同步，而不是在月末使其運營環境同步。而不匹配一直是問題的根源。”
在這些情況下，自動化可以發揮很大作用。在最基本的級別上，混合云的固有自動化功能可以真正提高災難響應能力和對策略的遵守。混合云方法還可以支持編排。最新一代的云原生應用程序和工具通常旨在支持自動化，并提供可跨越許多云計算服務的基于策略的通用管理。
最后，自動化是測試的重要組成部分，而某些企業根本做不到。根據一份調查報告，27%的企業每年測試一次災難恢復計劃或不到一次。
頻繁測試的好處
對于First Mid銀行信托公司來說，測試至關重要。Hinks說：“我們非常重視災難恢復測試，我們認為這應該像預定的任務一樣運行，每個月或每季度都要運行不同的場景。如果企業的災難恢復測試成功率達到100%，則說明沒有進行足夠的測試，或者沒有在足夠多的場景進行測試。”
考慮到企業經歷的變化，頻繁的測試比以往任何時候都重要。Chhabra說：“每次在源環境中進行重大更改時，都必須規劃更新恢復站點，然后再進行測試。假設企業要從VMware 6.2升級到6.5。當規劃一個運行手冊時，該手冊會考慮較早的版本，由于VMware在其最新版本中實現了某些功能的方式，該版本現在可能已過時。這使得驗證至關重要。”
與頻繁測試一樣重要，確保測試正確的東西也很重要。傳統上，企業一直專注于測試應用程序、服務器、存儲陣列等。如今，從組件級測試轉向測試應用程序之間的相互依賴性更有意義。
Renneker建議說：“朝著生態系統的測試邁進，也許可以從測試網絡轉移到具有多種場景的實時網絡測試。”
最后，企業重新評估參與災難恢復規劃和執行的人員。只專注于IT或只專注于業務方面都是一個很大的錯誤。例如，企業可能具有不再受支持但對其環境仍然至關重要的現有應用程序或基礎設施。這是一種風險，需要規劃與該風險相對應的災難恢復功能。如果企業尚未為原有應用程序或基礎設施計劃遷移或恢復基礎設施，則不會使災難恢復投資適應業務或IT風險。Chhabra指出，如果企業的恢復能力與該風險不符，則可能是投資過多或投資不足。
版權聲明：本文為企業網D1Net編譯，轉載需注明出處為：企業網D1Net，如果不注明出處，企業網D1Net將保留追究其法律責任的權利。
京公網安備 11010502049343號