AWS服务问题系统化排查指南

当AWS服务出现问题时，猜测只会浪费时间，往往还会让事态恶化。一套系统化的AWS故障排查工作流程能帮助你明确症状、检查正确的证据、隔离原因，并在不一次性改动三个变量的情况下解决问题。

当你遇到无法访问的EC2实例、AccessDenied错误、被限流的API调用、运行失败的Lambda函数，或其他任何根因不明显的AWS服务问题时，请参考本指南。

系统化故障排查方法论

有效的故障排查不是靠猜测，而是遵循一个逻辑清晰、可重复的过程。采用结构化的方法论能确保你收集所有必要信息，形成合理的假设，并高效地验证它们。以下是核心步骤的分解：

1. 清晰定义问题

在深入日志之前，花点时间全面理解问题。问自己：

什么是确切的问题？（例如：EC2实例无法访问、S3上传失败、Lambda函数超时）。
何时开始出现？是持续性的还是间歇性的？是否有特定的发生时间？
在哪里发生？涉及哪个区域、可用区、服务或特定资源？
谁受到影响？是所有用户、特定群体还是内部系统？
频率如何？是一次性事件还是重复出现的模式？
影响程度如何？是严重、高、中还是低优先级？

提示：在深入排查前，先检查最近的部署、Terraform或CloudFormation变更、IAM编辑、路由表更新和安全组更改。

2. 收集信息并观察

这是AWS强大的监控和日志工具发挥作用的地方。在不做任何更改的前提下，尽可能多地收集相关数据。

检查AWS Health Dashboard： 查看账户特定事件、区域服务事件或计划内维护。
查看CloudWatch指标： 检查服务的相关指标（例如：CPU利用率、网络I/O、错误率、被限流的请求）。
分析CloudWatch日志： 深入查看应用程序日志、VPC流日志、Lambda日志等，寻找错误或异常模式。
查阅CloudTrail日志： 识别最近的API调用，特别是当你怀疑存在未授权访问或配置错误时。
检查配置： 使用AWS Config查看资源配置是否最近发生过更改。
检查资源状态： 在各自的控制台中验证实例、数据库、负载均衡器的状态。

3. 提出假设

基于收集到的信息，提出一个或多个可能导致问题的原因。你的假设应该具体且可验证。例如：

"EC2实例无法访问是因为其安全组不允许入站SSH流量。"
"S3上传失败是由于Access Denied错误，表明IAM策略不正确。"
"Lambda函数超时是因为达到了服务并发限制。"

4. 验证假设并隔离变量

设计一个简单的测试来证明或推翻你的假设。如果初始测试未能解决问题，则优化假设并再次测试。测试时，一次只做一个更改，以便轻松识别因果关系。

示例（连接性）： 如果你怀疑安全组问题，从一个已知源IP和一个端口进行测试。如果证明规则是问题所在，则将临时测试规则替换为你实际需要的精确规则。
示例（权限）： 使用IAM策略模拟器针对失败的操作测试不同的IAM策略。

5. 解决并验证

一旦确定了根本原因，实施适当的修复。应用解决方案后，彻底验证问题是否已解决，并且没有引入新问题。

6. 记录与学习

问题解决后，记录问题、诊断步骤、根本原因和解决方案。这为未来事件创建了宝贵的知识库，并有助于提高系统的弹性。对于关键问题，考虑进行事后复盘，以确定预防措施。

关键AWS故障排查工具和资源

AWS提供了一套丰富的工具，对于诊断问题至关重要。

Amazon CloudWatch

监控资源和应用程序的主要工具。CloudWatch提供：

