# 工作负载和范围
<a name="workload-and-scope"></a>

 根据 [AWS Well-Architected Framework](https://docs.aws.amazon.com/wellarchitected/latest/userguide/workloads.html)：

 工作负载是一系列资源和代码，它们可提供商业价值，如面向客户的应用程序或后端过程。一个工作负载可能由单个 AWS 账户中的一部分资源组成，也可能是跨多个 AWS 账户的多个资源的集合。一家小型企业可能只有几个工作负载，而大型企业可能有数千个工作负载。

 工作负载不仅仅是云服务或资源。它还包括人员、团队、流程和运行手册，以及提供业务价值的技术和基础设施。在执行 WAFR 之前，请花些时间来了解和记录工作负载的各个组成部分。这有助于您在审查阶段节省时间。

## 为 WAFR 选择工作负载
<a name="choosing-a-workload-for-a-wafr"></a>

 要为 WAFR 准备工作负载，请与团队讨论以下问题：
+  谁拥有工作负载？ 如果工作负载中断影响业务，谁应负责？ 
+  工作负载的目的是什么？ 有针对业务的分析吗？ 它有沙盒、训练和日志记录吗？ 
+  此工作负载是否需要存在？ 如果您把它关掉会怎样？ 
+  工作负载是面向客户还是内部的？ 
+  工作负载是生产性的，还是非生产性的？ 
+  工作负载处于其生命周期的哪个阶段？ 
+  如果工作负载中断，会有什么影响？ 
+  工作负载的界限是什么？ 
+  此工作负载有哪些依赖关系？ 

 在继续运行 WAFR 之前，在评估工作负载时，您应该能够清楚地回答其中的大多数问题。

## 审查的范围是什么？
<a name="what-is-the-scope-of-the-review"></a>

 尽管 WAFR 最终会涵盖[框架的所有支柱](https://docs.aws.amazon.com/wellarchitected/latest/framework/the-pillars-of-the-framework.html)，但我们可以在做出决策之前确定权衡并了解上下文。一个好的起点是将重点放在已确定优先顺序的支柱或工作负载的特定领域上。

 定义更大的审查流程，生成一些切实可行的结果，然后进行迭代，将有助于您为工作负载和业务创造更多价值。

 考虑采取分阶段的方法：

1.  确定与当前业务和技术环境相关性最高的两到三个主要支柱 

1.  演示工作负载在这些支柱中的价值 

1.  获得令人满意的结果后，对更多支柱重复此过程 

 要进一步缩小范围，请使用专为您的工作负载设计的剖析。