本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 了解权衡因素和风险
<a name="tradeoffs"></a>

韧性架构应使用少量经过充分测试、简单可靠的机制来应对故障。为了实现最高水平的韧性，工作负载应自动检测尽可能多的故障模式并从中恢复。实现这一目标需要在韧性分析方面投入大量精力。这意味着实现更高的韧性水平需要权衡取舍。然而，随着不断进行权衡，相对于韧性目标而言，收益会逐渐递减。以下是最典型的权衡因素：
+ **成本**：冗余的组件、增强的可观测性、额外的工具或更高的资源利用率都将导致成本增加。
+ **系统复杂性**：检测和响应故障模式（包括缓解解决方案）以及可能不使用托管服务，都会增加系统复杂性。
+ **工程工作量**：需要额外的开发人员工时来构建用于检测和响应故障模式的解决方案。
+ **运营开销**：监控和运营处理更多故障模式的系统可能会增加运营开销，尤其是在您无法使用托管服务来缓解特定故障模式时。
+ **延迟和一致性**：如 [PACELC 定理](http://www.cs.umd.edu/~abadi/papers/abadi-pacelc.pdf)所述，构建重视可用性的分布式系统需要在一致性与延迟之间权衡取舍。



![\[根据所进行的权衡取舍实现韧性目标的概率，即您达到收益递减点的概率\]](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/resilience-analysis-framework/images/tradeoffs.png)


在考虑用户故事中已识别故障模式的缓解措施时，请同时考虑需要做出的权衡取舍。与安全性一样，韧性也是一个优化问题。您必须决定是避免、缓解、转移还是接受已识别故障带来的风险。您可以避免一些故障模式，接受一些故障模式，还可以转移一些故障模式。您可以选择缓解已识别的许多故障模式。为确定要采取哪种方法，请通过提出两个问题进行评估：发生故障的可能性有多大？ 如果发生故障，对工作负载产生哪些影响？

**可能性**是指事件发生的合理程度。例如，如果用户故事有一个组件在单个 Amazon Elastic Compute Cloud（Amazon EC2）实例上运行，则该组件可能会在系统运行期间的某个时间点中断，原因可能是由于修补程序或操作系统错误。相反，如果数据库由 Amazon Relational Database Service（Amazon RDS）管理，并在其主实例与辅助实例之间同步数据，则完全不可用的可能性较低。

**影响**是对事件可能造成的损害的评估。应从财务和声誉两个角度进行评估，并相对于其影响的用户故事的价值进行评估。例如，不堪重负的数据库可能会严重影响电子商务系统接受新订单的能力。但是，在负载均衡器背后 20 个实例的实例集中损失一个实例，影响可能微乎其微。

您可以将对这些问题的回答与为降低风险而必须进行的权衡成本进行比较。结合您的风险阈值和韧性目标考虑这些信息，可以帮助您决定要主动缓解哪些故障模式。