指标： 几乎所有AWS服务的实时数据点（CPU利用率、网络I/O、S3请求计数、DynamoDB被限流事件、Lambda调用/错误）。为应用程序特定数据创建自定义指标。
日志： 几乎任何来源的集中式日志记录（EC2、Lambda、VPC流日志、CloudTrail、应用程序日志）。使用CloudWatch Logs Insights进行强大的查询和分析。
告警： 在指标上设置阈值，以触发通知（通过SNS）或自动化操作（例如：自动扩展）。
仪表盘： 创建自定义仪表盘以可视化关键指标和日志，提供运营健康状况的统一视图。

AWS CloudTrail

CloudTrail记录您AWS账户中的API活动，显示谁在何时、何地、做了什么以及结果如何。对于安全调查、合规审计以及关键地，对于排查与权限或意外资源更改相关的问题，它是不可或缺的。

用法： 查找与问题发生时间一致的Access Denied事件、UPDATE、DELETE或CREATE操作。

针对S3中CloudTrail日志的Athena查询示例：

SELECT eventtime, eventsource, eventname, useridentity.arn, errorcode, errormessage
FROM cloudtrail_logs
WHERE eventtime > current_timestamp - interval '1' hour
  AND (errorcode LIKE '%AccessDenied%' OR errormessage LIKE '%denied%')
ORDER BY eventtime DESC
LIMIT 100

AWS管理控制台

每个服务控制台都提供特定的仪表盘、状态页面和配置详细信息。这通常是检查资源健康状况和设置的首选位置。例如，EC2控制台显示实例状态、安全组和网络接口。

AWS CLI/SDK

对于程序化检查、自动化和快速临时查询，AWS命令行界面（CLI）和软件开发工具包（SDK）非常宝贵。它们允许您直接从终端或应用程序获取信息、修改配置并与服务交互。

示例（检查安全组规则）：

aws ec2 describe-security-groups --group-ids sg-0123456789abcdef0

AWS Health Dashboard

提供有关AWS服务及您账户健康状况的个性化信息。对于了解问题是账户特定问题还是更广泛的AWS服务事件至关重要。它显示运营问题、计划内维护和个性化警报。

AWS Config

记录AWS资源配置的更改。如果某个资源突然表现异常，Config可以向您展示其配置历史，精确定位更改发生的时间和方式。

常见AWS问题类别及解决方案

大多数AWS问题属于几个重复出现的类别。理解这些模式有助于形成准确的假设。

1. 连接性问题

当资源无法通信时，检查网络路径：

安全组和网络ACL（NACL）： 这是最常见的原因。安全组是有状态的，应用于实例/ENI；NACL是无状态的，应用于子网。验证入站/出站规则是否允许必要的流量。
- 提示： 记住安全组是允许列表。NACL既有允许规则也有拒绝规则。对于NACL，顺序很重要。
路由表： 确保您的子网具有正确的路由以访问互联网（通过互联网网关）、其他VPC（对等连接）或本地网络（VPN/Direct Connect）。
DNS解析： 如果资源无法解析主机名，请检查VPC DNS设置、Route 53配置或应用程序级别的DNS设置。
VPC流日志： 对于深度网络故障排查，流日志记录进出VPC中网络接口的所有IP流量。在CloudWatch Logs Insights中分析它们，以查看已接受/拒绝的连接。
```
fields @timestamp, @message
| filter logStatus = 'OK'
| filter action = 'REJECT'
| filter srcAddr = '192.0.2.1' or dstAddr = '192.0.2.1' -- 感兴趣的IP
| sort @timestamp desc
```

2. 权限错误（访问被拒绝）

这些错误很常见，表现为Access Denied、UnauthorizedOperation或Forbidden消息。

IAM策略： 检查执行操作的用户、角色或组所附加的IAM策略。验证它们是否对正确的Resource上的特定Action具有Allow语句。
- 提示： IAM策略默认是拒绝。您需要显式的允许。

资源策略： 某些服务，包括S3、SQS、KMS、SNS和Lambda，支持基于资源的策略，这些策略直接在资源上授予或拒绝访问。这些必须与IAM身份策略保持一致。

