精通 DevOps 工具与最佳实践 - DevOps 知识中心 精通 DevOps 工具与最佳实践 - DevOps 知识中心

掌握 AWS 故障排除工作流程的专家指南

使用可重复的 AWS 故障排除工作流程，结合 CloudWatch、CloudTrail、VPC 流日志、AWS Config 和 Systems Manager。

掌握 AWS 故障排除工作流程的专家指南

当您每次都遵循相同的工作流程时，AWS 故障排除会变得更容易：定义症状、缩小范围、检查最近的更改、检查日志和指标，然后一次测试一个可能的原因。如果没有这种结构，很容易在 CloudWatch、IAM、VPC 设置和应用程序日志之间来回切换，而无法证明任何问题。

本指南为您提供了一个实用的 AWS 故障排除工作流程，并展示了 CloudWatch、CloudTrail、AWS Config、VPC 流日志和 Systems Manager 的适用场景。

核心 AWS 故障排除工作流程

有效的故障排除工作流程不是一系列随机操作，而是一种结构化的方法，指导您从问题检测到解决和预防。采用可重复的过程可确保一致性、减轻压力并加速事件解决。

1. 定义问题：收集初始信息

第一步是清楚地了解发生了什么。避免做出假设。尽可能多地收集客观信息。

  • 症状：具体是什么失败或行为异常？（例如，“API 调用超时”、“网站返回 5xx 错误”、“EC2 实例无法访问”）。
  • 范围：问题有多广泛？（例如，单个实例、特定应用程序、整个区域、特定用户）。它是否影响生产、预发布或开发环境？
  • 影响：业务影响是什么？（例如，收入损失、客户不满、安全风险）。
  • 最后已知正常状态：它上次正常工作是什么时候？
  • 错误消息：收集来自应用程序、浏览器控制台或直接 AWS 服务响应的任何错误消息。

提示：鼓励用户或系统提供具体的错误消息和时间戳。这些数据非常宝贵。

2. 验证范围：隔离受影响的组件

一旦定义了问题，缩小潜在的爆炸半径。这有助于您集中调查工作。

  • AWS 运行状况：检查您账户中的 AWS 运行状况和公共 AWS 状态页面，以了解正在进行的区域性问题。广泛的服务事件通常可以解释许多症状。
  • 隔离资源：如果 Web 服务器宕机，是只有一个 EC2 实例还是所有实例？数据库是否可以从其他实例访问？
  • 复现：问题是否可以持续复现？如果可以，在什么条件下？

3. 审查最近的更改：识别潜在触发因素

大多数问题都是由更改触发的。这通常是解决问题的最快途径。

  • 部署更改：新的代码部署、基础设施即代码 (IaC) 更新。
  • 配置更改：安全组修改、IAM 策略更新、负载均衡器设置、数据库参数组。
  • 扩展事件：自动扩展活动、服务的手动扩展。
  • AWS CloudFormation / Terraform：审查最近的堆栈更新或资源更改。

工具亮点：AWS CloudTrail 是您的主要工具，显示谁、何时、从何处执行了什么操作。

4. 利用 AWS 监控工具：深入挖掘数据

这是您利用 AWS 原生可观测性工具收集经验证据的地方。

  • Amazon CloudWatch：用于指标、日志和告警。
  • AWS CloudTrail：用于 API 活动和更改历史。
  • VPC 流日志：用于网络流量分析。
  • AWS Config：用于配置历史和合规性。
  • 应用程序日志：来自在 EC2、ECS、Lambda 等上运行的应用程序的日志。

5. 制定并测试假设：提出并验证理论

根据收集的数据，提出一个或多个关于根本原因的假设。然后，系统地测试每一个。

  • 示例假设：“EC2 实例无法访问，因为其安全组不允许入站 SSH 流量。”
  • 测试：检查安全组规则。如有必要，临时修改它们（谨慎操作并制定回滚计划），以查看连接是否恢复。

6. 实施并验证解决方案：应用修复并确认解决

一旦假设得到确认，应用修复。小心操作，如果可能，先在受控环境中进行。

  • 修复：更新 IAM 策略、重新配置安全组、回滚代码部署、扩展服务。
  • 验证：确保原始症状消失，并且没有引入新问题。修复后监控相关指标和日志。

7. 记录并学习：改进未来的故障排除

每个事件都是一次学习机会。记录问题、调查步骤、解决方案和预防措施至关重要。

  • 事件报告：创建简要报告，详细说明时间线、症状、根本原因、解决方案和经验教训。
  • 知识库：添加到团队的知识库中，供将来参考。
  • 预防措施：实施监控、告警或架构更改以防止再次发生。
  • 事后分析：进行无指责的事后分析，以识别系统性弱点。

