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