aws-service-chaos-research

AWS 服务专属的混沌与高可用性测试研究

为特定 AWS 服务生成全面的混沌工程和高可用性测试场景。采用场景库优先的方法：首先阅读最新的 FIS 场景库文档，查找预构建的复合场景；然后通过 list-actions 查询单个 FIS 操作；最后通过深入研究文档进行补充。

输出语言规则

检测用户对话的语言，并在所有输出中使用相同的语言。

• 中文输入 -> 中文输出
• 英文输入 -> 英文输出
• 混合输入 -> 遵循占主导地位的语言

前置条件

所需工具（每组至少一个）：

FIS 场景库（A 组——基于文档，始终可用）：

• aws___read_documentation — 直接阅读 FIS 场景库页面（场景仅在控制台中提供，无法通过 CLI 查询，因此阅读最新文档是发现它们的唯一方式）

FIS 操作发现（B 组——按偏好顺序使用）：

1. AWS CLI aws fis list-actions — 从用户所在区域获取权威的实时 FIS 操作列表
2. aws___search_documentation — CLI 不可用时，用作备用方案的 FIS 操作参考页面

文档研究（C 组）：

• aws___search_documentation — 搜索 AWS 官方文档
• aws___read_documentation — 阅读完整的文档页面
• aws___recommend — 查找相关页面

所有文档研究只能使用上述 AWS Knowledge MCP 工具。 请勿使用 SearXNG 或其他网络搜索工具进行文档研究。

工作流

重要——按顺序执行所有 AWS Knowledge MCP 调用： 所有 aws___search_documentation、aws___read_documentation 和 aws___recommend 调用都必须逐个按顺序执行。切勿并行发送多个 MCP 请求——aws-knowledge-mcp-server 有严格的速率限制，并会因并发请求而返回 "Too many requests" 错误。 等待每个请求返回完整响应后，再发送下一个请求。 这适用于以下所有步骤（步骤 2、4b、4c、5a、5b）。

失败时重试： 如果任何 MCP 调用（尤其是 aws___read_documentation）返回速率限制错误（"Too many requests"）或其他暂时性错误，最多重试 10 次，每次重试间隔 5 秒。只有在 10 次重试均失败后，才跳过该请求。

多服务请求： 当用户询问多个服务（例如，“EKS、RDS、MSK 和 ElastiCache”）时，一次处理一个服务。完成一个服务的所有研究步骤（步骤 2-5）后，再开始下一个服务。请勿并行研究多个服务——这会触发速率限制。场景库的获取（步骤 2）只需执行一次，因为它涵盖所有服务；每个服务各自的步骤（3-5）则必须依次重复执行。

步骤 1：确定目标服务

从用户的消息中提取目标 AWS 服务，并确定目标区域。

区域检测

FIS 操作在不同 AWS 区域可能有所不同——某些操作可能在 us-east-1 中可用，但在 ap-southeast-1 中尚不可用。务必先确定目标区域，因为服务关键词的解析取决于该区域。

检测顺序（使用第一个适用项）：

1. 用户明确指定——例如，“us-west-2”、“东京区域”、“ap-northeast-1”
2. 根据上下文推断——资源 ARN、之前的对话中提及的区域
3. 检查 AWS CLI 默认值——运行 aws configure get region 获取已配置的默认区域
4. 询问用户——如果以上方法均无法确定区域，请询问： “您要使用哪个 AWS 区域？FIS 操作和场景可能因区域而异。”

将解析出的区域存储为 TARGET_REGION，以便在后续步骤中使用。

服务关键字解析

FIS 操作 ID 遵循 aws:<service>:<action> 模式。要将用户输入映射到正确的 FIS 服务关键字，请从实时 FIS 操作列表中动态发现：

aws fis list-actions --region TARGET_REGION | jq '.actions[].id' | awk -F':' '{print $2}' | sort -u

这会返回该区域中 FIS 支持的服务关键字权威列表（例如，ebs、ec2、ecs、eks、elasticache、fis、network、rds、s3、ssm……）。 将用户提供的服务名称与此列表匹配。例如，如果用户说“Aurora”，则匹配到 rds；如果说“Kubernetes”，则匹配到 eks。

如果无法使用 AWS CLI，则将 AWS 服务名称转换为小写并移除空格和连字符，以此推导关键字（例如，“ElastiCache” → elasticache）。

如果服务存在歧义，请询问用户以澄清（例如，“RDS MySQL 还是 Aurora MySQL？”）。

