DevOps 災難恢復計劃

一個設計良好的災難恢復計劃對於減少風險、迅速復原失敗並確保您的數據和基礎設施完整性至關重要。

DevOps 中與災難恢復相關的迷思有嗎？

一些組織仍錯誤地認為，DevOps 工具（如GitHub、GitLab、Bitbucket、Azure DevOps 或Jira）具有內建的全面災難恢復功能。然而，我們不應忘記共享責任模型，該模型明確澄清了提供者負責保護其基礎設施並順利運行其服務，而用戶必須保護自己的帳戶數據。

例如，讓我們看一下 Atlassian 安全實踐中的引言：

“對於 Bitbucket，數據被複製到不同的 AWS 區域，每個區域每天進行獨立備份。我們不使用這些備份來還原客戶發起的破壞性更改，例如使用腳本覆蓋的字段，或刪除的問題、專案或站點。為避免數據丟失，我們建議定期備份。”

您可能會在任何 SaaS 提供商的共享責任模型中找到相同的建議。在這個領域的錯誤可能導致嚴重的中斷，包括關鍵源代碼或元數據的數據丟失、聲譽損害和財務損失。

DevOps 生態系統獨特的挑戰

在為您的 DevOps 環境制定災難恢復計劃時，值得考慮 DevOps 在這方面面臨的挑戰。

DevOps 生態系統總是擁有複雜的架構，例如相互連接的流程和環境（例如 GitHub 和 Jira 整合）。因此，單一故障，無論是由於損壞的封裝件還是勒索軟體攻擊，都可能在整個系統中蔓延。

此外，DevOps 的快速發展帶來不斷變化，這可能在恢復過程中使數據一致性和完整性檢查變得更加複雜。

另一個問題是數據保留政策。SaaS 工具通常會強加限制的保留期限 – 通常從 30 天到 365 天不等。因此，例如，如果您意外刪除了存儲庫而沒有備份副本，您可能永遠丟失它。

為什麼災難恢復是 DevOps 的必要性

數據的關鍵性很重要，但這並不是組織開發和改進其災難恢復機制的唯一原因。有效的災難恢復計劃可以幫助組織：

• 減輕風險，因為服務中斷、網絡攻擊和意外刪除可能導致長時間的停機和數據丟失。

事实和统计: 2023年，影响GitHub用户的事件比2022年增长了超过21%。就GitLab而言，大约32%的事件被确认为影响了服务性能并影响了客户。（统计数据来自《DevOps威胁报告》）。

• 符合合规和监管要求 — 例如，ISO 20071、GDPR或NIS 2要求组织具有强大的数据保护和恢复机制。未能遵守可能会导致严重罚款和法律后果。

注意: 2024年12月，欧盟《网络安全弹性法案》生效。这意味着到2027年12月，在欧盟提供数字产品和服务并运营的组织应根据法律要求调整其数据保护和事件管理。

• 降低或消除停机成本，因为每一分钟系统不可用都会导致收入损失。平均停机成本可能超过每分钟9,000美元，这使得快速恢复至关重要。

建立强大的灾难恢复计划的最佳实践

您的灾难恢复计划预见任何可能的灾难场景并为您和团队提供应对故障事件的所有必要步骤是不是至关重要？让我们来了解有效DRP的组成部分…

评估所有关键组件

您應該確定最關鍵的 DevOps 資產。它們可能包括源代碼存儲庫、元數據、CI/CD 流水線、構建產物、配置管理文件等。您需要知道在發生故障時優先恢復哪些數據。

實施最佳備份實踐

沒有一個良好組織的備份策略是無法檢索數據的。因此，遵循最佳備份實踐是很重要的，以確保您可以在任何故障情況下恢復您的關鍵數據，包括服務中斷、基礎架構停機、勒索軟件攻擊、意外刪除等。

出於這個原因，您的備份解決方案應該讓您：

