即使在灾难期间也总有时间喝杯茶
DRP （灾难恢复计划）是理想情况下永远不需要的东西。但是，如果海狸在交配季节迁徙时突然咬断了主干光纤，或者初级管理员放弃了生产基地，那么您一定要确保自己有一个预先制定的计划来处理所有这些耻辱。
当惊慌失措的客户开始切断技术支持电话时，后辈却在寻找氰化物，你明智地打开了红包，开始整理一切。
在这篇文章中，我想分享有关如何编写 DRP 及其应包含的内容的建议。我们还将关注以下事项：
- 让我们学会像恶棍一样思考。
- 让我们看看末日期间喝杯茶的好处。
- 让我们考虑一个方便的 DRP 结构
- 让我们看看如何测试它
这对哪些公司可能有用？
当 IT 部门开始需要此类东西时，很难划清界限。我想说，如果出现以下情况，您绝对需要 DRP：
- 停止服务器、应用程序或丢失某些数据库将给整个企业带来重大损失。
- 您拥有完善的 IT 部门。从某种意义上说，一个部门是公司的一个成熟单位，有自己的预算，而不仅仅是几个疲惫的员工铺设网络、清除病毒和重新填充打印机。
- 您有一个现实的预算，至少可以在紧急情况下部分裁员。
当 IT 部门几个月来一直在乞求将至少几个 HDD 放入旧服务器中进行备份时，您不太可能组织对失败的服务进行全面的迁移以保留容量。尽管这里的文档并不是多余的。
文档很重要
从文档开始。假设您的服务运行在管理员三代前编写的 Perl 脚本上，但没有人知道它是如何工作的。积累的技术债务和缺乏文档将不可避免地不仅伤害你的膝盖，还会伤害你的其他四肢，这只是时间问题。
一旦您对服务组件有了很好的描述，就可以查找事故统计数据。它们几乎肯定是完全典型的。例如，您的磁盘有时会变满，这会导致节点出现故障，直到手动清理为止。或者由于有人再次忘记续订证书而导致客户端服务不可用，而 Let's Encrypt 无法或不愿意进行设置。
像破坏者一样的想法
最困难的部分是预测那些以前从未发生过但可能会完全崩溃您的服务的事故。我和同事们经常在这里扮演反派。喝很多咖啡和一些美味的东西，然后把自己锁在会议室里。只需确保在同一次会议中锁定那些自己开发目标服务或定期使用该服务的工程师即可。然后，无论是在黑板上还是在纸上，您开始画出您的服务可能发生的所有可能的恐怖情况。没有必要详细到具体的清洁女工和拔掉电缆；考虑“破坏本地网络完整性”的场景就足够了。
通常，最典型的紧急情况分为以下类型：
- 网络故障
- 操作系统服务故障
- 应用失败
- 铁失效
- 虚拟化失败
只需浏览每种类型，看看哪些类型适用于您的服务。例如，Nginx 守护进程可能会崩溃并且无法正常运行 - 这意味着操作系统出现故障。导致 Web 应用程序失败的一种罕见情况是软件故障。在完成此阶段时，诊断问题非常重要。例如，如何区分虚拟化上的冻结接口与掉落的 cis 驱动器和网络事故。重要的是要迅速找到责任人并开始追究责任，直到事故得到解决。
写下典型问题后，我们倒了更多咖啡，并开始考虑最奇怪的场景，此时某些参数开始远远超出正常范围。例如：
- 如果活动节点上的时间相对于集群中其他节点的时间向后移动一分钟，会发生什么情况？
- 如果时间向前推进，如果再推进10年呢？
- 如果集群节点在同步期间突然失去网络会发生什么？
- 如果两个节点由于网络上彼此暂时隔离而无法共享领导权，会发生什么情况？
在这个阶段，反向方法非常有帮助。你带着团队中最顽固、想象力最差的成员，给他一个任务，让他在最短的时间内组织一次破坏活动，从而导致服务瘫痪。如果很难诊断，那就更好了。如果你给工程师一个打破某些东西的想法，你不会相信他们会想出多么奇怪又酷的想法。如果你答应他们为此提供一个测试平台，那绝对没问题。
你的这个DRP是什么？！
现在您已经定义了威胁模型。他们还考虑到当地居民为了寻找铜而切断光纤电缆，以及严格在周五 16:46 断开无线电中继线的军用雷达。现在我们需要了解如何处理这一切。
你的任务就是写那些在紧急情况下才会打开的非常红的信封。立即预计，当（不是如果！）一切都结束时，只有最没有经验的实习生会在附近，他们的手会因所发生的事情的恐怖而剧烈颤抖。了解医疗办公室如何实施紧急标志。例如，发生过敏性休克时该怎么办。医务人员熟记所有的规程，但当附近的一个人开始死亡时，很多时候每个人都无助地抓住眼前的一切。为此，墙上有明确的说明，其中包括“打开某某的包装”和“静脉注射这么多单位的药物”等内容。
紧急情况下很难思考！应该有脊髓解析的简单说明。
一个好的 DRP 由几个简单的块组成：
- 事故开始时应通知谁。为了尽可能并行化消除过程，这一点很重要。
- 如何正确诊断 - 执行跟踪、查看 systemctl status servicename 等。
- 每个阶段你能花多少时间？如果您没有时间在 SLA 时间内手动修复它，虚拟机将被终止并从昨天的备份中回滚。
- 如何确保事故已经结束。
请记住，DRP 在服务完全失败时开始，在服务恢复时结束，即使效率有所降低。仅仅丢失预订不应触发 DRP。您还可以将一杯茶写入 DRP。严重地。据统计，许多事故从不愉快变成了灾难性的，是因为工作人员仓促地赶去修复某些东西，同时杀死了唯一有数据的存活节点，或者最终结束了集群。一般来说，喝杯茶 5 分钟会给你一些时间冷静下来分析正在发生的事情。
不要混淆 DRP 和系统通行证！不要让不必要的数据超载。只要能够快速方便地使用超链接转到文档的所需部分，并以扩展格式阅读有关服务架构的必要部分即可。在 DRP 本身中，只有关于在何处以及如何连接复制粘贴特定命令的直接说明。
如何正确测试
确保任何负责的员工都能够完成所有项目。在最关键的时刻，工程师可能没有权限访问所需的系统，没有所需帐户的密码，或者他不知道什么是“通过代理连接到服务管理控制台”总公司”的意思。每一点都应该非常简单。
错 —“进入虚拟化并重新启动失效节点”
正确地 - “通过 Web 界面连接到 virt.example.com，在节点部分中，重新启动导致错误的节点。”
避免歧义。记住那个害怕的实习生。
请务必测试 DRP。这不仅仅是一个表演计划——它可以让您和您的客户快速摆脱危急情况。最好多次执行此操作：
- 一名专家和几名学员在尽可能模拟真实服务的测试台上工作。专家以各种方式中断服务，并让学员根据DRP 恢复服务。所有问题、文档歧义和错误都会被记录。受训人员接受培训后，DRP 在不明确的领域得到扩展和简化。
- 在真实服务上进行测试。事实上，您永远无法创建真实服务的完美副本。因此，每年有必要定期关闭一些服务器、切断连接并引发威胁列表中的其他灾难，以便评估恢复顺序。半夜发生 10 分钟的计划故障比高峰负载期间突然出现数小时故障并导致数据丢失要好。
- 真正的故障排除。是的，这也是测试的一部分。如果发生威胁清单之外的事故，则需要根据调查结果补充并最终确定DRP。
关键点
- 如果事情可能发生，它不仅会发生，而且会在最灾难性的情况下发生。
- 确保您拥有用于紧急负载转移的资源。
- 确保您有备份，它们会自动创建并定期检查一致性。
- 思考典型的威胁场景。
- 让工程师有机会提出提供服务的非标准选项。
- DRP 应该是一个简单而直白的指令。所有复杂的诊断只有在客户服务恢复后才能进行。即使处于储备能力。
- 在 DRP 中提供关键电话号码和联系人。
- 定期测试员工对 DRP 的理解。
- 安排生产现场有计划的事故。支架不能代替一切。
来源： habr.com