即使在灾难期间，也总是有时间喝一杯
DRP（灾难恢复计划）茶-理想情况下永远不需要。但是，如果在交配季节突然迁移的海狸through绕在主干纤维上，或者初级管理员降低了生产能力，那么您绝对要确保您有一个应对所有这些混乱情况的预先制定的计划。
当客户惊慌地开始切断他们的技术支持电话时，大三学生正在寻找氰化物，您明智地打开红色信封，开始将所有物品整理好。
在这篇文章中，我想分享有关如何编写DRP及其应包含的内容的建议。我们还将研究以下内容：
- 让我们学会像小人一样思考。
- 让我们看看启示录期间喝杯茶的好处。
- 我们将考虑一个方便的DRP结构
- 让我们看看如何测试它。
对于哪些公司可能有用
当IT部门开始需要这些东西时，很难划清界限。我要说的是，在以下情况下，您可以保证需要DRP：
- 停止服务器，应用程序或某些基础的丢失将导致整个企业的重大损失。
- 您拥有完善的IT部门。从部门的角度来看，这是公司的正式部门，拥有自己的预算，而不仅仅是一些疲倦的员工铺设网络，清理病毒和为打印机加油。
- 您有一个实际的预算，可以在紧急情况下至少部分地冗余。
当IT部门花了几个月的时间为至少一台旧服务器请求几个HDD进行备份时，您不太可能组织一次完整的故障服务转移以保留容量。尽管这里的文档不是多余的。
文档很重要
从文档开始。假设您的服务基于Perl脚本，该脚本是三代管理员之前编写的，而且没人知道它是如何工作的。不断累积的技术债务和缺乏文档记录将不可避免地使您不仅膝盖受伤，而且四肢受伤，这只是时间问题。
一旦您对服务组件有了很好的描述，就可以打开崩溃统计信息。它们几乎肯定是完全典型的。例如，您的磁盘有时会装满，这会导致在手动清除节点之前发生节点故障。否则，由于有人再次忘记续订证书，客户端服务变得不可用，而“让我们加密”无法或不希望配置它。
像破坏者一样的想法
最难的部分是预测以前从未发生过的事故，但是这些事故可能会完全破坏您的服务。在这里，我们通常与同事扮演反派。喝杯咖啡和一些美味的东西，然后将自己锁在会议室中。只需确保在同一会议室中将那些自己提出目标服务或定期使用目标服务的工程师锁在了门上即可。然后，无论是在板上还是在纸上，您都可以画出可能对您的服务造成的所有恐怖影响。不必详细介绍特定的清洁器并拔出电缆，只需考虑“破坏本地网络的完整性”方案即可。
通常，最典型的紧急情况属于以下几种类型：
- 网络故障
- 操作系统服务失败
- 应用失败
- 铁故障
- 虚拟化失败
只需浏览每个视图，看看适用于您的服务的内容。例如，Nginx守护程序可能崩溃而不会上升-这是操作系统方面的故障。导致Web应用程序无法使用的罕见情况是软件故障。在此阶段进行工作时，对问题进行诊断很重要。例如，如何区分虚拟化中挂起的接口与崩溃的tsiska和网络崩溃。重要的是要迅速找到肇事者，并拖着尾巴直到事故解决。
写下典型问题后，我们会倒一些咖啡，并开始考虑一些参数超出标准的最奇怪的情况。例如：
- 如果活动节点上的时间相对于群集中的其他时间退后一分钟会怎样？
- 如果时间在向前发展，又是在10年后呢？
- 如果群集节点在同步期间突然失去网络，会发生什么？
- 如果两个节点由于网络之间的临时隔离而无法共享领导权，将会发生什么？
在此阶段，反向方法很有帮助。您想像的是团队中最顽固的成员，想像力不足，然后在最短的时间内给他任务以安排破坏活动，从而破坏服务。如果难以诊断，那就更好了。如果您给工程师一个打破常规的想法，您将不会相信他们会想到什么奇怪而又酷的想法。如果您已经向他们保证可以为此提供测试平台，那就太好了。
您的DRP是多少？
因此，您已经定义了威胁模型。还考虑了切断光纤以寻找铜的当地人，以及严格在星期五下午4:46掉落无线电中继线的军用雷达。现在我们需要了解如何处理所有这些。
您的任务是写出在紧急情况下会打开的非常红的信封。立即期望当一切都好时（只有！），只有最没有经验的受训者会在附近，他们的手会因为发生的事情而颤抖。了解在医疗办公室如何实施紧急标签。例如，发生过敏性休克时该怎么办。医务人员内心地知道所有规程，但是当旁边的人开始死亡时，通常每个人都会无奈地抓住一切。为此，墙上有一个清晰的说明，上面有“打开包装”和“静脉内注射这么多单位药物”之类的物品。
紧急情况下很难思考！应该有简单的说明，以通过脊髓进行解析。
好的DRP包含几个简单的块：
- . , .
- — , systemctl status servicename .
- . SLA — .
- , .
请记住，DRP在服务完全失败时开始，并在即使效率降低的情况下也重新构建。只是丢失预订不应激活DRP。您还可以向DRP添加一杯茶。说真的据统计，由于恐慌中的工作人员急于修理某些东西，同时杀死了唯一拥有数据的活动节点或最终关闭了集群，许多令人不快的事故变成了灾难。通常，喝杯茶5分钟会给您一些时间让自己冷静下来并分析正在发生的事情。
不要混淆DRP和系统护照！不要让不必要的数据过载。只要使快速和方便地使用超链接成为可能，就可以转到文档的必需部分，并以扩展格式阅读有关服务体系结构必需部分的信息。而且在DRP本身中，只有直接说明在何处以及如何与特定命令连接以进行复制粘贴。
如何正确测试
确保任何负责人都能完成所有要点。在最关键的时刻，结果可能是工程师没有对所需系统的访问权限，所需帐户没有密码，或者他不知道这是什么意思“通过总部的代理连接到服务管理控制台”。每一点都应该非常简单。
错误-“转到虚拟化并重新启动死节点”。
正确-“通过Web界面连接到virt.example.com，在“节点”部分中，重新启动导致错误的节点。
避免歧义。记住受惊的实习生。
确保测试DRP。这不仅是一项计划，而且还可以使您和您的客户迅速摆脱紧急情况。最好多次执行此操作：
- 一名专家和数名受训人员在测试台上工作，该测试台尽可能地模拟真实的服务。专家会以各种方式中断服务，并为受训人员提供根据DRP恢复服务的机会。记录所有问题，文档中的歧义和错误。对受训人员进行培训后，在晦涩难懂的地方对DRP进行了补充和简化。
- . . , , , . 10 , .
- . , . , , DRP .
- , , .
- , .
- , , .
- .
- .
- DRP . , . .
- DRP.
- DRP.
- . .