如果用户提及部署架构，也要确定具体架构：

• 多可用区、多区域、单可用区
• 只读副本、全局表、跨区域复制
• 这会影响哪些场景具有相关性

步骤 2：获取 FIS 场景库（场景库优先）

此步骤具有最高优先级。 FIS 场景库提供由 AWS 精选的复合场景，可协调多个故障注入操作，模拟真实故障。这些场景是最有价值的起点，因为它们体现了 AWS 对如何测试弹性的建议。

场景库中的场景仅限控制台使用，无法通过 AWS CLI 或 API 列出或查询。发现这些场景的唯一方法是阅读最新文档。

获取 references/search-queries.md 中“FIS Scenario Library Pages (Always Fetch)”列出的场景库页面。阅读概览以及与目标服务相关的详细场景页面。逐一按顺序阅读页面——等待每次 aws___read_documentation 调用完成后，再开始下一次调用。

从场景文档中提取每个相关场景的以下信息：

• 场景名称和说明
• 场景协调的子操作
• 与目标服务相关的子操作
• 针对特定资源所需的资源标签
• 默认持续时间（中断阶段 + 恢复阶段）
• 任何先决条件或限制
• 停止条件建议

判断：哪些场景适用？

阅读文档后，对每个场景的相关性进行分类：

相关性	标准
直接相关	场景包含明确针对该服务的子操作（例如，在可用区断电场景中执行“故障转移 RDS”）
间接相关	场景会影响该服务所依赖的基础设施（例如，网络中断会影响任何基于 VPC 的服务）
不相关	场景不会对目标服务产生有意义的影响

在输出中包含直接相关和间接相关的场景。

步骤 3：查询 FIS 操作

完成场景库调研后，查询各项 FIS 操作，以发现复合场景可能未涵盖的特定服务故障注入功能。

路径 A：可使用 AWS CLI（首选）

步骤 3a：获取目标区域中的所有 FIS 操作：

aws fis list-actions --region TARGET_REGION --query 'actions[].{id:id, description:description}' --output json

将 TARGET_REGION 替换为步骤 1 中解析出的区域（例如，us-east-1）。 如果未确定区域，请省略 --region，以使用 CLI 默认值，但警告 用户：结果反映的是其默认区域，在其他区域可能有所不同。

步骤 3b：筛选目标服务——从完整列表中查找 id 包含步骤 1 中搜索关键词的操作：

aws fis list-actions --region TARGET_REGION --query 'actions[?starts_with(id, `aws:KEYWORD:`)].{id:id, description:description}' --output json

还要检查描述字段中的服务名称，因为某些操作的描述可能提及某项服务， 即使操作前缀不同。

步骤 3c（可选）：收集跨领域操作——这些操作会间接影响服务。如果用户的服务 能从网络、API 或基础设施层面的故障注入测试中受益，请将其纳入：

aws fis list-actions --region TARGET_REGION --query 'actions[?starts_with(id, `aws:network:`) || starts_with(id, `aws:fis:inject`) || starts_with(id, `aws:ssm:`) || starts_with(id, `aws:ec2:stop`) || starts_with(id, `aws:ec2:terminate`)].{id:id, description:description}' --output json

跨领域操作及其适用场景：

• aws:network:disrupt-connectivity — 适用于任何基于 VPC 的服务
• aws:network:disrupt-vpc-endpoint — 适用于通过 PrivateLink 访问的服务
• aws:fis:inject-api-internal-error — 适用于测试应用对 AWS API 故障的处理能力
• aws:fis:inject-api-throttle-error — 适用于测试退避／重试逻辑
• aws:fis:inject-api-unavailable-error — 适用于测试优雅降级
• aws:ec2:stop-instances / terminate-instances — 适用于运行在 EC2 上的服务
• aws:ssm:send-command / start-automation-execution — 适用于自定义故障脚本

是否纳入跨领域操作取决于具体情况：

• 纳入：当服务运行在 EC2 上、使用 VPC 网络，或用户关注基础设施层面的故障测试时
• 跳过：当用户只关注服务原生故障，或服务完全托管且没有用户可访问的基础设施层时

路径 B：无法使用 AWS CLI

搜索 FIS 操作参考文档：

aws___search_documentation(
  search_phrase="AWS FIS actions [SERVICE_NAME] fault injection",
  topics=["reference_documentation"],
  limit=10
)

然后阅读 FIS 操作参考页面：

aws___read_documentation(
  url="https://docs.aws.amazon.com/fis/latest/userguide/fis-actions-reference.html",
  max_length=10000
)

