应对云计算中断的6个步骤

企业通常期望公共云为许多应用类型提供灵活性、快速可扩展性和可靠性，但是公共云并不完美。每个主要云计算提供商都经历过内部系统或存储以及网络连接等外部资源的中断。业务中断对任何企业都是毁灭性的打击，云计算中断也可能影响数百名用户的业务。

所有这些凸显了公共云计算的共同现实:用户需要采用灾难恢复计划，就像使用内部数据中心一样。云计算中断时采取的规划和措施可以减轻或加剧对企业的影响。人们需要考虑以下六个重要步骤来顺利度过公共云中断。

步骤1：制定灾难复原策略

处理云计算中断的第一步是创建和实施灾难恢复计划，并在灾难发生之前部署该计划。虽然云计算提供商提供大量服务和资源，但用户需要为每个工作负载创建、部署、配置和监控这些服务和资源。

实际的灾难恢复策略可能会根据工作负载的需要及其对企业的重要性而发生根本变化。日常应用程序可能是虚拟机到辅助位置的常规数据备份和快照的理想选择，例如其他提供商区域、另一个云提供商，甚至是本地存储资源。

高级灾难恢复计划可以使用已部署但在另一个区域空闲的备用实例，并准备在主实例中断时接管。更全面的灾难恢复策略可以包括分布式集群，这些集群可以在多个云区域或可用性区域运行重复的工作负载实例。例如，这种策略可以包括使用负载平衡器在多个实例之间分配流量，并在该区域发生云中断时重定向流量。

这些复制工作的极端变化是云灾难恢复策略，其中工作负载跨两个或更多云平台(如AWS和微软Azure或Azure和谷歌云)冗余运行，以防止云中断的可能性。

步骤2：沟通并实现云计算透明

当事情发生变化时，你需要知道云中发生了什么。传统上，云计算提供商对服务中断不透明，但随着企业将更有价值的工作负载委托给公共云，这种情况正在发生变化。企业需要提高云计算的透明度，提供商也在改善与用户的沟通，以便更及时地了解中断的性质及其当前状态。

例如，AWS公共云提供的服务健康仪表板显示所有服务的当前状态，而微软Azure公共云提供类似的“Azure状态”页面。灾难恢复决策取决于企业对灾难及其严重性的理解，以及提供商对灾难持续时间的估计——，所有这些都可以随着云计算透明度的提高而提高。

但是不要呆在那里。业务和用户群取决于受影响的工作负载，因此向内部用户或客户传达停机的细节同样重要。通知他们停机时间、停机时间对工作负载的影响以及为解决停机时间而采取的步骤。

步骤3：确定灾难恢复计划的业务价值

确定实施灾难恢复计划需要做什么。有些计划是自动的。例如，重要的工作负载通常由某种类型的集群保护，即使节点(或实例)发生故障，集群也应该继续运行。但是，辅助工作负载的灾难恢复策略可能需要人工干预或不连续的步骤，例如恢复和重新启动快照或切换到备份实例。

如果需要人工干预，应考虑恢复过程中涉及的工作和费用，并确定开始恢复的商业价值。询问恢复工作负载是否比仅仅等待云提供商解决停机时间更长、成本更高。云计算提供商的沟通将对这一决定产生重大影响。

步骤4：实施灾难恢复计划

在许多情况下，任务关键型灾难恢复计划可能完全自动化，管理人员可能不需要采取任何有意的行动。例如，即使一个节点在云计算中断期间变得不可用，跨越AWS云计算可用性区域或Azure云区域的集群也可能继续运行。

但是，不太重要的工作负载可能需要有计划的操作。使用准备好的脚本、模板或其他资源来协调适当的灾难恢复响应。当企业决定启动需要hum的灾难恢复计划时

灾难恢复计划需要定期测试。执行测试演练，以确保适当的流程和资源来推动工作负载恢复。该测试还验证相关资源的配置，如IP地址和相关驱动程序以及依赖关系。如果恢复在常规测试中正常工作，则在实际灾难恢复条件下很可能正常工作。

步骤5：监控灾难复原策略

无论实施灾难恢复策略涉及多少工作量或自动化程度，验证恢复的工作负载是否正常工作仍然很重要。经理应该将灾难恢复状态下运行的工作负载的性能与正常情况下运行的相同工作负载的性能进行比较。

应用程序监控工具，如亚马逊云观察和谷歌堆栈审核，关注工作负载健康。这些工具还收集日志、指标和事件，以中继关于恢复的工作负载的操作数据。此外，他们将在云计算中断期间继续监控工作负载的性能和可用性。

步骤6：云计算中断的事后评估

云计算的中断对企业来说可能是痛苦的，但不会永远持续下去。当云计算提供商解决停机问题并恢复正常工作负载操作时，组织需要事后评估事件并评估其灾难恢复响应。

企业还应该考虑灾难恢复计划的有效性，并根据需要调整计划。这可能包括更改分配给应用程序的灾难恢复保护级别，微调用于实施灾难恢复计划的流程，或其他可能减轻未来云计算中断影响的更改。