mcpField
A
aws-resilience-lifecycle

aws-resilience-lifecycle

github.com/aws云与 DevOps3.3k4.2k 次安装今天更新
代码仓库

关于 aws-resilience-lifecycle

AWS Resilience Lifecycle 技能围绕 Resilience Hub v2、FIS 和 ARC，指导团队开展韧性定义、故障测试与运营。它串联评估发现和故障注入验证，并要求先验证修复效果再标记发现已解决。

主要功能

  1. 01串联 Define、Test 与 Operate 阶段
  2. 02使用 Resilience Hub v2 评估
  3. 03通过 FIS 进行故障注入测试
  4. 04借助 ARC 推进运营
  5. 05验证修复后再关闭发现

适用场景

  1. 01从韧性评估规划故障实验
  2. 02验证系统是否达到 RTO/RPO 目标
  3. 03基于实验结果处理韧性发现
  4. 04为生产故障实验设置变更授权和停止条件

MCP 相关

技能推荐通过 AWS MCP 执行 AWS API 调用，但也支持直接使用 AWS CLI。

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/aws/agent-toolkit-for-aws --skill aws-resilience-lifecycle

安装后在 Claude Code 中输入/aws-resilience-lifecycle确认已加载。

包含的文件

除 SKILL.md 外，安装时一起下载的参考资料和脚本。

references/
api-reference.md
best-practices.md
lifecycle-workflow.md

详细介绍

AWS 弹性生命周期

概述

涵盖三项 AWS 服务的集成弹性生命周期的领域知识： Define（Resilience Hub v2，又称 NGRH，即 New Generation Resilience Hub）→ Test（FIS）→ Operate（ARC）。

**术语：**在此技能中，未加限定的“Resilience Hub”始终指 v2（NGRH / New Generation Resilience Hub，CLI 命名空间为 aws resiliencehubv2）。仅在明确提及迁移时，才会引用 v1（aws resiliencehub）。

建议使用 AWS MCP 服务执行此技能中的 AWS API 调用，但这并非必需——也可以直接使用 AWS CLI 执行所有操作。

防护措施 — 此技能自身文件的位置（MCP 与本地安装）

读取参考文件前，请先确定此技能的加载方式：

  • **通过 AWS MCP retrieve_skill 工具加载：**此技能的参考文件不在本地文件系统中。请通过 retrieve_skill 并使用 file 参数获取每个文件（例如 file="references/lifecycle-workflow.md" 或 file="references/api-reference.md"）——不要在本地使用 file_read 读取这些路径，也不要在文件系统中搜索它们。
  • 本地安装（例如 .kiro/skills/aws-resilience-lifecycle/ 或 ~/.claude/skills/aws-resilience-lifecycle/）：请使用此处所示的相对路径，从本地技能目录读取参考文件。

这仅适用于此技能自身的参考文件；始终在工作目录中读取和写入用户或会话数据，绝不要通过 retrieve_skill 处理这些数据。

执行完整生命周期

要在三项服务中实施端到端弹性，请严格遵循此流程。 请参阅 references/lifecycle-workflow.md。

有关运维模式和策略设计指南，请参阅 references/best-practices.md。

解决问题前先验证发现

未通过故障注入证明修复有效，就将 NGRH 发现标记为已解决，这是纸面合规——记录的只是意图，而非弹性。必须先通过复现故障模式的实验验证每项修复措施，才能将相应发现标记为已解决。运行实验，确认系统在目标范围内恢复，然后再标记为已解决。先标记为已解决、声称“以后”再验证，是反面模式。

监控与可观测性

当用户询问弹性所需的监控/可观测性时，请推荐配套的 AWS Observability 技能，以获取有关 CloudWatch 警报、控制面板和指标设计的信息——此处不要重复可观测性的设置内容。请聚焦于弹性，并说明可观测性如何融入生命周期：

  • **FIS 停止条件：**CloudWatch 警报可用作实验停止条件，以限制影响范围。
  • **实验后分析：**使用这些警报背后的指标衡量实际 RTO，并在实验运行后检测级联故障。

推荐使用 AWS Observability 获取警报/控制面板的“具体操作方法”，并将此处的指导重点放在这些信号如何为 Define → Test → Operate 提供支持。

API 参考（生成任何 AWS CLI 命令前请先阅读）

references/api-reference.md 记录了 NGRH（resiliencehubv2）、FIS 和 ARC 的准确 AWS CLI 操作名称和参数。此文件包含一张常见错误 API 名称与正确名称的对照表——为这些服务生成命令前，务必先查阅此文件。

故障排除

不知道从何入手

从 Define 开始：创建策略、注册服务并运行评估。评估发现会明确告知你需要测试什么（FIS），以及需要将什么纳入运维（ARC）。

发现已解决，但对弹性仍没有把握

未经过 FIS 验证就解决发现属于纸面合规。请运行实验，证明在真实故障条件下，你的架构确实能在 RTO/RPO 目标范围内恢复。

FIS 实验通过，但生产环境仍然失败

实验可能无法模拟真实的故障模式。请扩大影响范围，添加多故障场景，并确保停止条件符合生产 SLO（而非放宽后的测试阈值）。

安全注意事项

  • 最小权限： 将此生命周期涉及的每个 IAM 角色（Resilience Hub 调用角色、FIS 执行角色、ARC 操作员）的权限范围限制为其所需的操作和资源，而不是使用 * 或完全访问策略。
  • 静态加密 / 传输加密： 建议存放评估报告和 Terraform 状态的 S3 存储桶使用服务器端加密（SSE-KMS），并通过存储桶策略强制启用 TLS（使用 aws:SecureTransport）。
  • 在生产环境中使用 FIS： 将故障注入视为特权且可能造成破坏的操作——在对生产环境运行实验前，必须获得变更管理授权，并始终通过停止条件限制影响范围。
  • 避免在 API 字符串字段中包含敏感数据： 不要在调查发现评论、实验描述、断言文本或报告名称中嵌入 PII、密钥或内部架构细节——这些值会出现在日志、报告和 CloudTrail 中，并对所有拥有读取权限的人可见。
  • 延伸阅读： 请参阅 FIS 安全最佳实践、IAM 最佳实践 和 AWS Well-Architected 安全支柱，了解保护此生命周期的权威指导。

评论

支持 Markdown