AWS环境下的大规模故障排查.

2 分钟阅读

内容级别：高级

本文提供了多种方法，旨在协助您提升运营卓越性并加快问题排查速度，助力您的AWS优化之旅。

简介

作为AWS Support的高级首席工程师，我经常与客户合作，排查随着时间推移而发展的分布式系统。有些问题最初非常模糊，但深入调查后，我学到了更多如何帮助客户提高运营卓越性的方式。仅在大规模环境下发生的瞬态问题尤其难以排查。本文将分享我在AWS环境中进行大规模排查的关键经验。

检测和分类问题

在问题被检测到之前，很难注意到问题的存在，因此在生产系统中进行持续监控是必要的。了解问题并在您的最终客户受到影响并报告问题之前采取行动至关重要。请确保在Amazon CloudWatch或您选择的监控工具中设置已知故障模式的指标覆盖。尝试分类那些具有明确信号的常见问题，并尽可能自动化解决这些问题。这样，您可以将精力集中在需要复杂决策的问题上。例如，Amazon DevOps Guru使用机器学习来分析操作数据和应用程序指标，并识别与正常运行模式不同的行为。当DevOps Guru检测到操作问题或风险时，它会通知用户，以便用户可以启动手动或自动操作。AWS Health向您发送有关AWS服务健康状况或计划变更的通知，以便您可以为事件做好准备，并快速排查可能影响工作负载的问题。在排查持续的瞬态网络中断问题时，DevOps Guru通过指标分析提供异常检测，而AWS Health则帮助您排除AWS检测到的事件。虽然这些服务无法提供根本原因，但它们提供了设定详细网络监控的下一步所需信息。

您可以使用混沌工程方法来发现未知的边界情况故障模式。AWS故障注入模拟器（FIS）允许您注入故障以测试应用程序。在应用程序上运行实战演练以模拟真实世界的事件条件是一种最佳实践。这种演练可以帮助您确保检测到位，并且系统已经准备好响应。有效的金丝雀测试使用现实流量测试系统，也可以在问题发生之前发现问题。您可以使用Amazon CloudWatch Synthetics创建定时运行的可配置脚本（称为金丝雀），以监控端点和API。

记录故障信号和调试信息非常重要。例如，AWS X-Ray可以通过提供请求跟踪、异常收集和性能分析功能来分析分布式应用程序的行为。您必须在问题出现之前设置好X-Ray，以便有效利用X-Ray的分布式跟踪功能。因此，这种设置必须是环境设置的一部分。记录资源标识符和问题的具体时间戳至关重要。有关日志记录和工具化的详细指导，请参见为操作可见性工具化分布式系统。

如为操作可见性构建仪表板所述，仪表板是我们系统的面向人的视图，提供系统行为的简明摘要，包含时间序列指标、日志、跟踪和告警。设置有用的仪表板并定期（例如每周）审查它们可以帮助您发现合适的告警阈值，并找到需要处理的缺失信号。关键要点是，在设计中考虑到操作至关重要，以确保能够检测问题、识别根本原因，并快速进行修复，这一点在AWS Well-Architected操作卓越性支柱中也有涉及。

通过提出正确的问题来理解问题

为了快速解决问题，缩小范围并识别问题出现的具体情况非常重要。提出澄清性问题有助于在根本原因不明确时处理模糊性。我通常会使用初始症状来推导出需要问的问题。我会回顾组成服务的组件并了解它们的依赖关系。然后，我会检查AWS re:Post以查找类似问题或解决方案。保持健康的怀疑态度很重要，检查环境中的任何更改是否导致了问题。警惕不准确的答案。例如，如果错误率在正常范围内，而您错误地认为服务已停机，您可能会浪费时间。不准确的答案是深入调查的良好指示。例如，考虑一个通过Amazon Elastic Kubernetes Service（Amazon EKS）上的容器网络接口（CNI）发送网络数据包并报告网络数据包超时的应用程序。提出以下问题：

只有少数数据包超时，还是所有发往此目的地的数据包都超时？
这个问题只在某个特定的工作节点上的Pod中发生，还是所有运行相同类型软件的Pod都有这个问题？

