让它成为洪水吧，但1C应该可以！我们与有关DR的业务进行谈判

想象一下：您正在为大型购物中心的IT基础架构服务。倾盆大雨始于城市。雨水穿过屋顶，水注满了脚踝深处的零售空间。我们希望您的服务器机房不在地下室，否则问题将不可避免。  



所描述的故事不是幻想，而是对2020年几次事件的集体描述。在大型公司中，对于这种情况总是要有灾难恢复计划（DRP）。在公司中，业务连续性专家对此负责。但是在中小型公司中，解决此类问题的方法取决于IT部门。您需要自己了解业务逻辑，了解可能会跌到什么地方，提出保护和实施措施。 



如果IT专业人员设法与企业进行谈判并讨论保护的必要性，那就太好了。但是我已经反复观察了该公司如何在灾难恢复（DR）解决方案上进行节省，因为它认为这是多余的。事故发生时，漫长的恢复可能会造成损失，企业还没有准备就绪。您可以重复任意多次：“但我告诉过您”-IT服务仍必须还原服务。







从架构师的角度，我将告诉您如何避免这种情况。在本文的第一部分中，我将展示准备工作：如何与客户讨论选择保护工具的三个问题： 

• 我们保护什么？
  
  
• 我们要保护什么？
  
  
• 我们保护有多强？ 
  
  

在第二部分中，我们将讨论回答这个问题的选项：要捍卫什么。我将举例说明不同客户如何建立保护的情况。

我们的保护：阐明关键业务功能 

最好通过与业务客户讨论灾难计划来开始进行准备。这里的主要困难是找到一种通用语言。客户通常不关心IT解决方案的工作方式。他关心该服务是否可以执行业务功能并赚钱。例如：如果站点正在运行，并且支付系统处于“撒谎”状态，则没有客户收据，而“极端”收据仍是IT专家。 



IT专业人员可能由于以下几个原因而难以进行谈判：

• IT服务没有完全意识到信息系统在业务中的作用。例如，如果没有可用的业务流程描述或透明的业务模型。 
  
  
• 并非整个过程都取决于IT部门。例如，当某些工作由承包商完成时，IT专家对此没有直接影响。
  
  

我将这样构造对话： 

1. 我们向企业解释，每个人都会发生事故，恢复需要时间。最好的办法是演示情况，如何发生以及可能发生的后果。
   
   
2. 我们表明并非所有内容都取决于IT服务，但是您准备好在您负责的领域内制定行动计划。
   
   
3. 我们要求商业客户回答：如果发生天启，应该首先恢复哪个过程？谁参加，如何参加？ 
   
   
   
   业务需要一个简单的答案，例如：呼叫中心有必要继续24/7全天候注册应用程序。
   
   
4. - . 
   
   , .
   
   
   
   : - , . 1 -, .
   
   
5. , . : 
   
   
   • ( ),   
     
     
   • , ( ), 
     
     
   • ( ).
   
   
   
6. 我们找出可能的故障点：服务性能所依赖的系统节点。另外，我们标记其他公司支持的节点：电信运营商，托管提供商，数据中心等。这样，您可以返回到业务客户进行下一步。
   
   

我们保护的是：风险

然后，我们首先从商业客户中找出我们要防范的风险。我们将有条件地将所有风险分为两类： 

• 因服务中断而浪费时间；
  
  
• 由于物理影响，人为因素等导致数据丢失
  
  

企业害怕丢失数据和时间-所有这些都会导致金钱损失。因此，我们再次询问有关每个风险组的问题： 

• 我们能为这个过程估计多少数据丢失和浪费的时间值得吗？ 
  
  
• 我们不会丢失什么数据？ 
  
  
• 我们在哪里不能允许停机？ 
  
  
• 哪些事件最有可能对我们构成威胁？
  
  

经过讨论，我们将了解如何确定故障点的优先级。 

我们保护的程度：RPO和RTO 

了解故障的关键点后，我们将计算RTO和RPO指标。 



让我提醒您，RTO（恢复时间目标）是从事故发生到完全恢复服务的允许时间。用业务术语来说，这是可以接受的停机时间。如果我们知道流程带来了多少钱，那么我们可以计算停机时间的每分钟损失，并计算可允许的损失。 



