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加密、不可变备份、恢复和灾难恢复功能（按时间点恢复、完整和细粒度恢复、恢复到多个目的地，如本地计算机、相同或新账户，或在GitHub、GitLab、Bitbucket和Azure DevOps之间跨越恢复）。

定义您的恢复度量标准

对于一个组织来说，设定可衡量的目标，如RTO或RPO，是至关重要的。

• 恢复时间目标（RTO）指的是灾难发生后您公司系统应该多快恢复运行。例如，如果您的组织将其RTO设定为8小时，那么在这8小时内，它应该在灾难事件后恢复正常工作流程。通常，组织设定的RTO越低，就越能够应对失败。
• 恢复点目标（RPO）显示了可以容忍的数据丢失量，以时间来衡量公司可以承受的时间。例如，如果公司可以轻松承受3小时的数据丢失，那么它的RPO就是3小时。您的RPO越低，您的组织应该有更频繁的备份。

定期测试和验证您的备份和恢复操作

通过定期测试恢复，您可以确保备份的完整性，并安心地知道在发生故障时，您可以快速检索数据。

此外，值得模拟故障。这将帮助您的组织评估其在面对模拟故障、勒索软件攻击或其他灾难时的灾难恢复计划有效性。

教育您的团队

当灾难发生时，恐慌是最糟糕的。因此，您团队的每个成员都应了解在这种情况下应该做什么。确定恢复操作应由谁执行，以及谁应该就灾难进行沟通的责任和角色。

您的组织应该拥有一个精心制定的灾难通信计划，其中规定了沟通策略、负责通知利益相关者和其他可能受影响方的人员，以及此类通信的模板。

DevOps中DRP的案例研究

让我们看一下DRP如何帮助避免灾难性后果的案例研究：

服务中断

一家大型数字公司完全依赖GitHub（也可能是其他服务提供商，如GitLab、Atlassian或Azure DevOps）。突然，公司意识到服务提供商正在发生中断…然而，公司需要尽快恢复运营 — 别忘了停机的平均成本是每分钟9,000美元。

通过全面的DRP，组织从最新的备份副本中恢复数据，使用点对点还原，到GitLab（或Bitbuket或Azure DevOps）。因此，组织快速恢复运营，消除数据丢失，并确保最小停机时间。

提示：在这种情况下，您的备份解决方案还应允许您将数据恢复到本地计算机，以尽快恢复业务连续性。

人为错误 vs. 基础设施停机

开发人员推送了不正确的数据并意外覆盖了关键文件。整个情况瘫痪了公司的工作流程，并导致停机。

希望组织的DRP预见到这种情况，遵循3-2-1备份规则。因此，公司的IT团队从另一个存储运行备份，以确保业务连续性。

勒索软件攻击

一家中等规模的软件公司面临着一场勒索软件攻击，加密了其主要的 Git 存储库。通过实施了高效的灾难恢复计划（DRP），并具备自动化备份和防勒索软件功能，比如不可变备份，该公司设法从数据未被损坏的时间点恢复其数据。

结果呢？该公司在几小时内恢复了其运营，避免了要求支付数百万美元的赎金以及最大程度地减少了停机时间。

要点

如今，灾难恢复计划对于组织来说是战略性必需品。除了保护数据，它还帮助组织确保合规性、建立客户信任并降低财务风险。

备份策略应成为任何灾难恢复计划的全面基础，即使是最苛刻的计划。因此，您应该能够：

• 建立备份策略，自动化备份过程以符合最苛刻的恢复时间目标和恢复点目标，
• 在多个位置保存数据，符合 3-2-1 备份规则，
• 拥有安全的防勒索软件保护机制，
• 监控备份性能，通过数据驱动的仪表板、Slack/email 通知、SLA、合规报告等，
• 进行测试恢复，
• 在任何故障事件中恢复数据，因为解决方案考虑了各种灾难情景并提供强大的恢复功能，包括完整数据恢复、细粒度恢复、按时间点恢复、恢复到相同或新账户、恢复到您的本地实例，以及
• 确保合规性和网络安全弹性。