决策点：是否找到 FIS 操作？

统计找到的特定于服务的操作数量（不包括跨领域操作）。

• 是（找到 1 个或更多特定于服务的操作） -> 继续步骤 4（FIS 增强路径）
• 否（未找到特定于服务的操作） -> 跳转到步骤 5（仅文档路径）

步骤 4：FIS 增强路径

当 FIS 为目标服务提供原生操作时，将场景库的发现结果与 FIS 操作的特定详细信息结合起来。

4a：将 FIS 操作整理为测试场景

将每个 FIS 操作映射到一个测试场景。使用 references/output-template.md 中的“FIS Native Fault Injection Scenarios”表格格式。

重要——Scenario Library 去重（必须在构建表格前应用）： 在按服务列出任何 FIS 操作之前，先检查该操作 ID 是否作为子操作出现在 Step 2 中发现的任何 Scenario Library 组合场景中。常见的重叠示例：

• aws:rds:failover-db-cluster — AZ Power Interruption 的子操作
• aws:elasticache:replicationgroup-interrupt-az-power — AZ Power Interruption 的子操作
• aws:eks:pod-network-latency — AZ Application Slowdown 的子操作
• aws:eks:pod-network-packet-loss — Cross-AZ Traffic Slowdown 的子操作
• aws:ec2:stop-instances — AZ Power Interruption 的子操作

规则：

1. 如果某个操作是 Scenario Library 子操作，仍要将其列出在按服务划分的表格中，但在“HA Verification Purpose”列追加： “（也是 {Scenario Name} 的子操作——请参阅 Scenario Library 部分）”。
2. 如果某项服务的所有特定于该服务的 FIS 操作都是 Scenario Library 子操作（例如，ElastiCache 只有 replicationgroup-interrupt-az-power，且该操作已由 AZ Power Interruption 覆盖），则完全省略“FIS Native Fault Injection Scenarios”子章节，并替换为：

   {SERVICE} 的所有 FIS 原生操作均由 Scenario Library 组合场景覆盖。详情请参阅 Scenario Library 和 Cross-Cutting 部分。

按故障域对场景分组：

1. 实例/任务级别 — 单个资源故障
2. 存储级别 — 磁盘/卷故障或性能下降
3. 网络级别 — 连接中断
4. AZ 级别 — 可用区故障模拟
5. 区域级别 — 跨区域故障转移
6. API/控制面 — AWS API 错误

Scenario Library 交叉引用： 对于每个 FIS 操作，检查它是否也作为子操作出现在 Step 2 中发现的任何 Scenario Library 组合场景中。如果是，则在“HA Verification Purpose”列追加说明（例如，“也是 AZ Power Interruption 的子操作——请参阅 Scenario Library 部分”）。如果某项服务的所有特定于该服务的 FIS 操作都是 Scenario Library 场景的子操作，则完全省略“FIS Native Fault Injection Scenarios”子章节，并替换为说明：“该服务的所有 FIS 原生操作均由 Scenario Library 组合场景覆盖——请参阅 Scenario Library 和 Cross-Cutting 部分。”

4b：补充特定于服务的能力

某些服务除 FIS 外还内置了故障注入。请搜索这些能力（依次搜索——等待搜索完成后再读取任何结果页面）：

aws___search_documentation(
  search_phrase="[SERVICE_NAME] fault injection testing failover simulation",
  topics=["general", "reference_documentation"],
  limit=10
)

如果找到，请使用 references/output-template.md 中的表格格式添加“Service Built-in Fault Injection”章节。

4c：深入研究文档

使用 references/search-queries.md 中“FIS-Enriched Path”下的搜索查询。依次运行全部 5 个查询（一次一个）。搜索完成后，逐一阅读最相关的 3 到 5 个页面，并对最相关的页面使用 aws___recommend 进行发现。切勿并行发送多个读取或 recommend 请求。

Step 5：仅文档路径（无 FIS 操作）

如果 FIS 没有适用于目标服务的原生操作，则改为进行全面的文档研究。请注意，Step 2 中发现的 Scenario Library 内容仍然适用。

5a：深入搜索文档

使用 references/search-queries.md 中“Documentation-Only Path”下的搜索查询。依次运行全部 6 个查询（一次一个，并等待每个查询完成）。

5b：阅读关键页面并发现相关内容

