剧本是官方的、正式的书面记录，描述了将可靠地生成组织资源堆栈的工作部署的策略和过程。在产生可预测的结果时，剧本就是计划。
稍后我将描述一本好剧本的所有关键要素。但需要强调的是，剧本本身或多或少是无用的，除非您的团队能够阅读它并将其转化为现实世界的结果。
为此，您需要确保团队中的每个相关成员都完全熟悉他们的角色以及他们将如何履行职责。这将需要您分发计划的副本，并确保每个人都得到他们需要的培训，以便在时机成熟时完美地执行任务。
（运维教程：java567.com/?v=2306022）
如何定义剧本范围
无论如何，一个好的计划始于明确的定义：
- 在哪里可以找到源代码的最新和干净的副本？
- 您的生产环境应该托管在哪里？在像 AWS 这样的公共云中？本地？
- 基础设施应该完成什么？
- 您的运营范围是什么：需要多大规模的硬件资源？
剧本还应明确定义在重建过程中必须遵循的政策：
- 如何保护组织数据？
- 什么决定只能由公司高级管理人员做出？
- 对可以使用的软件和第三方解决方案是否有限制……或者可以从哪些国家/地区获取它们？
- 是否有必须保留在本地的堆栈组件，或者所有东西都可以存在于云中？
如何定义工具
也许任何剧本的核心都是解决您将在工作流程的每个阶段使用的软件和部署工具和过程的部分。
此部分应包括处理将资源从代码移动到部署的脚本的完整代码，以及所有正在使用的软件代码的链接，以及对您将使用的服务进行身份验证的说明。
如何定义参与者
IT 部署是由人执行的。但是哪些人呢？
- 您与谁交谈谁可以使用信用卡以便您可以购买所需的资源？
- 谁有权访问您需要的关键代码库和在线帐户？
- 谁负责在代码投入生产之前进行测试和签字？
- 如果那个人不在怎么办？
需要定义与您正在记录的项目相关的每个角色，并且必须确定负责人 - 以及当前的联系信息。
除了运营联系人之外，剧本还应包括完整的公司通讯目录。如果您每个月都向某人支付薪水，那么他们很可能会被期望在恢复期间执行一些重要的功能。因此，您需要一个可靠的联系信息来源——最好包含每个人的多个联系端点。
如何记录您的恢复
恢复操作可能会很混乱。但至关重要的是，应保留每个步骤（恢复前、恢复后和恢复期间）的日志记录。所以日志生成和存储也应该是你的剧本的一部分。
即使您现在没有时间阅读它们，它们也会在您以后尝试回顾事件并弄清楚到底发生了什么时变得非常宝贵。准确可靠的日志和其他记录的存在实际上可能是法律强制要求的。
您通常会纳入部署生命周期的任何代码审查和应用程序测试都应包含在您的恢复手册中。毕竟，危机过后的错误和失败不会比危机前更有趣。通常为您的测试提供支持的所有脚本的实际代码也应该包含在这里。
如何让你的剧本保持最新
最后，您的剧本应该定期更新以反映对您的应用程序及其支持环境的更改。自然地，您希望使所有详细信息保持最新状态，包括负责特定角色的人员的变化，以及他们正确的联系信息。
为相对复杂的操作创建的完整剧本很容易达到数百页。当您添加协调将参与您的恢复的所有个人的行动的任务时，整个事情可能感觉有点难以管理。不幸的是，您只需要这样做：真的别无选择。
如何自动化你的恢复
好吧，几乎别无选择。还记得我是怎么告诉你的，你应该在剧本中包含完整的操作脚本和指向你的代码库的链接吗？你认为我们的剧本可以说服自己发挥作用吗？为什么不？
想想看。Ansible 或 Terraform 等编排工具，或 Amazon 的 CloudFormation 等特定于云的工具，使您能够以一种可以通过单个命令调用和启动的格式非常紧密地定义基础架构的每一层。
至少在理论上，您没有理由不能将您的剧本构建为一个实际的脚本，其中包含用于拉取软件存储库、启动复杂的虚拟网络和计算实例以及路由 DNS 域的命令。这将是基础架构即代码的强大功能的绝佳示例。
如何测试你的剧本
虽然我们仍在讨论计划和行动手册的主题，但我应该再添加一个非常重要的说明。如果您要不厌其烦地进行研究然后编写剧本，您肯定不想在危机中发现您的计划实际上行不通。
安全的假设是，除非事先经过仔细和反复的测试，否则任何技术都不会起作用。 恢复剧本是这样，备份也是这样：在您成功将备份存档恢复到真实环境之前，您应该假设它会失败。
有了您现在看到的关于剧本的范围、工具、文档、更新和自动化的内容，您现在已经准备好开始创建您自己的剧本了。好吧，别让我妨碍你！
（运维教程：java567.com/?v=2306022）
