关于可靠和弹性的云拓扑实践
可靠的应用程序包括：
- 恢复能力并从故障中正常恢复，并且在完全恢复之前，这些故障继续以最少的停机时间和数据丢失运行。
- 高可用性 (HA)，并以正常状态运行，无重大停机时间。
- 通过良好的灾难恢复 (DR) 设计保护免受区域故障影响。
了解这些元素如何协同工作，以及它们如何影响成本，对于构建可靠的应用至关重要。它可帮助您确定可接受的停机时间、业务的潜在成本以及恢复期间需要哪些功能。
可靠性架构师
创建云应用程序时，请使用以下命令建立可靠性。
- 定义要求。
根据您带来的云和业务需求的工作量定义可用性和恢复要求。
- 应用架构最佳实践。
按照已证明的做法，确定体系结构中可能存在的故障点，并确定应用程序如何响应故障。
- 使用模拟和强制故障转移进行测试。
模拟故障、触发强制故障转移以及从这些故障中测试检测和恢复。
- 一致部署应用程序。
使用可靠、可重复的流程发行至生产，并在可能的情况下实现自动化。
- 监视应用程序运行状况。
检测故障、监视潜在故障的指示符以及测量应用程序的运行状况。
- 管理故障和灾难。
确定何时发生故障，并根据既定策略确定如何解决故障。
定义要求
根据您带来的云和业务需求的工作量定义可用性和恢复要求。
在确定业务需求时，请考虑以下事项，并将可靠性计划与它们相匹配：
- 确定工作负载及其要求
工作量是一种不同的功能或任务，从业务逻辑和数据存储要求的角度来看，它在逻辑上与其他工作负载分离。对于可用性、可扩展性、数据一致性和灾难恢复，每个工作量都有不同的要求。
- 确定使用模式
应用程序的使用方式在要求中扮演角色。确定关键期间和非关键期间的需求差异。例如，处理月末处理的应用程序不能在月末失败，但可能会在其他时间处理失败。为了确保正常运行时间，可以在关键时段添加附加组件或冗余，并在它们不再添加值时将其删除。
- 标识关键组件和路径
并非系统的所有组件都与其他组件同等重要。例如，您可能具有添加增量值的可选组件，但可以在没有必要的情况下运行工作量。了解这些组件的位置，反之亦然，即工作量的关键部分所在的位置。这将有助于缩小可用性和可靠性度量范围，并规划恢复策略以优先考虑最重要的组件。
- 确定外部依赖关系以及下游故障的影响
如果您的工作量依赖于外部服务，这些依赖关系的故障可能会对工作负荷的可用性产生负面影响。实施取消集成联接的方法，以隔离下游故障。
- 确定工作量可用性要求
高可用性 (HA) 通常根据启动时间目标进行定义。例如，99% 的 HA 目标意味着某个特定资源在一年中可以在 3.65 天内不可用。Oracle Cloud Infrastructure (OCI) 的设计是为了为您提供高可用性环境。OCI 为其每个服务发布服务级别协议 (Service Level Agreement, SLA)，该协议描述了 Oracle 对这些服务的运行时间和连接的承诺，您应该复查这些承诺，以了解它们如何与您的要求匹配。OCI 上的某些服务内置了高水平的 HA，特别是 Oracle 托管服务，如自治数据库。要确保应用程序体系结构满足业务要求，请为包括外部依赖项在内的每个工作量定义目标 SLA。除了应用程序相关性之外，还考虑到满足可用性要求的成本和复杂性。
- 建立恢复度量—恢复时间目标 (RTO) 和恢复点目标 (RPO)
RTO 是应用程序在发生灾难事件后不可用的最长可接受时间。
RPO 是灾难期间可接受的数据丢失的最长持续时间。
要推导这些值，请执行风险评估，并确保您了解组织中停机或数据丢失的成本和风险。
- 定义灾难
有详细记录的灾后恢复计划和要求非常重要，但这种事件的混乱性质可能造成混乱。了解什么是企业的灾难，确定灾难期间需要的关键作用，并制定明确的通信计划以启动灾难响应。
应用体系结构最佳实践
设计体系结构时，请侧重于满足业务需求的实践，确定故障点，并最大限度地减少故障范围。
考虑以下最佳做法：
- 确定发生故障的位置
分析您的体系结构以确定应用程序可能遇到的故障类型、每个故障的潜在影响以及可能的恢复策略。
- 根据您的 HA 和 DR 要求确定所需的冗余级别
每个工作量所需的冗余级别取决于您的业务需求和应用程序总体成本的因素。
- 可扩展性的设计
云应用程序必须能够进行扩展以适应使用情况的变化。从离散组件开始，并设计应用程序以尽可能自动响应加载更改。在设计过程中请记住缩放限制，以便将来可以轻松地扩展。
- 使用负载平衡分配请求
负载平衡通过从滚动中删除不健康的实例，将应用程序的请求分发到健康服务实例。外部化状态信息将使后端缩放对最终用户透明。如果在会话中跟踪状态，则可能需要粘性。
- 在设计中构建可用性和弹性要求
弹性是指系统从故障中恢复并继续运行的能力。可用性是系统运作和工作时间的比例。实施高可用性最佳实践，例如避免单点故障并按服务级别目标分解工作负载。利用数据层的标准功能，例如应用程序连续性和异步事务，确保可用性和弹性。
- 实施 DR
设计解决方案以满足确定的 RTO 和 RPO 要求。确保您可以在 RTO 中使 DR 解决方案的所有组件联机。保护您的数据，以便满足 RPO 要求。存储、备份和复制数据的方式至关重要。
- 备份数据
即使使用完全复制的 DR 环境，常规备份仍然至关重要。定期备份和验证数据，并确保没有单个用户帐户可以访问生产和备份数据。
- 为应用程序数据选择复制方法
您的应用程序数据存储在各种数据存储中，并且可能具有不同的可用性要求。评估每种类型数据存储的复制方法和位置，以确保它们满足 HA 要求和 RPO。
- 了解故障转移的影响及其对备灾的影响
是否需要实例化另一个区域进行复制以满足您的工作负载要求？故障恢复时是否需要担心数据一致性？
- 记录并测试故障转移和故障恢复进程
明确记录故障转移到新数据存储的指令，并定期测试这些指令以确保它们准确且易于遵循。
- 确保您的数据恢复计划符合 RTO
确保备份和复制策略提供了满足 RTO 和 RPO 的数据恢复时间。应用程序使用的所有类型的数据的帐户，包括引用数据、文件和数据库。
- 备份数据
使用模拟和强制故障转移进行测试
要测试可靠性，需要测量端到端工作量在仅间歇发生的故障条件下的执行情况。
- 通过触发实际故障或模拟常见故障方案来测试常见故障方案
使用故障注入测试测试常见场景（包括故障组合）和恢复时间。
- 标识仅在负载下发生的故障
使用尽可能接近生产数据的生产数据或合成数据测试高峰负载，以了解应用程序如何在现实条件下运行。
- 运行灾难恢复演习
制定灾后恢复计划，并定期测试以确保计划有效。
- 执行故障转移和故障恢复测试
请确保应用程序的相关服务按正确的顺序进行故障转移和故障恢复。
- 运行模拟测试
测试实际生活情景可以突出显示需要解决的问题。情景应可控且不干扰业务。通知模拟测试计划的管理。
- 测试运行状况探测器
配置负载平衡器和通信管理器的健康探测器以检查关键系统组件。测试它们以确保它们作出适当响应。
- 测试监视系统
确保监测系统可靠地报告关键信息和准确的数据，以帮助查明潜在的故障。
- 在测试方案中包括第三方服务
除了恢复之外，还测试第三方服务中断可能导致的故障点。
- 了解测试期间遇到的问题
如果测试显示问题或差距，请通过增加监测或调整业务流程来确定和解决这些问题或差距。
一致部署应用程序
部署包括预配 Oracle Cloud Infrastructure (OCI) 服务和资源、部署应用程序代码和应用配置设置。更新可能涉及所有三项任务或其子集。
- 自动执行应用程序部署流程
自动执行尽可能多的流程。如有可能，应消除人工生产部署，尽管这在较低的环境中可能是可以接受的，以促进速度和灵活性。
- 利用自动化功能在部署之前测试代码
测试 Bug、安全漏洞、功能、性能和集成对于最大限度地减少最终用户发现的问题至关重要。测试失败应防止代码发布到生产中。
- 设计发行流程以最大限度地提高可用性
如果您的发布过程要求服务在部署期间脱机，则应用程序在重新联机之前不可用。利用平台暂存和生产功能。如果可能，请将新部署发布到用户子集以监视早期故障。
- 具有用于部署的回退计划
设计回退过程以返回到上一个已知良好版本，并在部署失败时尽量缩短停机时间。失败的部署时自动回退可以防止不必要的停机时间。
- 日志和审核部署
如果使用暂存部署技术，则应用程序的多个版本正在生产中运行。实施强大的日志记录策略，尽可能捕获特定版本的信息。
- 记录应用程序发放流程
明确定义并记录发放流程，并确保它可供整个运营团队使用。
监视应用程序运行状况
在应用程序中实施监视和预警的最佳做法，以便您可以检测故障并提醒操作员修复故障。
- 围绕服务调用实施跟踪
基线性能数据可帮助提供可用于在性能问题影响用户之前主动识别性能问题的趋势数据。
- 实施健康探测器
定期从应用程序外部运行它们，以确定应用程序健康状况和性能的降级。这些探测器应不仅仅是静态页面测试，还应反映整体应用程序运行状况。
- 检查长时间运行的工作流
提前捕获问题可以最大限度地减少回退整个工作流或执行多个补偿事务处理的需求。
- 维护系统、应用程序和审计日志
使用集中日志记录服务存储日志。
- 设置预警系统
标识应用程序运行状况的关键绩效指标 (KPI)，例如临时异常错误和远程调用等待时间，并为每个指标设置适当的阈值。达到阈值时向操作发送预警。
- 培训多个操作员以监视应用程序并执行手动恢复步骤
请确保始终至少有一个受过培训的运算符处于活动状态。
管理故障和灾难
创建恢复计划，并确保它涵盖数据恢复、网络中断、相关服务故障以及整个区域的服务中断。在恢复策略中考虑 VM、存储、数据库和其他 OCI 服务。
- OCI 支持交互的计划
在需要之前，请建立联系 OCI 支持的过程。
- 记录并测试灾难恢复计划
编写反映应用程序故障的业务影响的灾难恢复计划。尽可能自动执行恢复过程，并记录任何手动步骤。定期测试灾难恢复过程以验证和改进计划。
- 了解 DR 协调所需的关键作用
确保 DR 工作协调良好，并根据业务价值确定应用程序的优先次序。
- 准备应用程序故障
准备一系列故障，包括自动处理的故障、导致功能减少的故障以及导致应用程序不可用的故障。应用程序应将临时问题通知用户。
- 从数据损坏中恢复
如果数据存储中出现故障，请在存储再次可用时检查数据不一致，特别是在复制数据时。从备份中恢复损坏的数据。
- 从网络中断中恢复
您可以使用高速缓存的数据在本地运行，并减少应用程序功能。如果没有，请考虑应用程序停机或故障转移到其他区域。将数据存储在备用位置，直到恢复连接为止。
- 从相关服务故障中恢复
确定哪些功能仍然可用以及应用程序应如何响应。
- 从整个区域的服务中断中恢复
整个区域的服务中断并不常见，但您应该有一个策略来解决这些问题，特别是对于关键应用程序。您可以将应用程序重新部署到其他区域或重新分配流量。
- 从 DR 测试中学习并改进流程
确保捕获 DR 测试期间遇到的任何问题，并在将来的测试或故障转移中解决这些问题的计划。