• 自動化您的備份，通過安排它們之間最合適的間隔時間來進行，以便在發生故障時不會丟失任何數據，
• 提供長期甚至無限的保留，這將幫助您從任何時間點恢復數據，
• 應用 3-2-1 備份規則，確保所有存儲之間的複製，以便在其中一個備份位置失效時，您可以從另一個位置運行備份，
• 勒索軟件保護，包括使用您自己的加密密鑰進行 AES 加密，不可變備份，恢復和 DR 能力（按時間點恢復，完整和粒度恢復，恢復到多個目的地，如本地機器、相同或新帳戶，或跨 GitHub、GitLab、Bitbucket 和 Azure DevOps 之間）。

定義您的恢復指標

對於組織來說，設定可測量的目標，如 RTO 或 RPO，是至關重要的。

• 恢復時間目標（RTO）是指公司系統在災害發生後應恢復運作的速度。例如，如果您的組織將其RTO設定為8小時，那麼在這8小時內，它應在災害事件後恢復正常工作流程。通常，組織設定的RTO越低，就越能應對失敗。
• 恢復點目標（RPO）顯示了以公司可以承受的時間來衡量的可接受數據損失。例如，如果公司可以輕鬆承受3小時的數據損失，那麼其RPO為3小時。您的RPO越低，組織應該有更頻繁的備份。

定期測試和驗證您的備份和恢復操作

通過定期測試恢復，您可以確保備份完整性，並放心在發生故障時快速檢索數據。

此外，值得模擬故障。這將幫助您的組織在模擬的中斷、勒索軟件攻擊或其他災害面前評估其災難恢復計劃的效力。

教育您的團隊

當災害發生時，恐慌是最糟糕的。因此，您團隊的每個成員都應該了解在這種情況下應該做什麼。設立負責執行恢復操作和負責通報災害的人員的職責和角色。

您的組織應該擁有為災難全面建立的通信計劃，該計劃規定了通信策略和負責通知利益相關者和其他可能受影響方的人員，以及此類通信的範本。

DRP在DevOps中的案例研究

讓我們來看看災害恢復計劃如何幫助避免災害帶來的毀滅性後果：

服務中斷

一家大型數字公司完全依賴GitHub（也可能是其他服務提供商，如GitLab、Atlassian或Azure DevOps）。突然間，公司意識到服務提供商正在遭遇中斷…然而，公司需要盡快繼續運營 — 別忘了平均停機成本為每分鐘9,000美元。

通過完善的DRP，組織從最新備份拷貝中恢復數據，使用時間點還原，到GitLab（或Bitbuket或Azure DevOps）。因此，組織快速恢復運營，消除數據損失，確保最小化停機時間。

提示：在這種情況下，您的備份解決方案還應允許您將數據還原到本地機器，以便盡快恢復業務連續性。

人為錯誤 vs. 基礎設施停機

一位開發人員推送了不正確的數據，並意外覆蓋了關鍵文件。整個情況使公司的工作流程癱瘓並導致停機。

希望組織的DRP預見到這種情況，遵循3-2-1備份規則。因此，公司的IT團隊從另一個存儲運行備份，以確保業務連續性。

勒索軟件攻擊

一家中型軟件公司面臨勒索軟件攻擊，加密其主要的 Git 存儲庫。通過實施了高效的災難恢復計劃（DRP），具有自動備份和防勒索軟件功能（例如不可變備份），該公司成功從其數據未受損的時間點恢復了數據。

結果如何？公司在幾小時內恢復了運營，避免了數百萬美元的贖金要求，並將停機時間降到最低。

要點

災難恢復計劃對於組織現在是一個戰略性必需品。除了保護數據外，它還幫助組織確保合規性，建立客戶信任並降低財務風險。

備份策略應該成為任何災難恢復計劃的全面基礎，即使是最苛刻的計劃也是如此。因此，您應該能夠：

• 設置備份策略，使最苛刻的恢復時間目標（RTO）和恢復點目標（RPO）內的備份過程自動化，
• 將數據保存在多個位置，符合3-2-1備份規則，
• 具有安全的防勒索軟件保護機制，
• 通過數據驅動的儀表板、Slack/email 通知、SLA、合規性報告等監控備份性能，
• 進行測試還原，
• 在任何故障事件中恢復數據，因為該解決方案預見了任何災難恢復方案並提供了強大的還原能力，包括完整數據恢復、細粒度還原、按時間點還原、還原到同一個或新帳戶、還原到您的本地實例，以及
• 確保合規性和網絡韌性。