WA-可靠性-Reliability-202310-Summary
设计原则¶
collapse: close
title: 自动从故障中恢复
通过监控关键性能指标 (KPI) 的工作负载，您可以在超出阈值时触发自动化。这些 KPI 应该是衡量业务价值的指标，而不是衡量服务运营的技术方面的指标。更复杂的自动化，可以在故障发生之前预测和修复故障。使用更复杂的自动化，可以在故障发生之前预测和修复故障。
collapse: close
title: 测试恢复过程
在本地环境中，通常会进行测试以证明工作负载在特定场景中有效。测试通常不用于验证恢复策略。在云中，您可以测试工作负载如何失败，然后您您可以使用自动化来模拟不同的故障或重新创建之前导致故障的场景。这种方法会公开故障路径，您可以在真正的故障场景发生之前测试和修复，从而降低风险。
collapse: close
title: 水平扩展以提高聚合工作负载的可用性
用多个小资源替换一个大资源，以减少单个故障对整体工作负载的影响。将请求分布在多个较小的资源上，以确保它们不会共享一个共同的故障点.
collapse: close
title: 停止猜测容量
本地工作负载失败的一个常见原因是资源饱和，当对工作负载的需求超过该工作负载的容量时（这通常是拒绝服务攻击的目标）。在云中，您可以监控需求和工作负载利用率，并自动添加或删除资源以保持最佳水平以满足需求，而不会过度或不足供应。仍然存在限制，但可以控制某些配额，而可以管理其他配额（请参阅管理服务) 配额和约束)。
问题和定义¶
基础
REL 1 如何管理服务配额和限制？
REL 2 如何规划网络拓扑？
工作负载架构
REL 3 如何设计工作负载服务架构？
REL 4 您如何在分布式系统中设计交互以预防发生故障？
REL 5 您如何在分布式系统中进行交互设计，从而缓解或经受住故障影响？
变更管理
REL 6 如何监控工作负载资源？
REL 7 您如何设计工作负载，以适应不断变化的需求？
REL 8 如何实施更改？
故障管理
REL 9 如何备份数据？
REL 10 如何使用故障隔离来保护您的工作负载？
REL 11 如何将您的工作负载设计为可承受组件故障的影响？
REL 12 如何测试可靠性？
REL 13 如何规划灾难恢复（DR）？
最佳实践¶
基础¶
REL 1 如何管理服务配额和限制？¶
了解服务配额和限制¶
了解您的工作负载架构的默认限额并管理限额提高请求。了解哪些云资源约束（如磁盘或网络）可能会对您产生影响。
跨多个账户和区域管理服务限额¶
如果您目前使用多个账户或区域，请确保在运行生产工作负载的所有环境中都请求适当的限额。
通过架构适应固定服务配额和限制¶
了解不可更改的服务限额、服务限制和物理资源限制。为应用程序和服务设计架构，以防止这些限制影响可靠性。
监控和管理配额¶
评估您的可能使用情况，并适当提高您的配额，支持使用量按计划增长。
自动管理配额¶
实施工具以便在接近阈值时向您发送提醒。您可以使用 AWS 服务限额 API 自动发出配额提高请求。
确保在当前配额与最大使用量之间存在足够的差距，以便应对故障转移¶
当资源出现故障或无法访问时，该资源可能仍会被计入限额，直到成功终止资源。确认您的限额涵盖出现故障或无法访问的资源及其替换资源的重叠部分。在计算此差距时，应考虑网络故障、可用区故障或区域故障等使用案例。
REL 2 如何规划网络拓扑？¶
为工作负载公有端点使用高度可用的网络连接¶
构建与工作负载的公共端点的高可用性网络连接有助于减少因连接丢失而导致的停机，并提高工作负载的可用性和改进 SLA。为此，需使用高度可用的 DNS、内容分发网络（CDN）、API Gateway、负载均衡或反向代理。
为云环境和本地部署环境之间的私有网络预置冗余连接¶
在单独部署的私有网络之间使用多个 AWS Direct Connect 连接或 VPN 隧道。使用多个 Direct Connect 位置实现高可用性。如果使用多个 AWS 区域，请确保其中至少有两个区域存在冗余。您可能想要评估终止 VPN 的 AWS Marketplace 设备。如果您使用 AWS Marketplace 设备，请在不同的可用区中部署冗余实例以实现高可用性。
确保 IP 子网分配考虑扩展和可用性¶
Amazon VPC IP 地址范围必须足够大，以满足工作负载的要求，包括考虑未来的扩展以及跨可用区为子网分配 IP 地址。这包括负载均衡器、EC2 实例和基于容器的应用程序。
轴辐式拓扑优先于多对多网格¶
如果通过 VPC 对等连接、AWS Direct Connect 或 VPN 连接的网络地址空间超过两个（例如，VPC 和本地部署网络），则使用与 AWS Transit Gateway 所提供的模型类似的轴辐式模型。
在互相连接的所有私有地址空间中必须采用非重叠的私有 IP 地址范围¶
多个 VPC 通过对等连接或 VPN 连接时，各个 VPC 的 IP 地址范围不得重叠。与之类似，您必须避免 VPC 和本地部署环境或与其他您使用的云提供商之间出现 IP 地址冲突。您还必须能够在需要时分配私有 IP 地址范围。
工作负载架构¶
REL 3 如何设计工作负载服务架构？¶
选择如何划分工作负载¶
在确定应用程序的弹性要求时，工作负载划分很重要。应尽可能避免使用整体式架构。相反，应仔细考虑哪些应用程序组件可以分解为多项微服务。根据您的应用程序要求，最终应尽可能采用服务导向型架构（SOA）与微服务组合的形式。能够实现无状态的工作负载更容易部署为微服务。
构建专注于特定业务领域和功能的服务¶
服务导向型架构（SOA）采用按业务需求定义的、划分明确的功能来定义服务。微服务使用域模型和限界上下文，沿业务环境边界划定服务边界。通过将重点放在业务领域和功能上，有助于团队为其服务定义独立的可靠性要求。限界上下文隔离和封装业务逻辑，让团队能够更好地解释如何处理故障。
根据 API 提供服务合同¶
服务合同是 API 生产者与使用者之间的书面协议，采用机器可读的 API 定义形式进行定义。合同版本控制策略让使用者能够继续使用现有的 API，并在更新的 API 准备就绪时，将其应用程序迁移到更新的 API。只要遵守合同，生产者部署可随时进行。服务团队可以使用自己选择的技术堆栈来满足 API 合同要求。
REL 4 您如何在分布式系统中设计交互以预防发生故障？¶
确定需要哪种类型的分布式系统¶
硬性实时分布式系统需要同步并快速地做出响应，而软性实时系统有更宽松的以分钟计的时间窗口，或更多响应。离线系统会对响应进行批处理或异步处理。硬性实时分布式系统具有最严格的可靠性要求。
实施松耦合的依赖关系¶
队列系统、流系统、工作流和负载均衡器等依赖关系是松耦合的。松耦合有助于隔离某个组件的行为与依赖于它的其他组件的行为，从而提升弹性和敏捷性。
使所有响应幂等¶
幂等服务承诺每个请求只完成一次，因此发起多个相同请求与进行单个请求的效果相同。幂等服务使客户端可以轻松进行重试，而不必担心错误地处理多次。要执行此操作，客户端可以发出具有幂等性令牌的 API 请求，每当重复请求时都会使用同一令牌。幂等服务 API 使用令牌返回响应，该响应与首次完成请求时返回的响应相同。
持续工作¶
系统会在负载中存在剧烈快速更改时失败。例如，如果您的工作负载执行的一项运行状况检查监控着数千个服务器的运行状况，每次都应发送相同大小的有效负载（当前状态的完整快照）。无论是否有服务器或有多少服务器发生故障，运行状况检查系统都会持续工作，而不会有剧烈、快速的变动。
REL 5 您如何在分布式系统中进行交互设计，从而缓解或经受住故障影响？¶
实现轻松降级以将适用的硬依赖关系转换为软依赖关系¶
即使依赖项不可用，应用程序组件也应继续执行其核心功能。应用程序组件可以提供稍微陈旧的数据、替代数据，甚至没有数据。这可确保在提供核心业务价值的同时，将局部故障对整体系统功能造成的障碍减至最少。
限制请求¶
限制请求，以防范因需求意外增加而导致的资源耗尽的情况。系统将处理未超过限制速率的请求，而超过所定义限制的请求将被拒绝，并返回一条消息，指出请求已受限制。
控制与限制重试调用¶
使用指数回退来重试请求，每次重试之间的间隔会逐渐延长。在两次重试之间引入抖动，以随机调整重试间隔。限制最大重试次数。
快速试错和限制队列¶
当服务无法成功响应请求时，可采用快速失效机制。这样可释放与请求关联的资源，并允许该服务在资源不足的情况下进行恢复。快速失效机制一种成熟的软件设计模式，可用于在云端构建高度可靠的工作负载。队列也是一种成熟的企业集成模式，其能够实现平稳的负载，并在能够容忍异步处理的情况下，使得客户端能够释放资源。如果某个服务在正常条件下能够成功响应，但在请求速率过高时失败，请使用队列来缓冲请求。不过，不要允许出现较长的队列积压，否则可能导致处理已被客户端放弃的过时请求。
设置客户端超时¶
您应适当设置连接和请求的超时，对其进行系统性验证，不要依赖默认值，因为默认值并不了解具体的工作负载情况。
尽可能使服务为无状态¶
服务应该不需要状态或在不同的客户端请求之间卸载状态，在磁盘上和内存中本地存储的数据不存在依赖关系。从而支持任意替换服务器，而且不会对可用性产生影响。Amazon ElastiCache 或 Amazon DynamoDB 是卸载状态的理想目标位置。
实施紧急杠杆¶
紧急杠杆是可帮助您的工作负载减轻可用性影响的快速流程。
变更管理¶
REL 6 如何监控工作负载资源？¶
为工作负载监控全部组件（生成）¶
使用 Amazon CloudWatch 或第三方工具监控工作负载组件。使用 AWS Health Dashboard 监控 AWS 服务。
定义与计算指标（聚合）¶
存储日志数据并在必要时应用筛选条件以计算指标，例如，特定日志事件的数量，或从日志事件时间戳计算得到的延迟。
发送通知（实时处理和告警）¶
当组织检测到潜在问题时，会向相应的人员和系统发送实时通知和提醒，以便快速有效地处理这些问题。
自动响应（实时处理和告警）¶
检测到事件后，利用自动化功能执行操作；例如，更换故障组件。
分析¶
收集日志文件和指标历史，并对其进行分析以获得更广泛的趋势和工作负载见解。
定期进行审核¶
经常审核工作负载监控的实施情况，并根据重大事件和变更加以更新。
对通过系统的请求的端到端跟踪进行监控¶
跟踪各个服务组件的请求处理情况，这样产品团队便能够更轻松地分析和调试问题并提高性能。
REL 7 您如何设计工作负载，以适应不断变化的需求？¶
在获取或扩展资源时利用自动化¶
在替换被破坏的资源或扩展您的工作负载时，通过采用托管 AWS 服务（如 Amazon S3 和 AWS Auto Scaling）对流程进行自动化。您还可以使用第三方工具和 AWS 开发工具包自动扩展。
在检测到对工作负载的破坏时获取资源¶
如果可用性受到影响，在必要时被动扩展资源，从而还原工作负载的可用性。
当检测到某个工作负载需要更多资源时，就会获取资源¶
主动扩展资源以满足需求并避免影响可用性。
对工作负载进行负载测试¶
采用负载测试方法来衡量扩展活动能否满足工作负载要求。
REL 8 如何实施更改？¶
对部署等标准活动使用运行手册¶
运行手册是用来实现特定结果的预定义程序。使用运行手册执行标准活动，无论这些活动是手动还是自动执行。例如部署工作负载，对工作负载进行修补，或修改 DNS。
将功能测试作为部署的一部分进行集成¶
功能测试作为自动化部署的一部分运行。若未满足成功条件，则相关管道会中止或回滚。
将弹性测试作为部署的一部分进行集成¶
将弹性测试（使用混沌工程的原则）作为预生产环境中自动化部署管线的一部分执行。
使用不可改变基础设施部署¶
不可变基础设施模式要求在生产工作负载上不会出现就地更新、安全补丁或配置更改。需要更改时，会在新的基础设施上构建架构，并将其部署到生产环境中。
使用自动化功能部署更改¶
自动部署与修补以消除负面影响。
故障管理¶
REL 9 如何备份数据？¶
识别和备份需要备份所有数据，或从源复制数据¶
了解并使用工作负载所用的数据服务和资源的备份功能。大多数服务提供了备份工作负载数据的功能。
保护并加密备份¶
使用身份验证和授权来控制并检测对备份的访问。使用加密功能，防止并检测备份的数据完整性是否受到损坏。
自动执行数据备份¶
将备份配置为根据遵循恢复点目标（RPO）的定期计划自动备份，或者在数据集发生更改时自动备份。具有低数据丢失需求的关键数据资产需要频繁地自动备份，而可以接受某些丢失的较不重要数据的备份频率可以更低。
定期执行数据恢复以验证备份完整性和流程¶
通过执行恢复测试，验证您的备份流程实施是否满足恢复时间目标（RTO）和恢复点目标（RPO）要求。
REL 10 如何使用故障隔离来保护您的工作负载？¶
将工作负载部署到多个位置¶
将工作负载数据和资源分布到多个可用区，或在必要时分布到多个 AWS 区域。可通过选择不同位置满足各种需求。
为您的多位置部署选择合适的位置¶
要实现高可用性，请始终（如果可能）将您的工作负载组件部署到多个可用区（AZ）。对于具有极高弹性要求的工作负载，请谨慎评估用于多区域架构的选项。
采用隔板架构来限制影响范围¶
实施隔板架构（也称为基于 cell 的架构），将工作负载中故障的影响限制到有限数量的组件上。
组件的自动恢复受限于单个位置¶
如果工作负载的组件只能在单个可用区或本地部署数据中心内运行，您必须利用相关功能在定义的恢复目标内彻底重建工作负载。
REL 11 如何将您的工作负载设计为可承受组件故障的影响？¶
监控工作负载的所有组件以检测故障¶
持续监控您的工作负载的运行状况，以便您和您的自动化系统立即发现任何故障或性能下降情况。监控基于商业价值的关键性能指标（KPI）。
故障转移到运行状况良好的资源¶
如果资源发生故障，运行状况良好的资源应继续为请求提供服务。对于位置破坏（如可用区或 AWS 区域），确保您拥有适当的系统以失效转移到未受损位置内运行状况良好的资源。
自动修复所有层¶
在检测到故障时，使用自动化功能执行修复操作。降级可能会通过内部服务机制自动修复，也可能需要通过补救措施重启或移除资源。
恢复期间依赖于数据层面而不是控制面板¶
控制平面提供用于创建、读取和描述、更新、删除和列出（CRUDL）资源的管理 API，而数据平面则处理日常服务流量。在对可能影响弹性的事件实施恢复或缓解响应时，着眼于使用最少数量的控制平面操作，来实现对服务的恢复、重新扩展、恢复、修复或失效转移。在这些降级事件期间，数据平面操作应凌驾于任何活动之上。
使用静态稳定性来防止双模态行为¶
工作负载应具有静态稳定性，并且仅在单一正常模式下运行。双模态行为是指工作负载在正常模式和故障模式下表现出不同的行为。
当事件影响可用性时发出通知¶
在检测到突破阈值时发送通知，即使由问题引发的事件已经自动解决。
根据可用性目标和正常运行时间服务等级协议（SLA）来设计您的产品¶
构造您的产品以满足可用性目标和正常运行时间服务等级协议（SLA）。如果您公开或私下同意可用性目标或正常运行时间 SLA，请确认您设计了架构和运营流程来支持它们。
REL 12 如何测试可靠性？¶
根据行动手册调查故障¶
通过在行动手册中记录调查流程，实现对并不十分了解的故障场景做出一致且及时的响应。行动手册是在确定哪些因素导致故障场景时要执行的预定义步骤。所有流程步骤的结果都将用于确定要采取的后续步骤，直到问题得到确定或上报。
在意外事件发生后执行分析¶
审核影响客户的事件，确定这些事件的成因和预防措施。利用这些信息来制定缓解措施，以限制或防止再次发生同类事件。制定程序以迅速有效地做出响应。根据目标受众，适当传达事件成因和纠正措施。如果需要，可将这些原因告知他人。
测试功能要求¶
使用的技术包括用于验证所需功能的单元测试和集成测试。
测试扩展和性能要求¶
使用的技术包括负载测试以验证工作负载是否满足扩展和性能要求。
使用混沌工程测试弹性¶
在处于或尽可能接近生产的环境中定期运行混沌试验，以了解系统如何应对不利条件。
定期进行实际试用¶
利用实际试用活动，在尽可能接近生产环境的环境中（包括在生产环境中），与将参与实际故障情景的人员一起为应对事件和故障而练习如何使用您的程序。实际试用会强制执行相关措施，以确保生产事件不会影响用户。
REL 13 如何规划灾难恢复（DR）？¶
定义停机和数据丢失的恢复目标¶
工作负载具有恢复时间目标（RTO）和恢复点目标（RPO）。
使用定义的恢复策略来实现恢复目标¶
定义满足工作负载恢复目标的灾难恢复（DR）策略。选择一种策略，例如备份和还原、备用（主动/被动）或主动/主动。
测试灾难恢复实施以验证实施效果¶
定期测试到恢复站点的失效转移，以验证是否在正常运行，并满足 RTO 和 RPO。
管理 DR 站点或区域的配置漂移¶
确保 DR 站点或区域的基础设施、数据和配置满足需求。例如，检查 AMI 和服务配额是否为最新。
自动执行恢复¶
利用 AWS 或第三方工具自动进行系统恢复，并将流量路由至 DR 站点或区域。