示例S3存储桶策略（针对一个AWS账户，非公共访问）：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowReadFromAppRole",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:role/app-readonly-role"
      },
      "Action": [
        "s3:GetObject"
      ],
      "Resource": [
        "arn:aws:s3:::example-private-bucket/*"
      ]
    }
  ]
}

服务控制策略（SCP）： 如果您使用AWS Organizations，SCP可以设置账户中可用的最大权限。IAM允许不能覆盖SCP限制。
CloudTrail： 在CloudTrail日志中搜索Access Denied错误，以识别确切的API调用、主体和涉及的资源。
IAM策略模拟器： IAM控制台中的一个强大工具，用于测试不同策略对特定操作的影响。

3. 服务限制和限流

AWS服务有软限制和硬限制。达到这些限制可能导致错误或性能下降（ThrottlingException、TooManyRequestsException）。

CloudWatch指标： 监控服务特定指标以查找限流迹象，例如DynamoDB的ReadThrottleEvents或Lambda的Throttles。
Service Quotas控制台： 此控制台列出了您所有的AWS服务配额、当前使用情况，并允许您为可调整的配额请求增加。
指数退避和重试： 在与AWS API交互时，在您的应用程序中实施这些模式，以优雅地处理临时限流。

4. 资源配置错误

配置错误的资源是问题的常见原因。

存储： 不正确的S3存储桶权限（公共访问）、未加密的EBS卷、EBS的IOPS不足。
计算： 错误的EC2实例类型、不正确的AMI、配置错误的用户数据、Auto Scaling组问题。
数据库： 连接字符串问题、安全组配置错误、参数组设置。
负载均衡器： 不正确的监听器规则、不健康的目标组、安全组问题。
AWS Config： 使用Config跟踪资源配置随时间的变化，帮助识别何时引入了错误配置。

5. 应用程序特定问题

即使AWS服务运行完美，应用程序代码也可能存在问题。

应用程序日志： 确保您的应用程序日志流向CloudWatch Logs。分析它们以查找错误、异常或意外行为。
应用程序指标： 从您的应用程序发出自定义CloudWatch指标（例如：错误计数、请求延迟、队列深度），以获得更深入的见解。
AWS X-Ray： 对于分布式应用程序，X-Ray提供端到端的可见性，跟踪请求在多个服务中的流转，并识别性能瓶颈或错误。

减少MTTR的最佳实践

良好的准备工作可以减少事件期间所需的调查工作。

主动监控和告警： 为关键指标（CPU使用率、错误率、延迟、磁盘空间、API错误）实施全面的CloudWatch告警。与SNS集成，向PagerDuty、Slack或电子邮件发送通知。
集中式日志记录： 将所有服务（EC2、Lambda、容器等）的日志聚合到CloudWatch Logs或基于S3的数据湖中，以便于搜索和分析。
基础设施即代码（IaC）： 使用CloudFormation、AWS CDK或Terraform定义您的基础设施。这确保了一致性，减少了手动错误，并使回滚更改更容易。
运行手册和剧本： 记录常见问题、其症状、诊断步骤和解决流程。这使您的团队能够快速、一致地解决问题。
拥抱AWS Well-Architected Framework： 在设计系统时考虑卓越运营、安全性、可靠性、性能效率和成本优化。主动设计可以防止许多问题。
定期审计和审查： 定期审查安全组规则、IAM策略和资源配置，确保它们符合最佳实践和当前需求。
利用AWS Support： 对于无法解决的复杂问题，或者如果您怀疑是AWS侧的服务问题，如果您的支持计划允许，请开启一个支持案例。包括资源ID、区域、带时区的时间戳、错误消息、请求ID以及您已经尝试过的步骤。

要点

每次遇到AWS服务问题时，都遵循相同的节奏：定义症状、检查最近的更改、收集日志和指标、一次只测试一个假设，然后记录修复方案。这个习惯能让您在事态紧急时保持冷静的排查思路。