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

# 故障模式可观测性
<a name="observability"></a>

要缓解故障模式，您首先必须检测到其当前正在影响或即将影响您的工作负载。仅当存在必须采取措施的信号时，缓解措施才有效。这意味着，制定任何缓解措施的部分内容应至少包括：验证您是否具备或正在构建检测故障影响所必需的可观测性。

应从两个维度考虑故障模式的可观测现象：
+ 哪些*领先指标*告知您系统即将进入可能很快出现影响的情况？
+ 哪些*滞后指标*可以在故障模式发生后尽快显示其影响？

例如，对数据库元素施加的负载过高故障可将连接数作为领先指标。您可以将连接数的稳步上升视为数据库可能很快超出连接限制的领先指标，因此可以采取措施（例如终止最近最少使用的连接）以减少连接数。滞后指标指示何时超出数据库连接限制以及数据库连接错误数上升。除了收集应用程序和基础设施指标外，还应考虑收集[关键性能指标（KPI）](https://docs.aws.amazon.com/wellarchitected/latest/performance-efficiency-pillar/perf_process_culture_establish_key_performance_indicators.html)，以检测故障何时影响您的客户体验。

我们建议您尽可能在可观测性策略中同时包含这两种指标。在某些情况下，您可能无法创建领先指标，但应始终计划为要缓解的每个故障设置一个滞后指标。要选择适当的缓解措施，还应考虑检测到故障的是领先指标还是滞后指标。例如，假设您的网站流量突然激增。您可能只会看到一个滞后指标。在这种情况下，仅靠自动扩展可能并非最佳缓解措施，因为部署新资源需要时间，而节流几乎可以立即防止过载，让您的应用程序有时间扩展或减少负载。相反，对于逐渐增加的流量，您将看到一个领先指标。在这种情况下，节流并不合适，因为您有时间通过自动扩展系统来应对。