如果您负责此项工作，那么您将对改善生产中的这类DRP测试有何建议？
#1 楼
注意：也许不值得过多了解StackExchange在管理其灾难恢复方案方面的好坏。我怀疑他们遵循以下许多最佳实践，并且只是测试场景以验证其配置。
取决于您在其中运行的环境：
灾难恢复计划可能是更大的业务连续性计划的一部分，业务连续性计划也可能会考虑对您的人员，组织，位置，信息，合作伙伴和管理系统的操作风险。
灾难恢复计划可能被分解为许多针对单个服务的IT服务连续性计划。灾难恢复计划可能将人员和流程与服务的技术方面结合在一起。
鉴于这些定义，您可以考虑提高整个组织能力的方法可以抵抗故障：
服务恢复：
使两个地理分散的数据中的单个服务成为Active-Active中心。这确实假设应用程序能够在数据中心之间复制状态，例如使用BASE Semantics来存储数据。
创建自我修复服务，这意味着要预见失败并在考虑到弹性工程的情况下进行构建。一个示例是使用诸如Chaos Monkey之类的工具来模拟故障。
灾难恢复计划：
再次启用跨数据中心的主动-主动机制，与SRP的区别在于，需要仔细考虑容量，即，如果您必须以主动-主动模式使用DC，而一个DC发生故障，则必须充分扩展单个DC以支持100％的DC。交通。
战争游戏和演练对于灾难恢复计划而言确实非常重要，因为它可以测试人员和流程，在最成熟的DevOps环境中，其中的许多工作都可以自动化，这由Chaos Gorilla证明。
业务连续性计划：
基于这是一个DevOps网站，我不会花很长时间来构建业务连续性计划。但是，不能将所有鸡蛋都放在一个篮子中的规则适用-为办公室被水淹时制定计划：
让您的员工每周有一天在家远程工作，这将测试您的BCP策略。
如果可能的话，必须为您的员工在地理位置和政治上分开地点。
定义并测试用于传达业务连续性事件的清晰流程，并通过消防演习进行实践。
评论
好答案，理查德！您确实包括了（1）猴子（2）大猩猩和（3）刚读完我引述的问题时立即想到的鸡蛋（然后想到“嗯，东南部使用猴子或大猩猩，因此，他们为此：+1，并接受……尽管我的“接受”可能随时发生变化，例如，如果该用户打败了您的答案……
–Pierre.Vriens♦
17年4月29日在9:10
像Facebook这样的网站如何不会受到计划维护的影响
–TheGameiswar
17年5月4日在5:54
评论
确实是@ Dawny33，正如我建议的标签摘录中所述，对吗？顺便说一句，海事组织（IMO），这是一个好的做法，立即提交一个新创建的标签的编辑建议...由最初引入该标签的用户...这样可以避免它被滥用的风险（例如） 't Ruine Production”（可能意味着...）...@ Pierre.Vriens我将标签更改为使用全名而不是缩写；它在标签长度限制内，因此，我认为在可能的情况下最好使用全名。
@ Aurora0001：对我来说很好（当我第一次发布问题时，我实际上对此表示怀疑。）
@ Aurora0001：roi标签，您的想法也一样吗？
@ Pierre.Vriens是的，我会这么说。如果缩写很流行，也可以是同义词。