想象一下：您正在为一家大型购物中心的 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 已经准备就绪。
来源： habr.com