关键 AWS 故障排除工具详解

AWS 提供了一套强大的工具来帮助进行故障排除。了解它们的优势是关键。

Amazon CloudWatch

CloudWatch 以日志、指标和事件的形式收集监控和操作数据。它对于了解 AWS 资源和应用程序的运行状况和性能至关重要。

  • 指标：可视化性能数据（CPU 利用率、网络 I/O、磁盘操作、数据库连接、Lambda 调用/错误）。为您的应用程序创建自定义指标。
  • 日志：集中来自 EC2 实例（CloudWatch 代理）、Lambda 函数、VPC 流日志、CloudTrail 日志等的日志。使用 CloudWatch Logs Insights 进行强大的查询。
  • 告警：在指标上设置阈值，以在出现问题时触发通知（SNS、Lambda）。

实际示例：调查无响应的 EC2 实例

  1. 检查 EC2 实例状态检查：在 EC2 控制台中，查看实例的状态检查（系统状态和实例状态）。如果任何一个失败，这是一个强烈的指示。
  2. CloudWatch 指标：导航到该实例的 CloudWatch 指标。
    • CPUUtilization：CPU 是否持续处于 100%？
    • NetworkIn/NetworkOut：是否存在意外流量或突然下降？
    • DiskReadOps/DiskWriteOps：磁盘 I/O 是否饱和？
    • StatusCheckFailed_Instance / StatusCheckFailed_System：如果检查失败，这些指标将为 1。
  3. CloudWatch 日志：如果配置了 CloudWatch 代理，请检查 /aws/ec2/instance_id/ 以获取应用程序或系统日志（例如 syslog、nginx_access_log）。使用 CloudWatch Logs Insights 查询错误或特定事件。
# 示例 CloudWatch Logs Insights 查询，用于在 EC2 实例日志中查找错误
fields @timestamp, @message
| sort @timestamp desc
| filter @message like /ERROR|FAIL|EXCEPTION/ and @logStream = 'i-0abcdef1234567890'
| limit 50

AWS CloudTrail

CloudTrail 记录在您的 AWS 账户中进行的 API 调用，提供用户、角色或 AWS 服务所执行操作的历史记录。它对于安全审计、合规性以及最重要的故障排除更改至关重要。

  • 事件历史：查看管理事件的历史记录（例如 RunInstances、AuthorizeSecurityGroupIngress、UpdateFunctionConfiguration）。
  • 数据事件：配置跟踪以记录 S3 对象、Lambda 函数调用等的数据平面操作。

实际示例：诊断 IAM 权限错误（Access Denied）

应用程序或用户在尝试执行 AWS 操作（例如 s3:GetObject）时收到“Access Denied”错误。

  1. 识别失败的操作：哪个特定的 AWS API 调用失败？
  2. 转到 CloudTrail 事件历史：按以下条件过滤事件：
    • 事件名称：确切的 API 调用（例如 GetObject）。
    • 用户名：进行调用的 IAM 用户或角色。
    • 事件源：涉及的 AWS 服务（例如 s3.amazonaws.com）。
    • 时间范围：错误发生的时间附近。
  3. 检查事件详细信息：查找带有 errorCode: "AccessDenied" 的事件。
    • errorMessage 字段通常提供有关缺少的特定权限或资源策略违规的线索。
    • requestParameters 字段显示传递的参数，例如 S3 存储桶或键。
    • userIdentity 字段确认谁尝试了该操作。

这将精确定位哪个用户或角色尝试对哪个资源执行哪个操作，并因权限而失败，从而允许您修改相关的 IAM 策略或资源策略。

AWS Config

AWS Config 提供您的 AWS 资源、其配置以及它们随时间变化的详细清单。它可以评估配置更改是否符合所需设置。

  • 配置历史：查看资源配置如何更改（例如，何时添加或删除了安全组规则，或修改了 S3 存储桶策略）。
  • 合规性：定义规则以检查资源配置是否符合最佳实践或法规要求。

用例：如果应用程序突然失去对数据库的访问权限，您可以使用 AWS Config 检查数据库的安全组最近是否被修改，从而可能撤销对应用程序实例的访问权限。

VPC 流日志

VPC 流日志捕获进出 VPC 中网络接口的 IP 流量信息。它们对于网络连接问题非常宝贵。

  • 流量分析：识别被阻止的流量（REJECT 操作）、意外连接或进出特定 IP 的大量流量。
  • 排查连接问题：确定安全组、NACL 或路由表是否阻止了合法流量。