RPO（恢复点目标）是有效的数据恢复点。它决定了我们丢失数据的时间。从业务角度来看，数据丢失可能会导致例如罚款。这种损失也可以转化为金钱。 







应该为最终用户计算恢复时间：登录系统将花费多长时间。因此，首先我们添加链中所有链接的恢复时间。在这里，他们经常会犯一个错误：他们从SLA中选择了RTO提供者，而忘记了其他条款。

让我们看一个具体的例子。用户输入1C，系统打开并显示数据库错误。他联系系统管理员。基地在云中，系统管理员将问题报告给服务提供商。假设所有通讯都需要15分钟。在云中，将在一个小时内从备份还原此大小的数据库，因此，服务提供商方面的RTO（一个小时）。但这不是最后的截止日期，因为向用户添加了15分钟来检测问题。 

 

接下来，系统管理员需要检查数据库是否正确，将其连接到1C并启动服务。这需要另外一个小时，这意味着管理员方面的RTO已经是2小时15分钟。用户还需要15分钟：登录，检查是否已出现必要的事务。在此示例中，2小时30分钟是该服务的总恢复时间。

这些计算将显示业务恢复期取决于哪些外部因素。例如，如果办公室被水淹没，那么首先您需要检测并修复泄漏。这将需要不依赖IT的时间。  

我们的保护方式：选择应对不同风险的工具

在讨论了所有要点之后，客户已经了解了企业的事故成本。现在，您可以选择工具并讨论预算。我将以客户案例为例展示我们为不同任务提供的工具。 



让我们从第一类风险开始：服务停机造成的损失。此任务的解决方案应提供良好的RTO。

1.  
   
   
   
   — . , , , - .
   
   
   
   , . . , 2 . , .
   
   
   
   RTO: . .
   
   : . 
   
   : , , - .
   
   
2.   
   
   
   
   RTO, .
   
   
   
   active-passive active-active. , . . , .
   
   
   
   RTO: .
   
   : , .
   
   : - . .
   
   

   : - . . DR , . . 
   
    
   
   . .

3. 
   
   
   
   , ,   2 -. - , --. , . 
   
   
   
   RTO: 0.
   
   : . 
   
   : , , . 
   
   

   : . : 
   
   
   
   

   • . 
     
     
   • . : «» «». «» , . «» . . . 
     
     

   
   
   , . . 

4.  
   
   
   
   , : . , . DR: VMware vCloud Availability (vCAV). on-premise . vCAV . 
   
   
   
   RPO RTO: 5 . 
   
   
   
   : , , . vCAV, , PAYG (10% ).
   
   

   : 6 . : , — . , . 
   
    
   
   VMware vCloud Availability. - 5 . , - . 

所有经过考虑的解决方案都可提供高可用性，但不会使您免于由于加密病毒或员工意外错误而导致的数据丢失。在这种情况下，我们需要提供所需RPO的备份。



5.不要忘记备份



即使拥有最酷的灾难恢复解决方案，每个人都知道您需要进行备份。因此，我将简要回顾一下几点。



严格来说，备份不是灾难恢复。这就是为什么： 

• 这需要很长时间。如果数据以太字节为单位，则恢复将花费一个多小时。您需要还原，分配网络，检查电源是否打开，数据是否正确。因此，只有很少的数据，您才能获得良好的RTO。 
  
  
• 第一次可能无法恢复数据，因此您需要预留时间进行第二次操作。例如，有时我们不知道确切的数据丢失时间。假设损失是在15.00时发现的，每小时复制一次。从15.00开始，我们观察所有恢复点：14：00、13：00，依此类推。如果系统很关键，我们将尽量减少还原点的寿命。但是，如果在新备份中未找到必要的数据，那么我们要讲第二点-这是额外的时间。 
  
  

话虽如此，备份计划可以提供所需的RPO。对于备份，重要的是在主站点出现问题时提供地理冗余。建议单独保存一些备份。



最终的灾难恢复计划应至少具有两个工具：  

• 选项1-4之一，它将保护系统免于崩溃和崩溃。
  
  
• 备份以防止数据丢失。 
  
  

如果主要的Internet提供商崩溃，也值得考虑使用备用通信信道。瞧！-最低工资的DR已准备就绪。