韧性的责任共担模式 - 可靠性支柱

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

韧性的责任共担模式

韧性是您双方共同承担的责任 AWS 。您要了解作为韧性一部分的灾难恢复（DR）和可用性在这个共担模式下如何运行，这很重要。

AWS 责任-云的弹性

AWS 负责确保运行中提供的所有服务的基础设施的弹性。 AWS Cloud该基础架构包括运行 AWS Cloud 服务的硬件、软件、网络和设施。 AWS 尽商业上合理的努力提供这些 AWS Cloud 服务，确保服务可用性达到或超过AWS 服务级别协议 (SLAs)。

AWS 全球云基础设施旨在让客户能够构建高韧性的工作负载架构。每个可用区 AWS 区域 都是完全隔离的，由多个可用区组成，这些可用区是基础设施中物理隔离的分区。可用区会隔离可能影响工作负载韧性的故障，防止这些故障影响区域内的其他可用区。但同时，中的所有区域都通过完全冗余的专用城域光纤通过高带宽、低延迟的网络互连，在区域之间提供高吞吐量、低延迟的网络。 AWS 区域 可用区之间的所有流量都经过加密。网络性能足以完成可用区之间的同步复制。将应用程序划分为多个部门时AZs，可以更好地隔离并保护公司免受停电、雷击、龙卷风、飓风等问题的侵害。

客户责任 – 云中的韧性

您的责任由您选择的 AWS Cloud 服务决定。这决定了您承担韧性责任时必须执行的配置工作量。例如，诸如亚马逊弹性计算云 (AmazonEC2) 之类的服务要求客户执行所有必要的弹性配置和管理任务。部署 Amazon EC2 实例的客户负责在多个位置（例如 AWS 可用区）部署 Amazon EC2 实例，使用 Auto Scaling 等服务实现自我修复，并对安装在实例上的应用程序使用弹性工作负载架构最佳实践。对于托管服务，例如 Amazon S3 和 Amazon DynamoDB AWS ，运营基础设施层、操作系统和平台，客户可以访问终端节点来存储和检索数据。您负责管理数据的韧性，包括备份、版本控制和复制策略。

跨多个可用区部署工作负载 AWS 区域 是高可用性策略的一部分，该策略旨在通过将问题隔离到一个可用区来保护工作负载，该可用区使用其他可用区的冗余来继续处理请求。多可用区架构也是灾难恢复策略的一部分，旨在更好地隔离工作负载，防止受到停电、雷击、龙卷风、地震等事故和灾害的影响。灾难恢复策略也可以使用多个 AWS 区域。例如，在主动/被动配置中，如果主动区域不再处理请求，则工作负载的服务会从其主动区域失效转移到其灾难恢复区域。

展示韧性共担模式的图表。

客户和 AWS负责的云中的韧性与云的韧性

您可以使用 AWS 服务来实现您的弹性目标。作为客户，您负责管理系统的以下方面，以便实现云中的韧性。有关每项服务的更多详细信息，请参阅 AWS 文档。

联网、配额和限制

  • 基础部分详细介绍了责任共担模式这一领域的最佳实践。

  • 根据预期的负载请求增加情况（如果适用），规划留足了扩展空间的架构，了解所包含服务的服务配额和限制。

  • 设计网络拓扑，使其具有高可用性、冗余性和可扩展性。

变更管理和运营韧性

  • 变更管理包括如何在环境中引入和管理变更。实施变更需要构建运行手册并让其保持最新状态，也需要为应用程序和基础设施制定部署策略。

  • 监控工作负载资源的韧性策略考虑了所有组件，包括技术和业务指标、通知、自动化以及分析。

  • 云中的工作负载必须适应需求变化，能根据受损情况或使用量波动情况进行横向缩减。

可观测性和故障管理

工作负载架构

  • 您的工作负载架构包括如何围绕业务领域设计服务、应用SOA和分布式系统设计以防止故障，以及如何内置限制、重试、队列管理、超时和紧急杠杆等功能。

  • 依靠经过验证的 AWS 解决方案、Amazon Builders' Library 和 serverless patterns 来与最佳实践保持一致，从而快速启动实施。

  • 通过持续改进将系统分解为分布式服务，以便更快地扩展和创新。使用 AWS 微服务指导和托管服务选项来简化引入变更和实现创新的工作，提高完成这类工作的能力。

关键基础设施的持续测试

  • 测试可靠性意味着在功能、性能和混乱层面进行测试，也意味着采用事件分析和演练日活动实践来积累专业知识，解决人们不太了解的问题。

  • 对于全云部署和混合应用程序，如果知道在出现问题或组件故障时应用程序会有怎样的表现，您就可以快速和可靠地从故障中恢复。

  • 创建并记录可重复的试验，了解事情未按预期发展时系统有何表现。这些测试会证明整体韧性的有效性，并在面对真正的故障场景之前为运营程序提供反馈环路。