用例：您的 EC2 实例无法连接到外部 API。检查流日志中从实例 ENI 到 API IP 地址的 REJECT 条目，这可能表明安全组或 NACL 限制性过强。

AWS Systems Manager

Systems Manager 提供了一个统一的界面来查看来自多个 AWS 服务的操作数据并自动化操作任务。用于故障排除的关键组件包括：

  • Session Manager：无需打开入站端口（如 SSH 端口 22）即可安全地通过 Shell 访问 EC2 实例，从而降低安全风险并简化访问。
  • Run Command：在 EC2 实例上远程执行脚本或命令，以收集诊断数据或应用修复（例如，重启服务、检索日志）。
  • Automation：创建运行手册以自动化常见的故障排除和修复步骤。

常见的 AWS 故障排除场景和解决方案

连接问题

连接问题很常见，可能源于各种网络组件。

  • 安全组：充当 EC2 实例的虚拟防火墙。检查入站和出站规则中的所需端口和 IP 范围。
  • 网络访问控制列表 (NACL)：子网级别的无状态防火墙。查看入站和出站规则，注意规则顺序和显式 DENY 规则。
  • 路由表：确保存在正确的路由，以便流量到达其目的地（例如，用于公共流量的互联网网关、用于私有实例访问互联网的 NAT 网关、用于 VPC 间通信的 VPC 对等）。
  • DNS 解析：验证实例是否可以解析主机名。检查 VPC DNS 设置和任何自定义 DNS 服务器。
  • 子网 CIDR 重叠：如果使用 VPC 对等或 VPN，请确保没有重叠的 CIDR 块。

权限错误（访问被拒绝）

当 IAM 主体（用户、角色）尝试执行没有必要权限的操作时，会发生这些错误。

  • IAM 策略：最常见的罪魁祸首。检查附加到用户或角色的 IAM 策略。使用 IAM 策略模拟器测试特定操作和资源。
  • 资源策略：对于 S3、SQS、KMS 和 ECR 等服务，资源策略定义了谁可以访问该资源。确保调用主体在此处被授予访问权限。
  • 服务控制策略 (SCP)：如果使用 AWS Organizations，SCP 可能会在账户或 OU 级别限制操作。
  • 权限边界：一个高级 IAM 功能，可以限制 IAM 实体可以拥有的最大权限。
  • 会话策略：临时策略，可以覆盖或限制身份的有效权限。

服务限制和限流

AWS 服务有软限制和硬限制。达到这些限制可能会导致服务降级或故障。

  • 监控限制：通过 AWS Service Quotas 控制台定期检查您的服务配额。为接近关键限制的指标创建 CloudWatch 告警。
  • 请求增加：大多数软限制可以通过向 AWS 提交支持工单来增加。
  • 限流：当调用速率超过预置容量或突发限制时，Lambda、DynamoDB 和 API Gateway 等服务可能会限制请求。在日志中查找 TooManyRequestsException 或 ThrottlingException 错误。
  • 扩展：确保您的自动扩展组、ECS 服务或数据库只读副本配置为根据需求充分扩展。

主动故障排除的最佳实践

预防总是胜于治疗。实施这些实践以最大限度地减少事件并加快解决速度。

  1. 实施强大的监控和告警：为关键指标、系统运行状况和应用程序错误配置 CloudWatch 告警。与通知系统（SNS、Slack、PagerDuty）集成。
  2. 集中式日志记录：将所有应用程序和基础设施日志整合到 CloudWatch 日志或专用日志记录解决方案（例如，EC2/ECS 上的 ELK 堆栈、Datadog、Splunk）中。
  3. 基础设施即代码 (IaC)：使用 CloudFormation、Terraform 或 CDK 管理您的基础设施。这提供了版本控制并简化了回滚。
  4. 最小权限原则：仅授予用户和角色必要的权限。这减少了潜在安全事件的爆炸半径，并简化了权限故障排除。
  5. 定期审查 IAM 策略：定期审计 IAM 策略，查找过度宽松的语句或未使用的权限。
  6. 了解服务限制：了解您所在区域和账户的默认服务配额。针对预期的增长主动请求增加。
  7. 自动化常见任务：使用 AWS Systems Manager Automation 或 Lambda 函数自动化常见问题的诊断检查和修复。
  8. 标记策略：为所有资源实施一致的标记策略。这有助于组织、成本分配以及在故障排除期间过滤资源。
  9. 实践事件响应：定期进行关键事件的演练。这有助于团队在压力下熟悉工作流程和工具。

关键要点

良好的 AWS 故障排除是有纪律的，而不是疯狂的。定义问题，检查范围和最近的更改，使用正确的 AWS 数据源，并记录修复方法，以便下一次事件能更快解决。