REL11-BP07 构造您的产品以满足可用性目标和正常运行时间服务等级协议(SLA) - AWS Well-Architected Framework

REL11-BP07 构造您的产品以满足可用性目标和正常运行时间服务等级协议(SLA)

构造您的产品以满足可用性目标和正常运行时间服务等级协议(SLA)。如果您公开或私下同意可用性目标或正常运行时间 SLA,请确认您设计了架构和运营流程来支持它们。

期望结果:每个应用程序的性能指标都有明确的可用性和 SLA 目标,可以监控和维护目标,以便符合业务成果。

常见反模式:

  • 在不设置任何 SLA 的情况下设计和部署工作负载。

  • 在没有理由或业务需求的情况下将 SLA 指标设置得很高。

  • 在设置 SLA 时不考虑依赖项及其基础 SLA。

  • 创建应用程序设计时不考虑弹性的责任共担模式。

建立此最佳实践的好处:根据关键弹性目标设计应用程序有助于实现业务目标和满足客户期望。这些目标有助于推动评估不同技术并考虑各种权衡的应用程序设计过程。

未建立此最佳实践暴露的风险等级:

实施指导

应用程序设计必须考虑因业务、运营和财务目标而产生的各种要求。根据运营要求,工作负载需要具有特定的弹性指标目标,以便可以适当地监控和支持它们。不得在部署工作负载之后才设置或引出弹性指标。而应该在设计阶段定义这些指标,并帮助指导作出各种决策和权衡。

  • 每个工作负载都应有自己的一组弹性指标。这些指标可能与其他业务应用程序的指标不同。

  • 减少依赖项会对可用性产生积极影响。每个工作负载都应考虑其依赖项及其 SLA。一般来说,选择可用性目标等于或大于工作负载目标的依赖项。

  • 在可能的情况下,考虑采用松散耦合设计,以便您的工作负载可以在依赖项受损的情况下正常运行。

  • 减少控制面板依赖项,特别是在恢复或降级期间。评估对于任务关键型工作负载保持静态稳定的设计。使用资源节约来提高工作负载中这些依赖项的可用性。

  • 可观测性和仪表化对于通过减少平均检测时间(MTTD)和平均修复时间(MTTR)来实现 SLA 至关重要。

  • 更低的故障频率(更长的 MTBF)、更短的故障检测时间(更短的 MTTD)和更短的修复时间(更短的 MTTR)是用于提高分布式系统中的可用性的三个因素。

  • 建立和满足工作负载的弹性指标,这是所有有效设计的基础。这些设计必须考虑设计复杂性、服务依赖项、性能、扩展和成本之间的权衡。

实施步骤

  • 检查并记录工作负载设计,考虑以下问题:

    • 在工作负载中的什么地方使用控制面板?

    • 工作负载如何实施容错?

    • 扩缩、弹性伸缩、冗余和高可用性组件的设计模式是什么?

    • 数据一致性和可用性的要求是什么?

    • 是否考虑了资源节约或资源静态稳定性?

    • 服务依赖项是什么?

  • 与利益攸关方合作时,根据工作负载架构定义 SLA 指标。考虑工作负载使用的所有依赖项的 SLA。

  • 设置 SLA 目标后,优化架构以满足 SLA。

  • 设置满足 SLA 的设计后,实施运营更改、流程自动化和运行手册,这些操作也将侧重于减少 MTTD 和 MTTR。

  • 部署之后,监控和报告 SLA。

资源

相关最佳实践:

相关文档:

相关服务: