改进您的灾难恢复（DR）计划

文 | 沉默恶魔（转载请注明出处）
微信号：chenmoemo
关注公众号：AWS爱好者

最近云很热闹，先是AWS，后是google云故障，这也是在提醒我们掌握主动，学好灾备知识，尽早对业务做好灾备计划是非常重要的；没有一个云提供商能保证永远不出问题，灾难发生时，合理运用DR计划，在第一时间恢复业务，将灾难对于业务造成的影响降到最低是我们的目标。

前面我们介绍了关于Disaster Recovery (DR)的内容包括：

1 Disaster Recovery (DR) 灾难恢复的定义和内容概述
2 恢复时间目标（RTO） 和 恢复点目标（RPO）
3 与灾难恢复（DR）相关的AWS功能和服务-1
4 与灾难恢复（DR）相关的AWS功能和服务-2
5 与灾难恢复（DR）相关的AWS功能和服务-3
6 AWS灾难恢复方案示例-（1）备份和恢复
7 AWS灾难恢复方案示例-（2）在AWS使用Pilot Light快速恢复
8 AWS灾难恢复方案示例-（3）热备
9 AWS灾难恢复方案示例-（4）多站点（双活）

今天我们继续Disaster Recovery (DR)的内容，介绍DR系列的最后一篇–改进您的灾难恢复（DR）计划—建立完善的灾难恢复计划时应遵循的重要步骤，直接开始：

–1、DR计划的测试和确认–

DR计划需要测试，这非常重要，没有经过测试并确认的计划不能确保可用。我之前遇到过很多案例都是客户建立了DR计划，在灾难发生时才发现DR计划不可用，造成了重大的损失。

所以要定期进行测试确认确保是有效可行的。在AWS上可以经常且非常容易的进行DR计划测试，这是在AWS上部署的关键优势，因为可以随时生成资源，测试完了随时删除。

可以使用AWS CloudFormation在AWS上部署环境，使用模板来描述AWS资源以及创建完整环境所需的任何关联依赖项或运行时参数。

组织应该定期设置 “Game day”，对灾难恢复环境进行故障转移测试，可以很容易且具有成本效益的在AWS中创建Game day所需的场景，而不需要触及生产环境。Game day验证DR计划的可行性。

确保DR计划已落实到了文档，Game day主要依照DR计划文档执行。如Game day要模拟的灾难类别要提前规划，识别并形成文档，像业务站点断电/断网等等，这些是风险识别的内容。

经过“Game day”确认的DR计划是灾难事件发生时的执行方针，计划需要很清晰的落实在书面上，灾难恢复时依据文档执行或确认。

–2、DR环境的监控和警报–

需要定期检查并进行充分监控，以便在DR环境出现服务器故障、连接问题和应用程序问题的影响时及时收到提醒。 

Amazon CloudWatch提供对AWS资源监控的指标，也可以以应用程序为中心甚至以业务为中心的自定义指标。可以根据任何指标的已定义阈值设置警报，并且在需要时，可以设置Amazon SNS以在出现意外行为时发送警报。

当然，可以在AWS上使用任何监控解决方案，还可以继续使用公司用于监控实例指标以及客户操作系统统计信息和应用程序运行状况的任何现有监控和警报工具。

要提前把监控和警报搞起来，不要等到灾难恢复时才发现DR环境不可用，会造成非常长的恢复时间（RTO）。

–3、备份和备份验证–

切换到DR环境后，应继续进行定期备份，定期验证备份的有效性。

AWS可以灵活地执行频繁、低成本的的DR测试，而无需DR的资源“始终开启”。

–4、设置用户访问权限–

可以使用AWS Identity and Access Management（IAM）保护对DR环境中资源的访问。使用IAM，您可以创建基于角色和基于用户的安全策略，以隔离用户职责并限制用户对DR环境中指定资源和任务的访问。

–5、限制系统访问–

还可以为Amazon EC2资源创建角色，以便只有分配给指定角色的用户才能对DR环境执行已定义的操作，例如访问Amazon S3存储桶或重新指向弹性IP地址。

–6、多使用自动化–

可以使用配置管理/部署的软件自动将应用程序部署到基于AWS的服务器和本地服务器上。可以轻松地跨两个环境处理应用程序和配置更改管理。

AWS CloudFormation与多种工具结合使用，以自动方式配置基础架构服务。还有服务如 AWS OpsWorks或AWS Elastic Beanstalk，总体目标是尽可能自动化部署工作。

使用Auto Scaling确保实例数量适当，在DR情况下，当用户数量开始增多时，可以动态扩展以满足这种增加的需求；当用户减少时可以自动缩减到最低级别的数量。

---

以上，DR系列的内容就全部结束了，

后续此公众号还会发布更多精彩的AWS的知识点，快快关注吧!