FIS Recommender MCP Server

FIS推荐MCP服务器

一个MCP（模型上下文协议）服务器，根据DevOps代理的发现自动推荐AWS故障注入模拟器（FIS）实验。帮助团队快速设计混沌工程实验，以验证系统的弹性。

特性

• 🔍 分析DevOps发现并建议相关的FIS实验
• 🎯 将问题映射到适当的故障注入操作
• 📋 生成完整的FIS实验模板
• ⚡ 与Kiro CLI和其他MCP客户端无缝集成

部署选项

选项1:MCP服务器（用于DevOps代理）

部署MCP服务器

# Install toolkit
pip install bedrock-agentcore-starter-toolkit

# Configure and deploy
agentcore configure -e server.py --protocol MCP
agentcore launch

Windows注意事项： 如果您看到平台不匹配警告(linux/amd64 对比 linux/arm64)，使用 agentcore launch （不是 agentcore deploy)它通过CodeBuild进行远程跨平台构建。

设置OAuth（Cognito）

python setup_cognito_fis.py

保存输出值：

• 客户端ID -DevOps代理注册所需
• 客户端密钥 -DevOps代理注册所需
• 发现URL -需要为 agentcore configure
• 持有者令牌 -测试所需

在DevOps代理控制台中注册

1. 转到AIDevOps→ 代理→ 设置→ MCP服务器
2. 添加服务器：

- 端点: https://bedrock-agentcore.{REGION}.amazonaws.com/runtimes/{ENCODED_ARN}/invocations - 客户端ID：来自上面的OAuth设置输出 - 客户端密钥：来自上面的OAuth设置输出 - Exchange URL: https://{COGNITO_DOMAIN}.auth.{REGION}.amazoncognito.com/oauth2/token - 授权URL: https://{COGNITO_DOMAIN}.auth.{REGION}.amazoncognito.com/oauth2/authorize - 范围: openid - PKCE：已启用

测试

询问DevOps代理：

"Recommend FIS experiments for network latency issues"

看 安装指南 获取完整的部署说明。

选项2：Lambda客户端（用于API网关、EventBridge）

python deploy_lambda.py

# Test
aws lambda invoke --function-name fis-recommender-mcp-client --region {REGION} \
  --payload '{"tool":"recommend_fis_experiments","arguments":{"finding":{"summary":"network latency"}}}' \
  response.json && cat response.json

看 Lambda部署指南 详细说明。

本地开发

克隆仓库

git clone https://github.com/pimisael/fis-recommender-mcp.git
cd fis-recommender-mcp
chmod +x server.py

配置MCP客户端

适用于Kiro CLI

添加 ~/.kiro/mcp-servers.json:

{
  "mcpServers": {
    "fis-recommender": {
      "command": "python3",
      "args": ["/absolute/path/to/fis-recommender-mcp/server.py"],
      "env": {
        "AWS_REGION": "us-east-1"
      }
    }
  }
}

适用于克劳德桌面

添加 ~/Library/Application Support/Claude/claude_desktop_config.json:

{
  "mcpServers": {
    "fis-recommender": {
      "command": "python3",
      "args": ["/absolute/path/to/fis-recommender-mcp/server.py"],
      "env": {
        "AWS_REGION": "us-east-1"
      }
    }
  }
}

使用示例

示例1：网络延迟问题

提示：

I have a DevOps finding about network latency causing timeouts in my application. 
Can you recommend FIS experiments to test this?

Finding details:
- ID: finding-001
- Summary: "High network latency between services causing request timeouts"
- Type: NETWORK_ISSUE

答复： MCP服务器将建议：

• 行动： aws:network:disrupt-connectivity
• 时长：10分钟
• 目标：网络接口
• 停止条件：CloudWatch错误率报警

示例2：数据库可用性

提示：

Recommend FIS experiments for this finding:
{
  "id": "finding-db-001",
  "summary": "Database connection failures during peak load",
  "type": "DATABASE_ISSUE"
}

答复：

• 行动： aws:rds:reboot-db-instances
• 时长：2分钟
• 目标：RDS实例
• 测试应用程序的数据库故障转移处理

示例3:CPU压力测试

提示：

We had a CPU spike incident. Generate a FIS template to test our auto-scaling.

Finding: "CPU utilization reached 95% causing service degradation"

答复： 使用以下内容完成FIS实验模板：

• EC2实例停止操作
• 3分钟持续时间
• CloudWatch报警停止条件
• 按标签选择目标

示例4：记忆压力

提示：

Create FIS experiments to validate our memory monitoring:
- Finding ID: mem-leak-001
- Issue: Memory leak caused OOM errors
- Need to test alerting and recovery

答复：

• 行动： aws:ssm:send-command （记忆压力）
• 时长：5分钟
• 内存消耗的SSM文档
• 测试监控和自动恢复

独立测试

运行示例脚本以在没有MCP客户端的情况下进行测试：

python3 example.py

这将分析样本结果并显示建议。

支持的查找类型

网络和连接

数据库和存储

计算和实例

ECS和容器

EKS 和 Kubernetes

Lambda和无服务器

Lambda混沌工程最佳实践

冷启动和超时测试：

• 使用 aws:lambda:invocation-add-delay 模拟冷启动场景
• 集 startupDelayMilliseconds 高于函数超时以测试超时处理
• 验证重试逻辑、死信队列和错误处理

错误处理验证：

• 使用 aws:lambda:invocation-error 和 preventExecution: true 在不运行代码的情况下进行测试
• 集 invocationPercentage 逐渐增加故障注入（从10-20%开始）
• 验证CloudWatch火灾警报和监控捕获错误