从合并后的搜索结果中，按照 references/search-queries.md 中的优先级，阅读最相关的前 5 个页面。逐个阅读页面——等待每次 aws___read_documentation 调用完成后，再进行下一次调用。然后在该服务的主文档页面上使用 aws___recommend，发现相关内容。

从所有页面中提取：

• 该服务可能遇到的故障模式
• 内置 HA 机制（自动故障转移、复制等）
• 官方指南中记录的测试方法
• 测试期间需要关注的监控指标

5c：整理替代测试方法

使用 references/output-template.md 中的“Testing Methods (No Native FIS Actions)”章节格式，其中包括间接 FIS 操作和 AWS API/控制台方法。

第 6 步：整理输出并保存到本地文件

将报告直接写入本地 Markdown 文件，而不是将完整内容输出到终端。使用以下文件命名约定：

TIMESTAMP=$(TZ=Asia/Shanghai date +%Y-%m-%d-%H-%M-%S)
SERVICE_SLUG=$(echo "{SERVICE_NAME}" | tr '[:upper:]' '[:lower:]' | tr ' :/' '-')
# File name: ${TIMESTAMP}-${SERVICE_SLUG}-chaos-research.md

对于多服务请求，每个服务生成一个文件：

• ${TIMESTAMP}-rds-chaos-research.md
• ${TIMESTAMP}-eks-chaos-research.md
• 等等。

使用 references/output-template.md 中定义的准确格式整理报告内容，并将其保存到文件中。报告必须按以下顺序包含所有章节：

1. 执行摘要——概述区域、FIS 支持状态和关键建议
2. 场景库与跨领域内容——场景库中的复合场景（优先级最高），跨领域操作作为可选补充。本章节必须位于各服务章节之前。
3. 各服务章节——每个章节包括：FIS 场景（使用 {SVC}-# 测试 ID，例如 EKS-1、Redis-1）、内置方法、推荐测试场景矩阵、环境观察事项和停止条件
4. 推荐测试优先级（汇总）——引用各服务章节中的测试 ID；不要重复完整描述；如果某项 FIS 操作已在同一表格的场景库场景中涵盖，不要单独列出该操作
5. 实施最佳实践——稳定状态、DNS/连接、爆炸半径
6. 参考资料——仅包含实际搜索结果或已阅读页面中的 URL
7. 后续步骤——3–4 项可执行的后续步骤

保存后，在终端打印简短摘要，仅列出：

• 生成的报告文件路径
• 目标服务和区域
• 找到的 FIS 操作数量（特定服务操作 + 跨领域操作）
• 确定的场景库场景数量
• 优先级最高的 3 项推荐测试

重要准则

• 始终优先查阅场景库。 FIS 场景库收录了 AWS 精心策划的韧性测试场景。始终先阅读最新的场景库文档，再进行其他操作。这些内容基于文档（仅限控制台），无法通过命令行查询。
• 区域很重要。 查询 FIS 操作前，始终先确定目标区域。FIS 操作的可用性因区域而异。始终在 AWS CLI 命令中传入 --region，并在输出中明确说明区域。
• 不要捏造 FIS 操作。 如果某项操作不存在，请明确说明。设置备用方案的目的正是覆盖 FIS 不支持的服务。
• 不要捏造链接。 仅包含实际搜索结果中出现的 URL，或你已阅读过的已知文档页面中的 URL。
• 具体说明服务。 每项建议都应提及具体服务、其高可用性机制以及相关指标。
• 跨领域操作仅作补充参考。 仅在能提供价值时纳入，但应优先关注特定服务的操作和场景库中的场景。
• AWS Knowledge MCP 仅用于文档调研。 不要使用 SearXNG 或其他网络搜索工具。请使用 aws___search_documentation、aws___read_documentation 和 aws___recommend。
• 跨多个主题搜索。 依次使用不同的 topics 值（general、reference_documentation、troubleshooting）。
• 使用 aws___recommend 进行发现。 阅读关键页面后，调用 aws___recommend 查找关键词搜索可能遗漏的相关内容。
• 绝不要并行发送 MCP 请求。 对 aws___search_documentation、aws___read_documentation 和 aws___recommend 的所有调用都必须逐一执行。等待每次响应后再发送下一条请求。并行调用会导致 aws-knowledge-mcp-server 返回“Too many requests”错误。这是最常见的失败原因，每一步都必须严格遵守。
• 失败时重试，最多 10 次。 如果任何 MCP 调用因速率限制或暂时性错误而失败，请等待 5 秒后重试。最多重复 10 次，然后再跳过。
• 遵循语言要求。 使用与用户对话相同的语言输出。