在某些情况下，您可能会在广泛排查网络性能时浪费时间，而问题实际上只是特定路径上的连接性问题。您可以提出正确的问题来将问题隔离到特定组件。例如，如果所有数据包都超时，那么检查网络配置可能是更快的解决途径，而不是使用性能工具。当能够提出或回答正确问题的相关人员未参与时，您必须升级问题，以便迅速调动合适的资源并解决问题。建立事件时间线对于理解问题大有帮助。记录时间线有助于其他人更好地理解情况。时间线可以帮助解释可能是影响而非原因的事件。在Amazon，我们广泛采用这样的机制。

自动化数据收集

我曾处理过一个涉及从跨账户的多个Amazon Simple Storage Service（Amazon S3）存储桶中获取对象时出现大量5XX HTTP错误的问题。为了更深入地调查，我需要分析那些收到HTTP 5XX响应的特定请求及其Amazon S3请求ID。这些S3存储桶没有启用S3服务器访问日志记录功能。一个AWS Systems Manager自动化文档帮助我为这些存储桶以及我创建的新存储桶配置了日志记录。自动化文档的主要步骤如下代码片段所示：

"mainSteps": [
  {
    "name": "PutBucketLoggingByUri",
    "isCritical": false,
    "action": "aws:executeAwsApi",
    "onFailure": "step:PutBucketLoggingById",
    "nextStep": "End",
    "inputs": {
      "Service": "s3",
      "Api": "PutBucketLogging",
      "Bucket": "{{BucketName}}",
      "BucketLoggingStatus": {
        "LoggingEnabled": {
          "TargetBucket": "{{TargetBucket}}",
          "TargetPrefix": "{{TargetPrefix}}",
          "TargetGrants": [
            {
              "Grantee": {
                "Type": "{{GranteeType}}",
                "URI": "{{GranteeUri}}"
              },
              "Permission": "{{GrantedPermission}}"

自动化文档在下图中展示：

Enter image description here

您还可以使用AWS Systems Manager自动化文档来跨账户提取Amazon Elastic Compute Cloud（Amazon EC2）实例的诊断信息。对于详细的网络监控，Virtual Private Cloud（VPC）流日志和Elastic Load Balancing（ELB）访问日志非常有用，以隔离问题。要在分布式网络中排查瞬态网络错误，请使用AWSSupport-SetupIPMonitoringFromVPC运行手册，在大规模环境中自动化网络诊断，如跟踪路由和VPC流日志。

在设置日志记录后，使用Amazon Athena通过查询轻松分析流日志。您可以在为Amazon VPC流日志创建Athena表后进行这些操作。

例如，运行以下查询以列出所有被拒绝的TCP连接，并使用新创建的日期分区列date提取这些事件发生的星期几：

SELECT day_of_week(date) AS
  date,
  interface_id,
  srcaddr,
  action,
  protocol
FROM vpc_flow_logs
WHERE action = 'REJECT' AND protocol = 6
LIMIT 100;

查询结果如下所示。它提供了TCP连接被拒绝的位置和时间信息：

Enter image description here

在识别到接口和数据包丢失的位置后，您可以通过转移到不健康的资源来缓解问题。您还可以找到在VPC流日志中捕获的带有源和目的地详细信息以及时间戳的确切消息交换。我发现，征服复杂性需要简化这一数据收集和分析的方法。您可以通过使用专门为此任务设计的工具（如CloudWatch Logs Insights或Athena）来分析大型数据集，从而节省时间。除了帮助诊断问题外，Amazon Q还可以为您提供日志文件，帮助您理解和排查自定义问题。在大规模环境中，人工智能功能（如CloudWatch日志异常检测器）使得在日志组内扫描日志事件并找到日志数据中的异常变得更加容易。异常检测使用机器学习和模式识别来建立典型日志内容的基线。有关可观测性的其他最佳实践，请参见为操作可见性工具化分布式系统。

要找出问题的原因，您可能需要日志、跟踪等数据，而这些数据可能无法立即获取。优化安全准确地收集正确数据的过程可以为您节省时间。我们使用AWS Systems Manager或CloudWatch代理等工具收集和查看调试日志、端到端跟踪问题，并查看操作系统内核崩溃转储和系统调用。您可以减少诊断数据收集或修复过程中的步骤，从而更快地解决问题。有关示例，请参见AWS Support自动化工作流程（SAW）中的Systems Manager文档。这些自动化手册让您可以轻松收集诊断数据并自动解决问题。例如，EC2Rescue SAW文档可以帮助您通过Systems Manager自动化和AWSSupport-ExecuteEC2Rescue运行手册诊断和排查EC2实例中的问题。

分析是排查性能相关问题的另一种有用技术。操作系统工具（如perf）提供了多种跟踪和性能监控功能，可以将这些功能可视化为热图。通过这些热图，您可以找到导致性能问题的症结所在。对于应用程序，Amazon CodeGuru Profiler收集来自实时应用程序的运行时性能数据，并提供可帮助优化应用程序性能的建议。

在大规模环境中测试和复制

如果问题是随机发生的，或者只在生产规模的流量中发生，我会使用Systems Manager尝试在一组测试资源上复制问题。为了帮助防止生产影响，您可以通过Systems Manager自动化和Run Command文档，或通过在AWS上进行分布式负载测试来模拟真实世界条件。

排查随机出现在一组EC2实例中的操作系统关键错误或内核崩溃可能具有挑战性。在排查此类问题时，我需要避免对生产实例造成停机。假设应力条件可能会使问题更频繁地出现，我会选择扩展测试阶段实例，并通过Systems Manager自动化和Run Command在整个实例组中配置内核崩溃转储。引入负载测试的压力有助于重现问题并捕获内核崩溃转储。这帮助我将问题缩小到特定操作系统内核和驱动程序组合的特定IO流量模式。blktrace工具在使用btreplay在测试系统上分析和复制生产IO流量时非常有用。您可以使用Systems Manager在EC2实例上运行这两个工具。Systems Manager文档可以在每个EC2实例中运行，以在测试环境中复制问题，如下图所示：

Enter image description here

验证可能原因的理论

为了更快地找到问题的根本原因，我们在操作手册或排查指南中记录常见故障模式的排查方法。此外，自动化简化了调查过程。机器学习可以加速排查的自动化。有关更多信息，请参见Amazon Q的五个排查示例。然而，当问题的根本原因不明确时，寻求多样化的观点非常重要。我们可以隔离系统的特定组件，分析或测试它们，以查看它们如何引发整体问题的一部分，从而帮助尽早发现问题。当问题特别模糊时，实验并测试快速解决方案非常有用。如果实验失败，则可以以较低成本进行迭代以验证可能原因的理论的正确性。

验证解决方案

在确定并审查修复措施后，下一步是在足够规模的系统中测试修复措施。修复一个组件有时可能会暴露进一步的问题。因此，请务必执行验证修复安全性的测试。最好分阶段部署修复措施，并准备好回滚程序。有关安全持续部署的方法，请参见自动化安全的、无人工干预的部署。

从过去的问题中学习以避免将来发生

您必须设计系统，使其具有弹性和容错性。然而，尽管我们尽力设计，故障最终可能会随着时间的推移在大规模环境中发生。因此，您必须考虑到操作，设计系统以应对这种情况，以便快速解决问题并从中学习。任何操作准备不足，包括排查方法的缺陷，都可能导致对最终客户产生长期影响。在Amazon，我们通过错误更正（CoE）机制从每个问题中学习。我们使用CoE流程通过详细的回顾来提高质量，从而避免过去的问题，并在大规模环境中解决问题。故障是学习的绝佳机会。它们不仅可以用于在事后分析中推动正确的行动以提高弹性，还可以使我们在排查问题方面变得更加出色。

通过了解工作负载的需求，预定义常规活动的操作手册和指导问题解决的指南，使用AWS中的代码操作功能，并保持态势感知，操作团队可以更好地准备和有效应对事件发生时的情况。AWS从您遇到的常见问题中学习，并在我们的排查资源和re:Post中分享这些常见问题的答案。此外，AWS在AWS Well-Architected和AWS Trusted Advisor中更新了最佳实践。