集成测试：

• 使用 aws:lambda:invocation-http-integration-response 用于ALB、API网关、VPC Lattice
• 使用自定义HTTP状态代码测试上游/下游服务行为
• 验证断路器和回退机制

CI/CD中的连续测试：

• 在AWS CodePipeline部署后自动化Lambda FIS实验
• 使用CloudWatch Synthetics在实验期间监控用户体验
• 根据错误率阈值设置停止条件（例如，错误率>5%）

实验安全：

• 开始在非生产环境中使用合成流量进行实验
• 使用 invocationPercentage 限制爆炸半径的参数
• 将CloudWatch警报配置为停止条件
• 最初在非高峰时段跑步

需监控的关键指标：

• 调用错误和节流阀
• 持续时间和计费持续时间
• 并行执行
• 死信队列消息
• 下游服务健康

缓存和流媒体

API节流

可用性和恢复

可用工具

1.推荐实验

分析DevOps Agent的发现并返回FIS实验建议。

输入：

{
  "finding": {
    "id": "finding-123",
    "summary": "Network latency caused timeouts",
    "type": "AVAILABILITY_ISSUE"
  }
}

输出：

{
  "recommendations": [
    {
      "action": "aws:network:disrupt-connectivity",
      "duration": "PT10M",
      "description": "Simulates network disruption to test timeout handling",
      "targets": ["NetworkInterface"],
      "stopConditions": ["CloudWatch alarm on error rate > 5%"]
    }
  ],
  "finding_id": "finding-123",
  "count": 1
}

2.create_fis_template

生成一个完整的、准备部署的FIS实验模板。

输入：

{
  "recommendation": {
    "action": "aws:ec2:stop-instances",
    "duration": "PT3M",
    "description": "Test instance failure recovery"
  },
  "target_config": {
    "resourceType": "aws:ec2:instance",
    "selectionMode": "COUNT(1)",
    "tags": {
      "Environment": "staging",
      "Team": "platform"
    },
    "roleArn": "arn:aws:iam::123456789012:role/FISRole"
  }
}

输出： 完整的CloudFormation兼容FIS实验模板已准备好部署。

定制

添加新的查找映射

编辑 server.py 并添加到 finding_mappings 字典：

finding_mappings = {
    "disk": {
        "action": "aws:ebs:pause-volume-io",
        "duration": "PT5M",
        "description": "Simulates disk I/O issues"
    },
    # Add your custom mappings here
}

调整持续时间

修改ISO 8601格式的持续时间值：

• PT2M =2分钟
• PT5M =5分钟
• PT10M =10分钟
• PT1H =1小时

需求

• Python 3.10+
• AWS CLI已配置
• 具有适当权限的AWS帐户
• MCP兼容客户端（Kiro CLI、Claude Desktop等）

windows用户

• 所有脚本都是基于Python的，完全跨平台的
• 如果 agentcore configure 回退到容器部署（“找不到zip实用程序”），通过以下方式安装zip choco install zip 或 scoop install zip，然后重新运行。容器部署也有效，但速度较慢。

混沌工程最佳实践

混沌工程飞轮

遵循每个实验的科学方法：

1. 定义稳态 -建立可测量的基线指标（TPS、延迟、错误率）
2. 形式假设 -预测系统将如何响应故障
3. 运行实验 -以受控方式注入故障
4. 验证结果 -将实际行为与假设进行比较
5. 改进 -弥补差距并重新进行实验

实验安全指南

从小处着手，逐步扩大规模：

• 从非生产环境开始
• 在真实客户流量之前使用合成流量
• 从低百分比（10-20%）开始，逐渐增加
• 最初在非高峰时段跑步

实施护栏：

• 将CloudWatch警报设置为停止条件
• 定义明确的回滚程序
• 使用实时仪表板监控爆炸半径
• 实验前与操作团队沟通

范围和影响：

• 明确实验边界
• 使用标签定位特定资源
• 限制并发实验
• 记录预期影响与实际影响

连续混沌测试

在CI/CD中实现自动化：

• 将FIS实验集成到AWS CodePipeline中
• 部署后自动运行实验
• 使用结果来控制生产发布
• 随时间跟踪实验结果

比赛日：

• 安排定期的混沌工程会议
• 模拟真实的故障场景
• 测试事件响应程序
• 验证运行手册和文档

要跟踪的关键指标

系统健康状况：

• 请求成功率（目标：>99.9%）
• 潜伏期百分位数（p50、p95、p99）
• 错误率（4xx、5xx）
• 资源利用率（CPU、内存、连接）

弹性指标：

• 检测故障的时间
• 恢复时间
• 爆炸失效半径
• 级联故障预防

常见故障场景

网络故障：

• 服务之间的分区容忍度
• 跨区域连接丢失
• DNS解析失败
• 延迟和数据包丢失增加

资源枯竭：

• CPU和内存压力
• 连接池耗尽
• 磁盘I/O饱和
• API节流和速率限制

依赖失败：

• 数据库故障转移和复制延迟
• 缓存失效和冷启动
• 第三方API不可用
• 消息队列积压

参考文献

• AWS架构良好的可靠性支柱
• 混沌工程原理
• AWS故障注入模拟器
• 使用AWS FIS和CodePipeline进行混沌测试
• 使用混沌工程验证弹性

许可证

麻省理工学院

贡献

问题和拉取请求欢迎访问https://github.com/pimisael/fis-recommender-mcp