Aws Resilience Modeling

Name: Aws Resilience Modeling
Author: aws-samples

aws-samples/sample-aws-resilience-skill

17 installs
9 repo stars
Updated July 29, 2026
aws-samples/sample-aws-resilience-skill

aws-resilience-modeling is a skill that analyzes AWS architecture resilience, identifies failure modes, scores risk, and designs disaster-recovery plans.

About

aws-resilience-modeling conducts AWS system resilience analysis and risk assessment across seven tasks, from component and dependency mapping to failure-mode identification, risk scoring, business impact analysis, and mitigation planning. A developer uses it to find single points of failure, assess RTO/RPO compliance, and produce disaster-recovery plans. It runs read-only through AWS MCP servers or falls back to analyzing IaC, architecture docs, or interactive Q&A.

Runs comprehensive AWS resilience analysis and failure-mode identification
Maps component dependencies, scores risk, and designs DR and mitigation plans
Operates read-only via AWS MCP servers or falls back to IaC and docs analysis

Aws Resilience Modeling by the numbers

17 all-time installs (skills.sh)
Ranked #824 of 1,039 Cloud & Infrastructure skills by installs in the Skillselion catalog
Data as of Jul 30, 2026 (Skillselion catalog sync)

At a glance

aws-resilience-modeling capabilities & compatibility

Capabilities: resilience analysis · failure mode analysis · dependency mapping · disaster recovery planning
Works with: aws
Use cases: devops · research

From the docs

What aws-resilience-modeling says it does

You are a senior AWS Solutions Architect specializing in cloud system resilience assessment and risk management.

SKILL_EN.md

If MCP is not configured, the Skill will automatically fall back to analyzing IaC code, architecture documentation, or interactive Q&A.

SKILL_EN.md

npx skills add https://github.com/aws-samples/sample-aws-resilience-skill --skill aws-resilience-modeling

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

[![Listed on Skillselion](https://skillselion.com/badge/skills/aws-samples/sample-aws-resilience-skill/aws-resilience-modeling.svg)](https://skillselion.com/skills/aws-samples/sample-aws-resilience-skill/aws-resilience-modeling)

Installs	17
repo stars	★ 9
Last updated	July 29, 2026
Repository	aws-samples/sample-aws-resilience-skill ↗

What it does

Analyze an AWS architecture for failure modes, risk priorities, and disaster-recovery planning.

Who is it for?

Architects and SREs assessing AWS system resilience and disaster-recovery readiness

Skip if: Environments requiring write access, since all analysis runs strictly read-only

When should I use this skill?

Performing architecture analysis, identifying failure modes, mapping dependencies, or creating disaster-recovery plans

What you get

A prioritized resilience report with failure modes, risk scores, and a mitigation roadmap

architecture and dependency diagrams
a failure-mode and risk-scoring report
a mitigation strategy and implementation roadmap

By the numbers

7 analysis tasks
9-dimension resilience scoring
4 industry-leading methodologies

Files

assets/
references/
scripts/

SKILL.mdMarkdownGitHub ↗

Language / 语言

If the user speaks English, follow SKILL_EN.md
如果用户使用中文，请遵循 SKILL_ZH.md

Detect the language from the user's message and load the corresponding instruction file.

AWS 系统韧性分析报告

[客户名称] - [环境名称]

分析日期：2025-02-17 分析师：Claude (AWS Resilience Assessment Skill) 版本：1.0

---

执行摘要

概述

本报告对 [客户名称] 的 AWS 生产环境进行了全面的韧性评估，识别了潜在的故障模式，并提供了优先级排序的改进建议。

当前韧性成熟度

总体评分：⭐⭐⭐ (3/5 - 已定义)

维度	评分	说明
架构韧性	⭐⭐⭐⭐	多 AZ 部署，但缺少跨区域 DR
数据韧性	⭐⭐⭐	定期备份，但未测试恢复
运营韧性	⭐⭐	基础监控，缺少自动化恢复
测试韧性	⭐⭐	年度 DR 演练，无混沌工程
合规韧性	⭐⭐⭐	定义 SLA，但无 SLO 跟踪

关键发现（Top 5 风险）

优先级	风险	影响	当前状态
🔴 高	RDS 单区域部署	RTO > 30 分钟	需迁移到 Aurora Global
🔴 高	缺少 Auto Scaling	无法应对流量突增	需配置 Target Tracking
🟡 中	监控覆盖不足	故障检测延迟	需集成 X-Ray 和 Synthetics
🟡 中	未实施 Circuit Breaker	级联故障风险	需在应用层实现
🟢 低	NAT Gateway 单 AZ	单点故障	需多 AZ 部署

优先改进建议（Top 3）

1. 迁移到 Aurora Global Database

预期效果：RTO < 1 分钟，RPO < 1 秒
实施周期：3-4 周
预估成本：+$500-2000/月

2. 实施 Auto Scaling 策略

预期效果：自动应对 3x 流量突增
实施周期：1-2 周
预估成本：变动成本（按需）

3. 建立混沌工程实践

预期效果：每季度验证韧性，提前发现问题
实施周期：持续
预估成本：$100-300/月

预期投资和回报

项目	一次性投资	月度成本	预期收益
基础韧性改进	$10,000	+$500	减少 70% 中断时间
完整韧性改进	$30,000	+$2,000	达到 99.99% 可用性
持续改进计划	$5,000	+$500	持续韧性验证

ROI 分析：

当前估计年度中断损失：$100,000
实施后预期减少：$70,000/年
投资回收期：6 个月

---

1. 系统架构可视化

1.1 当前架构总览

graph TB
    subgraph "AWS Region: us-east-1"
        subgraph "VPC: 10.0.0.0/16"
            subgraph "Public Subnet - AZ-1a"
                ALB1[Application Load Balancer]
                NAT1[NAT Gateway]
            end

            subgraph "Public Subnet - AZ-1b"
                ALB2[ALB - Standby]
            end

            subgraph "Private Subnet - AZ-1a"
                EC2_1a_1[EC2 Instance]
                EC2_1a_2[EC2 Instance]
            end

            subgraph "Private Subnet - AZ-1b"
                EC2_1b_1[EC2 Instance]
                EC2_1b_2[EC2 Instance]
            end

            subgraph "Data Subnet - AZ-1a"
                RDS_Primary[RDS Primary<br/>PostgreSQL]
                Redis_1a[ElastiCache<br/>Redis]
            end

            subgraph "Data Subnet - AZ-1b"
                RDS_Standby[RDS Standby]
                Redis_1b[ElastiCache<br/>Redis]
            end
        end
    end

    Internet[Internet] -->|HTTPS| R53[Route 53]
    R53 -->|Health Check| ALB1
    ALB1 --> EC2_1a_1
    ALB1 --> EC2_1a_2
    ALB1 --> EC2_1b_1
    ALB1 --> EC2_1b_2

    EC2_1a_1 --> RDS_Primary
    EC2_1a_2 --> RDS_Primary
    EC2_1b_1 --> RDS_Primary
    EC2_1b_2 --> RDS_Primary

    EC2_1a_1 --> Redis_1a
    EC2_1a_2 --> Redis_1a
    EC2_1b_1 --> Redis_1b
    EC2_1b_2 --> Redis_1b

    RDS_Primary -.->|Sync Replication| RDS_Standby

    EC2_1a_1 -->|Egress| NAT1
    EC2_1a_2 -->|Egress| NAT1

    classDef spof fill:#ff6b6b,stroke:#c92a2a,stroke-width:3px
    class NAT1,RDS_Primary spof

🚨 识别的单点故障：

NAT Gateway（仅 AZ-1a）
RDS Primary（故障转移需 60-120 秒）

1.2 组件依赖关系图

graph LR
    User[用户请求] --> R53[Route 53]
    R53 --> ALB[Application LB]
    ALB --> App[应用服务器]
    App --> Cache[ElastiCache]
    App --> RDS[RDS 数据库]
    App --> S3[S3 存储]

    App -.->|异步| SQS[SQS 队列]
    SQS -.->|异步| Worker[Worker 服务]

    classDef critical fill:#ff6b6b
    classDef important fill:#ffd93d
    classDef optional fill:#6bcf7f

    class RDS,App critical
    class Cache,ALB important
    class S3,SQS optional

依赖关系说明：

🔴 关键依赖（同步）：RDS、应用服务器
🟡 重要依赖（同步）：ElastiCache、ALB
🟢 可选依赖（异步）：S3、SQS

1.3 数据流图

sequenceDiagram
    participant User as 用户
    participant CF as CloudFront
    participant ALB as Application LB
    participant App as 应用服务器
    participant Cache as ElastiCache
    participant DB as RDS

    User->>CF: 1. HTTPS 请求
    CF->>ALB: 2. 转发（或缓存命中）
    ALB->>App: 3. 负载均衡
    App->>Cache: 4. 检查缓存
    alt 缓存命中
        Cache-->>App: 5a. 返回缓存数据
    else 缓存未命中
        App->>DB: 5b. 查询数据库
        DB-->>App: 6. 返回数据
        App->>Cache: 7. 更新缓存
    end
    App-->>ALB: 8. 返回响应
    ALB-->>CF: 9. 返回响应
    CF-->>User: 10. 返回（并缓存）

1.4 网络拓扑图

graph TB
    subgraph "VPC: prod-vpc (10.0.0.0/16)"
        subgraph "AZ-1a"
            PubSub1a[Public Subnet<br/>10.0.1.0/24]
            PrivSub1a[Private Subnet<br/>10.0.11.0/24]
            DataSub1a[Data Subnet<br/>10.0.21.0/24]
        end

        subgraph "AZ-1b"
            PubSub1b[Public Subnet<br/>10.0.2.0/24]
            PrivSub1b[Private Subnet<br/>10.0.12.0/24]
            DataSub1b[Data Subnet<br/>10.0.22.0/24]
        end

        IGW[Internet Gateway]
        NAT1[NAT Gateway<br/>AZ-1a]

        RouteTablePub[Public Route Table<br/>0.0.0.0/0 → IGW]
        RouteTablePriv[Private Route Table<br/>0.0.0.0/0 → NAT]

        SGWeb[Security Group: Web<br/>Allow 443 from 0.0.0.0/0]
        SGApp[Security Group: App<br/>Allow 8080 from Web SG]
        SGDB[Security Group: DB<br/>Allow 5432 from App SG]
    end

    Internet[Internet] --> IGW
    IGW --> PubSub1a
    IGW --> PubSub1b

    PubSub1a --> RouteTablePub
    PubSub1b --> RouteTablePub

    PrivSub1a --> RouteTablePriv
    PrivSub1b --> RouteTablePriv

    PrivSub1a --> NAT1
    PrivSub1b --> NAT1

    classDef spof fill:#ff6b6b
    class NAT1 spof

网络分析：

✅ 多 AZ 部署（1a、1b）
✅ 分层子网（Public、Private、Data）
✅ 安全组遵循最小权限原则
🚨 NAT Gateway 单 AZ（单点故障）
⚠️ 缺少 VPC Flow Logs（可观测性不足）

---

2. 故障模式识别与分类

📋 以下风险识别基于AWS总结的常见风险检查清单，结合客户实际环境进行评估。

2.1 单点故障 (SPOF)

风险 ID	组件	故障场景	影响	概率	优先级
R-001	NAT Gateway (AZ-1a)	AZ-1a 故障	AZ-1b 实例无法访问互联网	中 (3)	🟡 中
R-002	RDS Primary	硬件故障	60-120s 故障转移延迟	低 (2)	🟡 中
R-003	API Gateway (单区域)	区域故障	完全服务中断	极低 (1)	🔴 高

详细分析：R-003 - API Gateway 单区域部署

当前配置：

Region: us-east-1
Endpoints:
  - API Gateway: https://api.example.com
  - 无跨区域复制
  - 无故障转移机制

故障场景：

us-east-1 区域级故障（历史案例：2017 年 S3 中断）
API Gateway 服务中断

影响：

所有 API 请求失败
100% 用户无法使用服务
业务完全中断

当前缓解措施：

❌ 无

建议改进：参见 6.1 缓解策略 - R-003

2.2 过度延迟

风险 ID	组件	瓶颈点	当前延迟	目标延迟	优先级
R-004	数据库查询	N+1 查询	P95: 500ms	< 200ms	🔴 高
R-005	跨 AZ 调用	网络往返	P95: 5ms	< 2ms	🟢 低

2.3 过度负载

风险 ID	组件	容量限制	当前峰值	预期增长	优先级
R-006	EC2 Auto Scaling	固定容量（4 实例）	80% CPU	流量增长 50%/年	🔴 高
R-007	RDS 连接池	最大 100 连接	峰值 85	预计超限	🟡 中
R-008	API Gateway	10,000 RPS 配额	峰值 8,500	季节性突增	🟡 中

2.4 错误配置

风险 ID	配置项	问题	Well-Architected 违反	优先级
R-009	RDS 备份	保留期 7 天	推荐 30 天	🟢 低
R-010	CloudWatch 日志	未设置保留期	成本优化	🟢 低
R-011	IAM 策略	过于宽松（s3:*）	安全	🟡 中
R-012	未启用 MFA Delete	S3 数据误删风险	可靠性	🟡 中

2.5 共享命运 (Shared Fate)

风险 ID	共享资源	耦合组件	影响范围	优先级
R-013	RDS Primary	所有应用服务	数据库故障影响 100%	🔴 高
R-014	单个 AWS 账户	所有环境	账户级配额、安全	🟡 中
R-015	NAT Gateway	AZ-1b 出站流量	50% 实例无互联网	🟡 中

---

3. 韧性评估（5 星评分）

3.1 RDS 数据库

评估维度	评分	当前状态	差距分析	改进建议
冗余设计	⭐⭐⭐	Multi-AZ 部署	单区域，区域故障 RTO > 30 分钟	迁移到 Aurora Global Database
AZ 容错	⭐⭐⭐⭐	自动故障转移	RTO 60-120 秒	使用 Aurora（RTO < 30s）
超时与重试	⭐⭐⭐	应用层配置 5s 超时	未配置指数退避	实施指数退避重试
断路器	⭐	无	数据库故障导致应用崩溃	实施 Circuit Breaker
自动扩展	⭐⭐	手动扩展	响应慢，需人工干预	启用 Auto Scaling（Aurora）
配置防护	⭐⭐⭐	IaC (Terraform)	未启用 drift 检测	AWS Config 规则
故障隔离	⭐⭐	所有服务共享	无读写分离	实施读副本
备份恢复	⭐⭐⭐	每日自动备份	未测试恢复	季度恢复演练
最佳实践	⭐⭐⭐	部分合规	未加密（静态）	启用加密

综合评分：⭐⭐⭐ (3/5)

3.2 应用服务器 (EC2 / ECS)

评估维度	评分	当前状态	差距分析	改进建议
冗余设计	⭐⭐⭐⭐	多 AZ 部署	配置正确	保持
AZ 容错	⭐⭐⭐⭐	Auto Scaling 跨 AZ	健康检查配置正确	增加预热实例
超时与重试	⭐⭐	部分配置	依赖服务无超时	所有外部调用配置超时
断路器	⭐	无	依赖故障导致级联	集成 resilience4j
自动扩展	⭐⭐	固定容量（4 实例）	无法应对突增	Target Tracking Auto Scaling
配置防护	⭐⭐⭐⭐	CI/CD + IaC	配置审查流程	保持
故障隔离	⭐⭐⭐	微服务架构	部分服务紧耦合	解耦共享依赖
备份恢复	⭐⭐⭐⭐⭐	AMI + 自动化部署	配置完善	保持
最佳实践	⭐⭐⭐⭐	大部分合规	少量优化空间	详见具体建议

综合评分：⭐⭐⭐ (3.2/5)

3.3 汇总评分

总体韧性评分：⭐⭐⭐ (3/5 - 已定义)

成熟度模型：
├─ Level 1: 初始（被动响应）
├─ Level 2: 可重复（有记录流程）
├─ Level 3: 已定义（标准化流程）✅ 当前
├─ Level 4: 管理（量化管理）    ← 目标
└─ Level 5: 优化（持续改进）

---

4. 业务影响分析

4.1 关键业务功能映射

业务功能	依赖组件	优先级	当前 RTO	当前 RPO	目标 RTO	目标 RPO
用户登录/注册	ALB + App + RDS	P0	2 分钟	5 分钟	1 分钟	1 分钟
订单处理	ALB + App + RDS + SQS	P0	5 分钟	5 分钟	2 分钟	0 秒
支付交易	第三方 API + App + RDS	P0	5 分钟	0 秒	1 分钟	0 秒
库存查询	ALB + App + Cache + RDS	P1	10 分钟	N/A	5 分钟	N/A
报表生成	Worker + RDS	P2	1 小时	1 小时	30 分钟	30 分钟

4.2 组件故障影响矩阵

组件	故障场景	影响的业务功能	影响程度	用户影响	当前 RTO
RDS Primary	AZ 故障	所有写操作	严重	100% 无法下单	2 分钟
ALB	配置错误	所有流量	严重	100% 无法访问	10 分钟
ElastiCache	节点故障	用户会话、缓存	中等	需重新登录，查询变慢	即时（降级）
NAT Gateway	AZ-1a 故障	AZ-1b 出站流量	中等	50% 实例无法调用第三方 API	15 分钟
SQS 队列	队列延迟	异步任务处理	轻微	报表延迟	不影响实时

4.3 RTO/RPO 合规性分析

当前架构 vs 业务目标：

业务功能：订单处理
├─ 业务目标：RTO < 2 分钟，RPO = 0 秒
├─ 当前能力：RTO ~ 5 分钟，RPO ~ 5 分钟
└─ 差距：❌ 不符合

原因分析：
1. RDS Multi-AZ 故障转移需要 60-120 秒
2. 应用重连数据库需要 30-60 秒
3. 健康检查检测延迟 30 秒
4. RPO 取决于 RDS 备份频率（5 分钟）

改进建议：
1. 迁移到 Aurora（故障转移 < 30 秒）
2. 应用实现快速重连（连接池）
3. 减少健康检查间隔（15 秒）
4. 启用 Aurora Backtrack（RPO = 0）

合规性总结：

业务功能	目标 RTO	当前 RTO	合规性	差距
用户登录	1 分钟	2 分钟	❌	-1 分钟
订单处理	2 分钟	5 分钟	❌	-3 分钟
支付交易	1 分钟	5 分钟	❌	-4 分钟
库存查询	5 分钟	10 分钟	❌	-5 分钟
报表生成	30 分钟	1 小时	❌	-30 分钟

结论：当前架构无法满足任何业务功能的 RTO/RPO 目标，需要紧急改进。

---

5. 风险优先级排序

5.1 风险评分矩阵

评分公式：

风险得分 = (发生概率 × 业务影响 × 检测难度) / 修复复杂度

其中：
- 发生概率：1-5（1=极低，5=极高）
- 业务影响：1-5（1=轻微，5=严重）
- 检测难度：1-5（1=易检测，5=难检测）
- 修复复杂度：1-5（1=简单，5=复杂）

5.2 风险清单（按优先级排序）

排名	风险 ID	风险描述	概率	影响	检测	修复	得分	优先级
1	R-013	RDS 单区域部署	2	5	2	3	6.67	🔴 高
2	R-006	缺少 Auto Scaling	4	4	1	2	8.00	🔴 高
3	R-004	数据库 N+1 查询	5	3	2	2	15.00	🔴 高
4	R-003	API 单区域部署	1	5	2	4	2.50	🟡 中
5	R-007	RDS 连接池限制	3	4	2	1	24.00	🟡 中
6	R-001	NAT Gateway 单 AZ	3	3	1	1	9.00	🟡 中
7	R-014	单账户架构	2	3	3	5	3.60	🟢 低
8	R-009	RDS 备份保留期短	2	2	1	1	4.00	🟢 低

5.3 风险可视化矩阵

影响 ↑
5 │     [R-013]           [R-003]
4 │  [R-006] [R-007]
3 │        [R-004]    [R-001]
  │                   [R-014]
2 │ [R-009]
1 │
  └─────────────────────────────→ 概率
    1    2    3    4    5

图例：
🔴 高优先级（风险得分 > 5）
🟡 中优先级（风险得分 2-5）
🟢 低优先级（风险得分 < 2）

5.4 级联效应分析

场景：us-east-1 区域故障

graph TD
    A[us-east-1 区域故障] --> B[API Gateway 不可用]
    A --> C[RDS Primary 不可用]
    A --> D[ElastiCache 不可用]
    A --> E[NAT Gateway 不可用]

    B --> F[100% API 请求失败]
    C --> G[所有写操作失败]
    D --> H[缓存未命中，数据库负载增加]
    E --> I[无法调用第三方 API]

    F --> J[完全业务中断]
    G --> J
    H --> J
    I --> J

    J --> K[预估损失：$50,000/小时]

    classDef critical fill:#ff6b6b
    class A,J,K critical

结论：

单区域架构存在严重的级联故障风险
区域故障导致完全业务中断
建议：实施多区域 DR 策略（至少导航灯模式）

---

（报告后续部分包括：缓解策略建议、实施路线图、持续改进计划、附录等，格式类似）

---

说明

这是一个示例模板，展示了最终报告的格式和内容。实际分析时会根据你的具体环境和需求进行定制。

报告的其他部分（6-9 节）将包含：

详细的缓解策略（含架构图、代码、命令）
分阶段实施路线图（Gantt 图、资源需求）
持续改进计划（SLO/SLI、事后复盘、混沌工程）
附录（完整资源清单、配置审计、术语表）

完整报告通常为 30-50 页，包含大量可视化图表和可执行的代码示例。

AWS System Resilience Analysis Report

[Customer Name] - [Environment Name]

Analysis Date: 2025-02-17 Analyst: Claude (AWS Resilience Assessment Skill) Version: 1.0

---

Executive Summary

Overview

This report provides a comprehensive resilience assessment of [Customer Name]'s AWS production environment, identifying potential failure modes and providing prioritized improvement recommendations.

Current Resilience Maturity

Overall Score: 3/5 - Defined

Dimension	Score	Description
Architecture Resilience	4/5	Multi-AZ deployment, but no cross-region DR
Data Resilience	3/5	Regular backups, but recovery not tested
Operational Resilience	2/5	Basic monitoring, no automated recovery
Testing Resilience	2/5	Annual DR drills, no chaos engineering
Compliance Resilience	3/5	SLA defined, but no SLO tracking

Key Findings (Top 5 Risks)

Priority	Risk	Impact	Current Status
High	RDS single-region deployment	RTO > 30 min	Need to migrate to Aurora Global
High	Missing Auto Scaling	Cannot handle traffic spikes	Need Target Tracking configuration
Medium	Insufficient monitoring coverage	Delayed fault detection	Need X-Ray and Synthetics integration
Medium	No Circuit Breaker implemented	Cascading failure risk	Need application-layer implementation
Low	NAT Gateway single AZ	Single point of failure	Need multi-AZ deployment

Priority Improvement Recommendations (Top 3)

1. Migrate to Aurora Global Database

Expected Outcome: RTO < 1 minute, RPO < 1 second
Implementation Timeline: 3-4 weeks
Estimated Cost: +$500-2000/month

2. Implement Auto Scaling Strategy

Expected Outcome: Automatically handle 3x traffic spikes
Implementation Timeline: 1-2 weeks
Estimated Cost: Variable (on-demand)

3. Establish Chaos Engineering Practice

Expected Outcome: Quarterly resilience verification, proactive issue discovery
Implementation Timeline: Ongoing
Estimated Cost: $100-300/month

Expected Investment and Return

Item	One-time Investment	Monthly Cost	Expected Benefit
Foundation Resilience Improvements	$10,000	+$500	70% reduction in downtime
Complete Resilience Improvements	$30,000	+$2,000	Achieve 99.99% availability
Continuous Improvement Plan	$5,000	+$500	Continuous resilience verification

ROI Analysis:

Estimated annual outage losses: $100,000
Expected reduction after implementation: $70,000/year
Payback period: 6 months

---

1. System Architecture Visualization

1.1 Current Architecture Overview

graph TB
    subgraph "AWS Region: us-east-1"
        subgraph "VPC: 10.0.0.0/16"
            subgraph "Public Subnet - AZ-1a"
                ALB1[Application Load Balancer]
                NAT1[NAT Gateway]
            end

            subgraph "Public Subnet - AZ-1b"
                ALB2[ALB - Standby]
            end

            subgraph "Private Subnet - AZ-1a"
                EC2_1a_1[EC2 Instance]
                EC2_1a_2[EC2 Instance]
            end

            subgraph "Private Subnet - AZ-1b"
                EC2_1b_1[EC2 Instance]
                EC2_1b_2[EC2 Instance]
            end

            subgraph "Data Subnet - AZ-1a"
                RDS_Primary[RDS Primary<br/>PostgreSQL]
                Redis_1a[ElastiCache<br/>Redis]
            end

            subgraph "Data Subnet - AZ-1b"
                RDS_Standby[RDS Standby]
                Redis_1b[ElastiCache<br/>Redis]
            end
        end
    end

    Internet[Internet] -->|HTTPS| R53[Route 53]
    R53 -->|Health Check| ALB1
    ALB1 --> EC2_1a_1
    ALB1 --> EC2_1a_2
    ALB1 --> EC2_1b_1
    ALB1 --> EC2_1b_2

    EC2_1a_1 --> RDS_Primary
    EC2_1a_2 --> RDS_Primary
    EC2_1b_1 --> RDS_Primary
    EC2_1b_2 --> RDS_Primary

    EC2_1a_1 --> Redis_1a
    EC2_1a_2 --> Redis_1a
    EC2_1b_1 --> Redis_1b
    EC2_1b_2 --> Redis_1b

    RDS_Primary -.->|Sync Replication| RDS_Standby

    EC2_1a_1 -->|Egress| NAT1
    EC2_1a_2 -->|Egress| NAT1

    classDef spof fill:#ff6b6b,stroke:#c92a2a,stroke-width:3px
    class NAT1,RDS_Primary spof

Identified Single Points of Failure:

NAT Gateway (AZ-1a only)
RDS Primary (failover requires 60-120 seconds)

1.2 Component Dependency Diagram

graph LR
    User[User Request] --> R53[Route 53]
    R53 --> ALB[Application LB]
    ALB --> App[Application Servers]
    App --> Cache[ElastiCache]
    App --> RDS[RDS Database]
    App --> S3[S3 Storage]

    App -.->|Async| SQS[SQS Queue]
    SQS -.->|Async| Worker[Worker Service]

    classDef critical fill:#ff6b6b
    classDef important fill:#ffd93d
    classDef optional fill:#6bcf7f

    class RDS,App critical
    class Cache,ALB important
    class S3,SQS optional

Dependency Description:

Critical dependencies (synchronous): RDS, Application Servers
Important dependencies (synchronous): ElastiCache, ALB
Optional dependencies (asynchronous): S3, SQS

1.3 Data Flow Diagram

sequenceDiagram
    participant User as User
    participant CF as CloudFront
    participant ALB as Application LB
    participant App as Application Server
    participant Cache as ElastiCache
    participant DB as RDS

    User->>CF: 1. HTTPS Request
    CF->>ALB: 2. Forward (or cache hit)
    ALB->>App: 3. Load Balance
    App->>Cache: 4. Check Cache
    alt Cache Hit
        Cache-->>App: 5a. Return Cached Data
    else Cache Miss
        App->>DB: 5b. Query Database
        DB-->>App: 6. Return Data
        App->>Cache: 7. Update Cache
    end
    App-->>ALB: 8. Return Response
    ALB-->>CF: 9. Return Response
    CF-->>User: 10. Return (and Cache)

1.4 Network Topology Diagram

graph TB
    subgraph "VPC: prod-vpc (10.0.0.0/16)"
        subgraph "AZ-1a"
            PubSub1a[Public Subnet<br/>10.0.1.0/24]
            PrivSub1a[Private Subnet<br/>10.0.11.0/24]
            DataSub1a[Data Subnet<br/>10.0.21.0/24]
        end

        subgraph "AZ-1b"
            PubSub1b[Public Subnet<br/>10.0.2.0/24]
            PrivSub1b[Private Subnet<br/>10.0.12.0/24]
            DataSub1b[Data Subnet<br/>10.0.22.0/24]
        end

        IGW[Internet Gateway]
        NAT1[NAT Gateway<br/>AZ-1a]

        RouteTablePub[Public Route Table<br/>0.0.0.0/0 -> IGW]
        RouteTablePriv[Private Route Table<br/>0.0.0.0/0 -> NAT]

        SGWeb[Security Group: Web<br/>Allow 443 from 0.0.0.0/0]
        SGApp[Security Group: App<br/>Allow 8080 from Web SG]
        SGDB[Security Group: DB<br/>Allow 5432 from App SG]
    end

    Internet[Internet] --> IGW
    IGW --> PubSub1a
    IGW --> PubSub1b

    PubSub1a --> RouteTablePub
    PubSub1b --> RouteTablePub

    PrivSub1a --> RouteTablePriv
    PrivSub1b --> RouteTablePriv

    PrivSub1a --> NAT1
    PrivSub1b --> NAT1

    classDef spof fill:#ff6b6b
    class NAT1 spof

Network Analysis:

Multi-AZ deployment (1a, 1b)
Layered subnets (Public, Private, Data)
Security groups follow least privilege principle
NAT Gateway single AZ (single point of failure)
Missing VPC Flow Logs (insufficient observability)

---

2. Failure Mode Identification and Classification

The following risk identification is based on AWS common risk checklists, assessed against the customer's actual environment.

2.1 Single Point of Failure (SPOF)

Risk ID	Component	Failure Scenario	Impact	Probability	Priority
R-001	NAT Gateway (AZ-1a)	AZ-1a failure	AZ-1b instances cannot access internet	Medium (3)	Medium
R-002	RDS Primary	Hardware failure	60-120s failover delay	Low (2)	Medium
R-003	API Gateway (single region)	Regional failure	Complete service outage	Very Low (1)	High

Detailed Analysis: R-003 - API Gateway Single-Region Deployment

Current Configuration:

Region: us-east-1
Endpoints:
  - API Gateway: https://api.example.com
  - No cross-region replication
  - No failover mechanism

Failure Scenario:

us-east-1 regional failure (historical case: 2017 S3 outage)
API Gateway service disruption

Impact:

All API requests fail
100% of users unable to use the service
Complete business interruption

Current Mitigations:

None

Recommended Improvements: See 6.1 Mitigation Strategy - R-003

2.2 Excessive Latency

Risk ID	Component	Bottleneck	Current Latency	Target Latency	Priority
R-004	Database Queries	N+1 Queries	P95: 500ms	< 200ms	High
R-005	Cross-AZ Calls	Network Round-trip	P95: 5ms	< 2ms	Low

2.3 Excessive Load

Risk ID	Component	Capacity Limit	Current Peak	Expected Growth	Priority
R-006	EC2 Auto Scaling	Fixed capacity (4 instances)	80% CPU	50%/year traffic growth	High
R-007	RDS Connection Pool	Max 100 connections	Peak 85	Expected to exceed	Medium
R-008	API Gateway	10,000 RPS quota	Peak 8,500	Seasonal spikes	Medium

2.4 Misconfiguration

Risk ID	Configuration Item	Issue	Well-Architected Violation	Priority
R-009	RDS Backup	7-day retention period	Recommended 30 days	Low
R-010	CloudWatch Logs	No retention period set	Cost optimization	Low
R-011	IAM Policy	Too permissive (s3:*)	Security	Medium
R-012	MFA Delete not enabled	S3 data accidental deletion risk	Reliability	Medium

2.5 Shared Fate

Risk ID	Shared Resource	Coupled Components	Impact Scope	Priority
R-013	RDS Primary	All application services	Database failure affects 100%	High
R-014	Single AWS Account	All environments	Account-level quotas, security	Medium
R-015	NAT Gateway	AZ-1b outbound traffic	50% of instances without internet	Medium

---

3. Resilience Assessment (5-Star Rating)

3.1 RDS Database

Assessment Dimension	Score	Current Status	Gap Analysis	Improvement Recommendation
Redundancy Design	3/5	Multi-AZ deployment	Single region, regional failure RTO > 30 min	Migrate to Aurora Global Database
AZ Fault Tolerance	4/5	Automatic failover	RTO 60-120 seconds	Use Aurora (RTO < 30s)
Timeout & Retry	3/5	Application-layer 5s timeout	No exponential backoff	Implement exponential backoff retry
Circuit Breaker	1/5	None	Database failure crashes application	Implement Circuit Breaker
Auto Scaling	2/5	Manual scaling	Slow response, requires manual intervention	Enable Auto Scaling (Aurora)
Configuration Safeguards	3/5	IaC (Terraform)	No drift detection enabled	AWS Config rules
Fault Isolation	2/5	All services shared	No read-write separation	Implement read replicas
Backup & Recovery	3/5	Daily automated backup	Recovery not tested	Quarterly recovery drills
Best Practices	3/5	Partially compliant	Not encrypted (at rest)	Enable encryption

Composite Score: 3/5

3.2 Application Servers (EC2 / ECS)

Assessment Dimension	Score	Current Status	Gap Analysis	Improvement Recommendation
Redundancy Design	4/5	Multi-AZ deployment	Correctly configured	Maintain
AZ Fault Tolerance	4/5	Auto Scaling across AZs	Health checks correctly configured	Add warm instances
Timeout & Retry	2/5	Partially configured	No timeouts for dependency services	Configure timeouts for all external calls
Circuit Breaker	1/5	None	Dependency failures cause cascading	Integrate resilience4j
Auto Scaling	2/5	Fixed capacity (4 instances)	Cannot handle spikes	Target Tracking Auto Scaling
Configuration Safeguards	4/5	CI/CD + IaC	Configuration review process	Maintain
Fault Isolation	3/5	Microservices architecture	Some services tightly coupled	Decouple shared dependencies
Backup & Recovery	5/5	AMI + automated deployment	Well configured	Maintain
Best Practices	4/5	Mostly compliant	Minor optimization opportunities	See specific recommendations

Composite Score: 3.2/5

3.3 Summary Scores

Overall Resilience Score: 3/5 - Defined

Maturity Model:
+- Level 1: Initial (reactive response)
+- Level 2: Repeatable (documented processes)
+- Level 3: Defined (standardized processes)  <- Current
+- Level 4: Managed (quantitatively managed)  <- Target
+- Level 5: Optimized (continuous improvement)

---

4. Business Impact Analysis

4.1 Critical Business Function Mapping

Business Function	Dependencies	Priority	Current RTO	Current RPO	Target RTO	Target RPO
User Login/Registration	ALB + App + RDS	P0	2 min	5 min	1 min	1 min
Order Processing	ALB + App + RDS + SQS	P0	5 min	5 min	2 min	0 sec
Payment Transactions	Third-party API + App + RDS	P0	5 min	0 sec	1 min	0 sec
Inventory Queries	ALB + App + Cache + RDS	P1	10 min	N/A	5 min	N/A
Report Generation	Worker + RDS	P2	1 hour	1 hour	30 min	30 min

4.2 Component Failure Impact Matrix

Component	Failure Scenario	Affected Business Functions	Impact Severity	User Impact	Current RTO
RDS Primary	AZ failure	All write operations	Critical	100% unable to place orders	2 min
ALB	Misconfiguration	All traffic	Critical	100% unable to access	10 min
ElastiCache	Node failure	User sessions, cache	Medium	Need to re-login, queries slower	Immediate (degraded)
NAT Gateway	AZ-1a failure	AZ-1b outbound traffic	Medium	50% instances cannot call third-party APIs	15 min
SQS Queue	Queue delay	Async task processing	Minor	Report delays	No real-time impact

4.3 RTO/RPO Compliance Analysis

Current Architecture vs. Business Targets:

Business Function: Order Processing
+- Business Target: RTO < 2 min, RPO = 0 sec
+- Current Capability: RTO ~ 5 min, RPO ~ 5 min
+- Gap: Does not comply

Root Cause Analysis:
1. RDS Multi-AZ failover requires 60-120 seconds
2. Application database reconnection requires 30-60 seconds
3. Health check detection delay 30 seconds
4. RPO depends on RDS backup frequency (5 minutes)

Improvement Recommendations:
1. Migrate to Aurora (failover < 30 seconds)
2. Implement fast reconnection at application layer (connection pooling)
3. Reduce health check interval (15 seconds)
4. Enable Aurora Backtrack (RPO = 0)

Compliance Summary:

Business Function	Target RTO	Current RTO	Compliance	Gap
User Login	1 min	2 min	No	-1 min
Order Processing	2 min	5 min	No	-3 min
Payment Transactions	1 min	5 min	No	-4 min
Inventory Queries	5 min	10 min	No	-5 min
Report Generation	30 min	1 hour	No	-30 min

Conclusion: The current architecture cannot meet the RTO/RPO targets for any business function and requires urgent improvement.

---

5. Risk Prioritization

5.1 Risk Scoring Matrix

Scoring Formula:

Risk Score = (Probability x Business Impact x Detection Difficulty) / Remediation Complexity

Where:
- Probability: 1-5 (1=very low, 5=very high)
- Business Impact: 1-5 (1=minor, 5=critical)
- Detection Difficulty: 1-5 (1=easy to detect, 5=hard to detect)
- Remediation Complexity: 1-5 (1=simple, 5=complex)

5.2 Risk Inventory (Sorted by Priority)

Rank	Risk ID	Risk Description	Probability	Impact	Detection	Remediation	Score	Priority
1	R-013	RDS single-region deployment	2	5	2	3	6.67	High
2	R-006	Missing Auto Scaling	4	4	1	2	8.00	High
3	R-004	Database N+1 queries	5	3	2	2	15.00	High
4	R-003	API single-region deployment	1	5	2	4	2.50	Medium
5	R-007	RDS connection pool limit	3	4	2	1	24.00	Medium
6	R-001	NAT Gateway single AZ	3	3	1	1	9.00	Medium
7	R-014	Single account architecture	2	3	3	5	3.60	Low
8	R-009	Short RDS backup retention	2	2	1	1	4.00	Low

5.3 Risk Visualization Matrix

Impact
5 |     [R-013]           [R-003]
4 |  [R-006] [R-007]
3 |        [R-004]    [R-001]
  |                   [R-014]
2 | [R-009]
1 |
  +--------------------------------> Probability
    1    2    3    4    5

Legend:
  High priority (risk score > 5)
  Medium priority (risk score 2-5)
  Low priority (risk score < 2)

5.4 Cascading Effect Analysis

Scenario: us-east-1 Regional Failure

graph TD
    A[us-east-1 Regional Failure] --> B[API Gateway Unavailable]
    A --> C[RDS Primary Unavailable]
    A --> D[ElastiCache Unavailable]
    A --> E[NAT Gateway Unavailable]

    B --> F[100% API Requests Fail]
    C --> G[All Write Operations Fail]
    D --> H[Cache Misses, Database Load Increases]
    E --> I[Cannot Call Third-Party APIs]

    F --> J[Complete Business Outage]
    G --> J
    H --> J
    I --> J

    J --> K[Estimated Loss: $50,000/hour]

    classDef critical fill:#ff6b6b
    class A,J,K critical

Conclusion:

Single-region architecture has serious cascading failure risks
Regional failure leads to complete business outage
Recommendation: Implement multi-region DR strategy (at minimum Pilot Light)

---

(Subsequent report sections include: Mitigation Strategy Recommendations, Implementation Roadmap, Continuous Improvement Plan, Appendices, etc., in similar format)

---

Notes

This is a sample template demonstrating the format and content of the final report. The actual analysis will be customized based on your specific environment and requirements.

The remaining sections (6-9) of the report will include:

Detailed mitigation strategies (with architecture diagrams, code, commands)
Phased implementation roadmap (Gantt chart, resource requirements)
Continuous improvement plan (SLO/SLI, postmortems, chaos engineering)
Appendices (complete resource inventory, configuration audit, glossary)

A complete report typically spans 30-50 pages, with extensive visualizations and executable code examples.

<!DOCTYPE html>
<html lang="zh-CN">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>AWS 系统韧性评估报告</title>
    <script src="https://cdn.jsdelivr.net/npm/chart.js@4.4.0/dist/chart.umd.min.js"></script>
    <script src="https://cdn.jsdelivr.net/npm/mermaid@10/dist/mermaid.min.js"></script>
    <style>
        * {
            margin: 0;
            padding: 0;
            box-sizing: border-box;
        }

        body {
            font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', 'PingFang SC', 'Microsoft YaHei', sans-serif;
            line-height: 1.6;
            color: #232f3e;
            background: linear-gradient(135deg, #f5f5f5 0%, #e9ecef 100%);
            padding: 20px;
        }

        .container {
            max-width: 1400px;
            margin: 0 auto;
            background: white;
            box-shadow: 0 4px 20px rgba(0,0,0,0.1);
            border-radius: 12px;
            overflow: hidden;
        }

        .header {
            background: linear-gradient(135deg, #232f3e 0%, #37475a 100%);
            color: white;
            padding: 40px;
            position: relative;
            overflow: hidden;
        }

        .header::before {
            content: '';
            position: absolute;
            top: -50%;
            right: -50%;
            width: 200%;
            height: 200%;
            background: radial-gradient(circle, rgba(255,153,0,0.1) 0%, transparent 70%);
            animation: pulse 15s ease-in-out infinite;
        }

        @keyframes pulse {
            0%, 100% { transform: scale(1); }
            50% { transform: scale(1.1); }
        }

        .header-content {
            position: relative;
            z-index: 1;
        }

        h1 {
            font-size: 2.5em;
            margin-bottom: 10px;
            color: white;
        }

        .subtitle {
            font-size: 1.2em;
            opacity: 0.9;
            margin-bottom: 20px;
        }

        .meta-info {
            display: grid;
            grid-template-columns: repeat(auto-fit, minmax(200px, 1fr));
            gap: 15px;
            margin-top: 20px;
        }

        .meta-item {
            background: rgba(255,255,255,0.1);
            padding: 10px 15px;
            border-radius: 8px;
            backdrop-filter: blur(10px);
        }

        .meta-label {
            font-size: 0.85em;
            opacity: 0.8;
            margin-bottom: 5px;
        }

        .meta-value {
            font-size: 1.1em;
            font-weight: bold;
        }

        .content {
            padding: 40px;
        }

        h2 {
            color: #232f3e;
            font-size: 2em;
            margin-top: 40px;
            margin-bottom: 20px;
            padding-left: 15px;
            border-left: 5px solid #ff9900;
        }

        h3 {
            color: #232f3e;
            font-size: 1.5em;
            margin-top: 30px;
            margin-bottom: 15px;
        }

        h4 {
            color: #545b64;
            font-size: 1.2em;
            margin-top: 20px;
            margin-bottom: 10px;
        }

        .score-banner {
            background: linear-gradient(135deg, #ff9900 0%, #ff8c00 100%);
            color: white;
            padding: 40px;
            border-radius: 12px;
            text-align: center;
            margin: 30px 0;
            box-shadow: 0 6px 20px rgba(255,140,0,0.3);
            position: relative;
            overflow: hidden;
        }

        .score-banner::before {
            content: '';
            position: absolute;
            top: -50%;
            left: -50%;
            width: 200%;
            height: 200%;
            background: radial-gradient(circle, rgba(255,255,255,0.2) 0%, transparent 70%);
        }

        .score-banner-content {
            position: relative;
            z-index: 1;
        }

        .score-value {
            font-size: 5em;
            font-weight: bold;
            margin: 20px 0;
            text-shadow: 2px 2px 4px rgba(0,0,0,0.2);
        }

        .score-stars {
            font-size: 3em;
            margin: 10px 0;
        }

        .dashboard {
            display: grid;
            grid-template-columns: repeat(auto-fit, minmax(250px, 1fr));
            gap: 20px;
            margin: 30px 0;
        }

        .stat-card {
            background: linear-gradient(135deg, white 0%, #f8f9fa 100%);
            border: 2px solid #e0e0e0;
            border-radius: 12px;
            padding: 25px;
            text-align: center;
            box-shadow: 0 4px 15px rgba(0,0,0,0.08);
            transition: transform 0.3s ease, box-shadow 0.3s ease;
            position: relative;
            overflow: hidden;
        }

        .stat-card::before {
            content: '';
            position: absolute;
            top: 0;
            left: 0;
            width: 100%;
            height: 4px;
            background: linear-gradient(90deg, #ff9900 0%, #ff8c00 100%);
        }

        .stat-card:hover {
            transform: translateY(-5px);
            box-shadow: 0 8px 25px rgba(0,0,0,0.15);
        }

        .stat-icon {
            font-size: 3em;
            margin-bottom: 15px;
        }

        .stat-value {
            font-size: 2.5em;
            font-weight: bold;
            color: #232f3e;
            margin: 10px 0;
        }

        .stat-label {
            font-size: 1em;
            color: #545b64;
        }

        .risk-card {
            background: white;
            border: 2px solid #e0e0e0;
            border-left: 6px solid;
            border-radius: 8px;
            padding: 25px;
            margin: 20px 0;
            box-shadow: 0 4px 12px rgba(0,0,0,0.08);
            transition: transform 0.2s ease;
        }

        .risk-card:hover {
            transform: translateX(5px);
        }

        .risk-critical {
            border-left-color: #d13212;
            background: linear-gradient(to right, rgba(209,50,18,0.05) 0%, white 100%);
        }

        .risk-high {
            border-left-color: #ff9900;
            background: linear-gradient(to right, rgba(255,153,0,0.05) 0%, white 100%);
        }

        .risk-medium {
            border-left-color: #f7b500;
            background: linear-gradient(to right, rgba(247,181,0,0.05) 0%, white 100%);
        }

        .risk-low {
            border-left-color: #1d8102;
            background: linear-gradient(to right, rgba(29,129,2,0.05) 0%, white 100%);
        }

        .risk-header {
            display: flex;
            justify-content: space-between;
            align-items: center;
            margin-bottom: 15px;
        }

        .risk-title {
            font-size: 1.3em;
            font-weight: bold;
            color: #232f3e;
        }

        .risk-badge {
            display: inline-block;
            padding: 6px 15px;
            border-radius: 20px;
            font-size: 0.9em;
            font-weight: bold;
        }

        .badge-critical {
            background: #d13212;
            color: white;
        }

        .badge-high {
            background: #ff9900;
            color: white;
        }

        .badge-medium {
            background: #f7b500;
            color: #232f3e;
        }

        .badge-low {
            background: #1d8102;
            color: white;
        }

        .chart-container {
            position: relative;
            height: 500px;
            margin: 30px auto;
            background: white;
            border-radius: 12px;
            padding: 20px;
            box-shadow: 0 4px 12px rgba(0,0,0,0.08);
        }

        .chart-row {
            display: grid;
            grid-template-columns: repeat(auto-fit, minmax(500px, 1fr));
            gap: 30px;
            margin: 30px 0;
        }

        table {
            width: 100%;
            border-collapse: separate;
            border-spacing: 0;
            margin: 20px 0;
            box-shadow: 0 4px 12px rgba(0,0,0,0.08);
            border-radius: 8px;
            overflow: hidden;
        }

        thead {
            background: linear-gradient(135deg, #232f3e 0%, #37475a 100%);
            color: white;
        }

        th {
            padding: 15px;
            text-align: left;
            font-weight: bold;
            font-size: 0.95em;
        }

        td {
            padding: 12px 15px;
            border-bottom: 1px solid #e0e0e0;
        }

        tbody tr {
            transition: background-color 0.2s ease;
        }

        tbody tr:nth-child(even) {
            background: #f8f9fa;
        }

        tbody tr:hover {
            background: #fff3e0;
        }

        .mermaid {
            background: white;
            border-radius: 12px;
            padding: 30px;
            margin: 30px 0;
            box-shadow: 0 4px 12px rgba(0,0,0,0.08);
        }

        .alert {
            padding: 20px 25px;
            margin: 20px 0;
            border-radius: 8px;
            border-left: 5px solid;
            box-shadow: 0 2px 8px rgba(0,0,0,0.08);
        }

        .alert-danger {
            background: #fff5f5;
            border-color: #d13212;
            color: #a02a1b;
        }

        .alert-warning {
            background: #fff8e5;
            border-color: #ff9900;
            color: #995c00;
        }

        .alert-success {
            background: #f0f8f0;
            border-color: #1d8102;
            color: #0d5201;
        }

        .alert-info {
            background: #e7f3ff;
            border-color: #0073bb;
            color: #004876;
        }

        .recommendation-section {
            background: linear-gradient(135deg, #f0f8ff 0%, #e7f3ff 100%);
            border: 2px solid #0073bb;
            border-radius: 12px;
            padding: 25px;
            margin: 30px 0;
        }

        .recommendation-section h3 {
            color: #0073bb;
            margin-top: 0;
        }

        code {
            background: #f4f4f4;
            padding: 3px 8px;
            border-radius: 4px;
            font-family: 'Courier New', monospace;
            font-size: 0.9em;
            color: #e01e5a;
        }

        pre {
            background: #2d2d2d;
            color: #f8f8f2;
            padding: 20px;
            border-radius: 8px;
            overflow-x: auto;
            border-left: 4px solid #ff9900;
            box-shadow: 0 4px 12px rgba(0,0,0,0.15);
        }

        pre code {
            background: none;
            color: inherit;
            padding: 0;
        }

        ul, ol {
            margin: 15px 0 15px 30px;
        }

        li {
            margin: 10px 0;
        }

        .footer {
            background: #f8f9fa;
            padding: 30px 40px;
            text-align: center;
            color: #545b64;
            border-top: 3px solid #ff9900;
        }

        .progress-bar {
            width: 100%;
            height: 40px;
            background: #e0e0e0;
            border-radius: 20px;
            overflow: hidden;
            margin: 15px 0;
            box-shadow: inset 0 2px 4px rgba(0,0,0,0.1);
        }

        .progress-fill {
            height: 100%;
            background: linear-gradient(90deg, #ff9900 0%, #ff8c00 100%);
            display: flex;
            align-items: center;
            justify-content: center;
            color: white;
            font-weight: bold;
            transition: width 1.5s ease;
            box-shadow: 0 2px 8px rgba(255,140,0,0.4);
        }

        .timeline {
            position: relative;
            padding: 20px 0;
            margin: 30px 0;
        }

        .timeline::before {
            content: '';
            position: absolute;
            left: 30px;
            top: 0;
            bottom: 0;
            width: 4px;
            background: linear-gradient(to bottom, #ff9900, #ff8c00);
        }

        .timeline-item {
            position: relative;
            padding-left: 70px;
            margin-bottom: 30px;
        }

        .timeline-marker {
            position: absolute;
            left: 20px;
            width: 24px;
            height: 24px;
            background: white;
            border: 4px solid #ff9900;
            border-radius: 50%;
            box-shadow: 0 2px 8px rgba(0,0,0,0.2);
        }

        .timeline-content {
            background: white;
            padding: 20px;
            border-radius: 8px;
            box-shadow: 0 2px 8px rgba(0,0,0,0.1);
        }

        @media print {
            body {
                background: white;
                padding: 0;
            }

            .container {
                box-shadow: none;
            }

            .chart-container, .risk-card {
                page-break-inside: avoid;
            }

            .header::before, .score-banner::before {
                display: none;
            }
        }

        @media (max-width: 768px) {
            .content {
                padding: 20px;
            }

            h1 {
                font-size: 1.8em;
            }

            h2 {
                font-size: 1.5em;
            }

            .chart-row {
                grid-template-columns: 1fr;
            }

            .dashboard {
                grid-template-columns: 1fr;
            }

            .chart-container {
                height: 300px;
            }
        }

        /* 动画效果 */
        @keyframes fadeInUp {
            from {
                opacity: 0;
                transform: translateY(30px);
            }
            to {
                opacity: 1;
                transform: translateY(0);
            }
        }

        .fade-in-up {
            animation: fadeInUp 0.6s ease-out;
        }

        /* 可折叠区域 */
        details {
            background: #f8f9fa;
            border-radius: 8px;
            padding: 15px;
            margin: 15px 0;
            border: 1px solid #e0e0e0;
        }

        summary {
            font-weight: bold;
            cursor: pointer;
            color: #ff9900;
            padding: 10px;
            border-radius: 4px;
            transition: background-color 0.2s ease;
        }

        summary:hover {
            background: rgba(255,153,0,0.1);
        }

        details[open] summary {
            margin-bottom: 15px;
            border-bottom: 2px solid #ff9900;
        }

        /* 徽章系统 */
        .badge-container {
            display: flex;
            flex-wrap: wrap;
            gap: 10px;
            margin: 15px 0;
        }

        .info-badge {
            display: inline-flex;
            align-items: center;
            gap: 8px;
            padding: 8px 15px;
            border-radius: 20px;
            font-size: 0.9em;
            font-weight: 500;
            box-shadow: 0 2px 6px rgba(0,0,0,0.1);
        }

        .badge-aws {
            background: linear-gradient(135deg, #232f3e 0%, #37475a 100%);
            color: white;
        }

        .badge-cost {
            background: linear-gradient(135deg, #1d8102 0%, #2ea043 100%);
            color: white;
        }

        .badge-time {
            background: linear-gradient(135deg, #0073bb 0%, #0091ff 100%);
            color: white;
        }
    </style>
</head>
<body>
    <div class="container">
        <div class="header">
            <div class="header-content">
                <h1>🛡️ AWS 系统韧性评估报告</h1>
                <div class="subtitle">基于 AWS Well-Architected Framework 和 AWS 韧性分析框架</div>

                <div class="meta-info">
                    <div class="meta-item">
                        <div class="meta-label">项目名称</div>
                        <div class="meta-value" id="project-name">-</div>
                    </div>
                    <div class="meta-item">
                        <div class="meta-label">评估日期</div>
                        <div class="meta-value" id="assessment-date">-</div>
                    </div>
                    <div class="meta-item">
                        <div class="meta-label">AWS 区域</div>
                        <div class="meta-value" id="aws-region">-</div>
                    </div>
                    <div class="meta-item">
                        <div class="meta-label">评估范围</div>
                        <div class="meta-value" id="assessment-scope">-</div>
                    </div>
                </div>
            </div>
        </div>

        <div class="content fade-in-up">
            <!-- 总体成熟度评分 -->
            <div class="score-banner">
                <div class="score-banner-content">
                    <h2 style="margin: 0; border: none; padding: 0; color: white;">整体韧性成熟度</h2>
                    <div class="score-stars" id="maturity-stars">⭐⭐⭐⭐☆</div>
                    <div class="score-value" id="maturity-score">4.2</div>
                    <div style="font-size: 1.5em;">良好 (Good)</div>
                </div>
            </div>

            <!-- 关键指标仪表板 -->
            <h2>📊 执行摘要</h2>

            <div class="dashboard">
                <div class="stat-card">
                    <div class="stat-icon">🔍</div>
                    <div class="stat-value" id="total-risks">15</div>
                    <div class="stat-label">识别的风险</div>
                </div>
                <div class="stat-card">
                    <div class="stat-icon">🔴</div>
                    <div class="stat-value" id="critical-risks">3</div>
                    <div class="stat-label">关键风险</div>
                </div>
                <div class="stat-card">
                    <div class="stat-icon">⏱️</div>
                    <div class="stat-value" id="avg-rto">5min</div>
                    <div class="stat-label">平均 RTO</div>
                </div>
                <div class="stat-card">
                    <div class="stat-icon">💰</div>
                    <div class="stat-value" id="monthly-cost">$2.5K</div>
                    <div class="stat-label">月度成本影响</div>
                </div>
            </div>

            <!-- 韧性评估雷达图 -->
            <h3>📈 韧性评估维度</h3>
            <div class="chart-container">
                <canvas id="resilienceRadarChart"></canvas>
            </div>

            <!-- 风险分布图 -->
            <h3>📊 风险分布</h3>
            <div class="chart-row">
                <div class="chart-container" style="height: 400px;">
                    <canvas id="riskDistributionChart"></canvas>
                </div>
                <div class="chart-container" style="height: 400px;">
                    <canvas id="riskPriorityChart"></canvas>
                </div>
            </div>

            <!-- Top 5 关键风险 -->
            <h2>🔴 Top 5 关键风险</h2>

            <div class="risk-card risk-critical" id="risk-1">
                <div class="risk-header">
                    <div class="risk-title">R-001: RDS 单区域部署</div>
                    <span class="risk-badge badge-critical">🔴 关键</span>
                </div>
                <p><strong>故障模式</strong>: 单点故障 (SPOF)</p>
                <p><strong>业务影响</strong>: 区域故障导致完全服务中断，影响100%用户</p>
                <p><strong>当前 RTO</strong>: 数小时</p>
                <p><strong>目标 RTO</strong>: < 1分钟</p>
                <div class="recommendation-section" style="margin-top: 15px;">
                    <h4 style="margin: 0 0 10px 0; color: #0073bb;">💡 改进建议</h4>
                    <p>实施 Aurora Global Database，实现跨区域自动故障转移</p>
                    <div class="badge-container">
                        <span class="info-badge badge-cost">成本: +$500-2000/月</span>
                        <span class="info-badge badge-time">实施: 2-3周</span>
                        <span class="info-badge badge-aws">Aurora Global DB</span>
                    </div>
                </div>
            </div>

            <div class="risk-card risk-high">
                <div class="risk-header">
                    <div class="risk-title">R-002: 缺少 Auto Scaling 配置</div>
                    <span class="risk-badge badge-high">🟠 高</span>
                </div>
                <p><strong>故障模式</strong>: 过度负载</p>
                <p><strong>业务影响</strong>: 流量突增时服务降级，影响用户体验</p>
                <p><strong>风险评分</strong>: 5.3 / 10</p>
                <div class="recommendation-section" style="margin-top: 15px;">
                    <h4 style="margin: 0 0 10px 0; color: #0073bb;">💡 改进建议</h4>
                    <p>配置 Target Tracking Auto Scaling 和预测性扩展</p>
                    <div class="badge-container">
                        <span class="info-badge badge-cost">成本: 无额外成本</span>
                        <span class="info-badge badge-time">实施: 1周</span>
                        <span class="info-badge badge-aws">Auto Scaling</span>
                    </div>
                </div>
            </div>

            <div class="risk-card risk-high">
                <div class="risk-header">
                    <div class="risk-title">R-003: 缺少断路器机制</div>
                    <span class="risk-badge badge-high">🟠 高</span>
                </div>
                <p><strong>故障模式</strong>: 共享命运</p>
                <p><strong>业务影响</strong>: 依赖服务故障导致级联失败</p>
                <div class="recommendation-section" style="margin-top: 15px;">
                    <h4 style="margin: 0 0 10px 0; color: #0073bb;">💡 改进建议</h4>
                    <p>使用 AWS App Mesh 实现断路器和重试策略</p>
                    <div class="badge-container">
                        <span class="info-badge badge-cost">成本: ~$50/月</span>
                        <span class="info-badge badge-time">实施: 2-3周</span>
                        <span class="info-badge badge-aws">App Mesh</span>
                    </div>
                </div>
            </div>

            <!-- 系统架构图 -->
            <h2>🏗️ 系统架构可视化</h2>

            <h3>当前架构</h3>
            <div class="mermaid" id="architecture-diagram">
graph TB
    subgraph "Region: us-east-1"
        subgraph "AZ-1a"
            EC2_1[EC2 Instances]
            RDS_1[RDS Primary]
        end
        subgraph "AZ-1b"
            EC2_2[EC2 Instances]
            RDS_2[RDS Standby]
        end
        ALB[Application Load Balancer]
        ALB --> EC2_1
        ALB --> EC2_2
        EC2_1 --> RDS_1
        EC2_2 --> RDS_1
        RDS_1 -.->|Replication| RDS_2
    end
    User[用户] --> ALB
            </div>

            <!-- 风险清单表格 -->
            <h2>📋 完整风险清单</h2>

            <table id="risk-table">
                <thead>
                    <tr>
                        <th>风险 ID</th>
                        <th>故障模式</th>
                        <th>概率</th>
                        <th>影响</th>
                        <th>风险得分</th>
                        <th>优先级</th>
                    </tr>
                </thead>
                <tbody>
                    <tr>
                        <td><strong>R-001</strong></td>
                        <td>RDS 单区域部署</td>
                        <td>3/5</td>
                        <td>5/5</td>
                        <td>15.0</td>
                        <td><span class="risk-badge badge-critical">关键</span></td>
                    </tr>
                    <tr>
                        <td><strong>R-002</strong></td>
                        <td>缺少 Auto Scaling</td>
                        <td>4/5</td>
                        <td>4/5</td>
                        <td>5.3</td>
                        <td><span class="risk-badge badge-high">高</span></td>
                    </tr>
                    <tr>
                        <td><strong>R-003</strong></td>
                        <td>缺少断路器机制</td>
                        <td>3/5</td>
                        <td>4/5</td>
                        <td>4.0</td>
                        <td><span class="risk-badge badge-high">高</span></td>
                    </tr>
                </tbody>
            </table>

            <!-- 实施路线图 -->
            <h2>🗓️ 实施路线图</h2>

            <div class="alert alert-info">
                <strong>💡 分阶段实施建议</strong><br>
                根据风险优先级和依赖关系，建议分3个阶段实施改进措施，总耗时约6个月。
            </div>

            <div class="timeline">
                <div class="timeline-item">
                    <div class="timeline-marker"></div>
                    <div class="timeline-content">
                        <h4>第一阶段（0-2个月）：基础韧性</h4>
                        <p><strong>关键任务：</strong></p>
                        <ul>
                            <li>RDS Multi-AZ 迁移</li>
                            <li>配置自动备份和恢复测试</li>
                            <li>实施基础监控和告警</li>
                        </ul>
                        <div class="progress-bar">
                            <div class="progress-fill" style="width: 0%;">0%</div>
                        </div>
                    </div>
                </div>

                <div class="timeline-item">
                    <div class="timeline-marker"></div>
                    <div class="timeline-content">
                        <h4>第二阶段（2-4个月）：自动化与扩展</h4>
                        <p><strong>关键任务：</strong></p>
                        <ul>
                            <li>IaC 迁移（Terraform）</li>
                            <li>Auto Scaling 配置</li>
                            <li>CI/CD 流水线优化</li>
                        </ul>
                        <div class="progress-bar">
                            <div class="progress-fill" style="width: 0%;">0%</div>
                        </div>
                    </div>
                </div>

                <div class="timeline-item">
                    <div class="timeline-marker"></div>
                    <div class="timeline-content">
                        <h4>第三阶段（4-6个月）：高级韧性</h4>
                        <p><strong>关键任务：</strong></p>
                        <ul>
                            <li>Aurora Global Database</li>
                            <li>混沌工程实验（AWS FIS）</li>
                            <li>SLO/SLI 跟踪和错误预算</li>
                        </ul>
                        <div class="progress-bar">
                            <div class="progress-fill" style="width: 0%;">0%</div>
                        </div>
                    </div>
                </div>
            </div>

            <!-- 成本效益分析 -->
            <h2>💰 成本效益分析</h2>

            <div class="chart-container" style="height: 400px;">
                <canvas id="costBenefitChart"></canvas>
            </div>

            <table>
                <thead>
                    <tr>
                        <th>改进措施</th>
                        <th>成本影响</th>
                        <th>预期效果</th>
                        <th>ROI</th>
                    </tr>
                </thead>
                <tbody>
                    <tr>
                        <td><strong>Aurora Global DB</strong></td>
                        <td>+$500-2000/月</td>
                        <td>RTO < 1分钟，RPO < 1秒</td>
                        <td class="badge-container"><span class="info-badge badge-cost">高</span></td>
                    </tr>
                    <tr>
                        <td><strong>Auto Scaling</strong></td>
                        <td>无额外成本</td>
                        <td>应对流量突增，提升用户体验</td>
                        <td class="badge-container"><span class="info-badge badge-cost">很高</span></td>
                    </tr>
                    <tr>
                        <td><strong>AWS FIS 测试</strong></td>
                        <td>~$100/月</td>
                        <td>验证韧性假设，提前发现问题</td>
                        <td class="badge-container"><span class="info-badge badge-cost">中</span></td>
                    </tr>
                </tbody>
            </table>

            <!-- 持续改进计划 -->
            <h2>🔄 持续改进计划</h2>

            <div class="recommendation-section">
                <h3>SLO/SLI 定义</h3>
                <table>
                    <thead>
                        <tr>
                            <th>服务</th>
                            <th>SLI</th>
                            <th>SLO</th>
                            <th>错误预算</th>
                        </tr>
                    </thead>
                    <tbody>
                        <tr>
                            <td><strong>Web 应用</strong></td>
                            <td>请求成功率</td>
                            <td>99.9%</td>
                            <td>43.2 分钟/月</td>
                        </tr>
                        <tr>
                            <td><strong>API</strong></td>
                            <td>P95 延迟</td>
                            <td>< 200ms (99.5%)</td>
                            <td>3.6 小时/月</td>
                        </tr>
                        <tr>
                            <td><strong>数据库</strong></td>
                            <td>可用性</td>
                            <td>99.95%</td>
                            <td>21.6 分钟/月</td>
                        </tr>
                    </tbody>
                </table>
            </div>

            <details>
                <summary>📚 查看事后复盘流程模板</summary>
                <div style="padding: 15px;">
                    <h4>无责任文化原则</h4>
                    <ul>
                        <li>专注于系统问题，而非个人过失</li>
                        <li>鼓励透明和诚实</li>
                        <li>从故障中学习</li>
                    </ul>
                    <h4>复盘必含要素</h4>
                    <ul>
                        <li>事故时间线</li>
                        <li>根因分析（5 Whys）</li>
                        <li>影响评估</li>
                        <li>做得好的地方</li>
                        <li>需要改进的地方</li>
                        <li>行动项（带负责人和截止日期）</li>
                    </ul>
                </div>
            </details>

            <!-- 参考资源 -->
            <h2>📚 参考资源</h2>

            <div class="alert alert-info">
                <strong>AWS 官方文档</strong>
                <ul style="margin: 10px 0 0 20px;">
                    <li><a href="https://docs.aws.amazon.com/prescriptive-guidance/latest/resilience-analysis-framework/" target="_blank">AWS Resilience Analysis Framework</a></li>
                    <li><a href="https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/" target="_blank">AWS Well-Architected - Reliability Pillar</a></li>
                    <li><a href="https://docs.aws.amazon.com/fis/latest/userguide/" target="_blank">AWS Fault Injection Simulator</a></li>
                    <li><a href="https://docs.aws.amazon.com/resilience-hub/latest/userguide/" target="_blank">AWS Resilience Hub</a></li>
                </ul>
            </div>

            <div class="alert alert-success">
                <strong>业界最佳实践</strong>
                <ul style="margin: 10px 0 0 20px;">
                    <li><a href="https://aws-observability.github.io/observability-best-practices/" target="_blank">AWS Observability Best Practices</a></li>
                    <li><a href="https://principlesofchaos.org/" target="_blank">Chaos Engineering Principles</a></li>
                    <li><a href="https://docs.aws.amazon.com/prescriptive-guidance/latest/chaos-engineering-on-aws/" target="_blank">Chaos Engineering on AWS</a></li>
                </ul>
            </div>
        </div>

        <div class="footer">
            <p><strong>报告生成日期</strong>: <span id="report-date">-</span></p>
            <p><strong>评估框架</strong>: AWS Well-Architected Framework + AWS 韧性分析框架</p>
            <p><strong>工具版本</strong>: AWS Resilience Assessment v1.0.0</p>
            <p style="margin-top: 20px; color: #999;">
                🤖 Powered by <a href="https://claude.ai" target="_blank" style="color: #ff9900;">Claude Sonnet 4.5</a>
            </p>
        </div>
    </div>

    <script>
        // 初始化 Mermaid
        mermaid.initialize({
            startOnLoad: true,
            theme: 'default',
            themeVariables: {
                primaryColor: '#ff9900',
                primaryTextColor: '#232f3e',
                primaryBorderColor: '#ff8c00',
                lineColor: '#ff9900',
                secondaryColor: '#f8f9fa',
                tertiaryColor: '#fff'
            }
        });

        // 设置报告日期
        document.getElementById('report-date').textContent = new Date().toLocaleDateString('zh-CN');

        // 韧性评估雷达图
        const radarCtx = document.getElementById('resilienceRadarChart').getContext('2d');
        new Chart(radarCtx, {
            type: 'radar',
            data: {
                labels: [
                    '冗余设计',
                    'AZ 容错',
                    '超时与重试',
                    '断路器',
                    '自动扩展',
                    '配置防护',
                    '故障隔离',
                    '备份恢复',
                    '最佳实践'
                ],
                datasets: [{
                    label: '当前状态',
                    data: [3, 3, 2, 1, 2, 3, 2, 3, 3],
                    backgroundColor: 'rgba(255, 153, 0, 0.2)',
                    borderColor: 'rgb(255, 153, 0)',
                    borderWidth: 3,
                    pointBackgroundColor: 'rgb(255, 153, 0)',
                    pointBorderColor: '#fff',
                    pointHoverBackgroundColor: '#fff',
                    pointHoverBorderColor: 'rgb(255, 153, 0)',
                    pointRadius: 5,
                    pointHoverRadius: 7
                }, {
                    label: '目标状态',
                    data: [5, 5, 5, 5, 5, 5, 5, 5, 5],
                    backgroundColor: 'rgba(29, 129, 2, 0.1)',
                    borderColor: 'rgb(29, 129, 2)',
                    borderWidth: 2,
                    borderDash: [5, 5],
                    pointBackgroundColor: 'rgb(29, 129, 2)',
                    pointBorderColor: '#fff',
                    pointRadius: 3
                }]
            },
            options: {
                responsive: true,
                maintainAspectRatio: true,
                scales: {
                    r: {
                        beginAtZero: true,
                        max: 5,
                        ticks: {
                            stepSize: 1,
                            callback: function(value) {
                                return value + '⭐';
                            },
                            font: { size: 12 }
                        },
                        pointLabels: {
                            font: {
                                size: 13,
                                weight: 'bold'
                            }
                        }
                    }
                },
                plugins: {
                    legend: {
                        position: 'bottom',
                        labels: {
                            padding: 20,
                            font: { size: 14 }
                        }
                    },
                    title: {
                        display: true,
                        text: '韧性评估维度（当前 vs 目标）',
                        font: {
                            size: 16,
                            weight: 'bold'
                        },
                        padding: { bottom: 20 }
                    }
                }
            }
        });

        // 风险分布图（按类别）
        const distCtx = document.getElementById('riskDistributionChart').getContext('2d');
        new Chart(distCtx, {
            type: 'doughnut',
            data: {
                labels: ['单点故障', '过度延迟', '过度负载', '错误配置', '共享命运'],
                datasets: [{
                    data: [5, 2, 3, 3, 2],
                    backgroundColor: [
                        'rgb(209, 50, 18)',
                        'rgb(255, 153, 0)',
                        'rgb(247, 181, 0)',
                        'rgb(29, 129, 2)',
                        'rgb(0, 115, 187)'
                    ],
                    borderWidth: 2,
                    borderColor: '#fff'
                }]
            },
            options: {
                responsive: true,
                maintainAspectRatio: true,
                plugins: {
                    legend: {
                        position: 'right',
                        labels: { font: { size: 13 }, padding: 15 }
                    },
                    title: {
                        display: true,
                        text: '风险类别分布',
                        font: { size: 16, weight: 'bold' }
                    }
                }
            }
        });

        // 风险优先级图
        const priorityCtx = document.getElementById('riskPriorityChart').getContext('2d');
        new Chart(priorityCtx, {
            type: 'bar',
            data: {
                labels: ['关键', '高', '中', '低'],
                datasets: [{
                    label: '风险数量',
                    data: [3, 5, 4, 3],
                    backgroundColor: [
                        'rgb(209, 50, 18)',
                        'rgb(255, 153, 0)',
                        'rgb(247, 181, 0)',
                        'rgb(29, 129, 2)'
                    ],
                    borderWidth: 0
                }]
            },
            options: {
                responsive: true,
                maintainAspectRatio: true,
                scales: {
                    y: {
                        beginAtZero: true,
                        ticks: { stepSize: 1 }
                    }
                },
                plugins: {
                    legend: { display: false },
                    title: {
                        display: true,
                        text: '风险优先级分布',
                        font: { size: 16, weight: 'bold' }
                    }
                }
            }
        });

        // 成本效益分析图
        const costCtx = document.getElementById('costBenefitChart').getContext('2d');
        new Chart(costCtx, {
            type: 'scatter',
            data: {
                datasets: [{
                    label: 'Aurora Global DB',
                    data: [{ x: 1500, y: 5 }],
                    backgroundColor: 'rgb(209, 50, 18)',
                    pointRadius: 15
                }, {
                    label: 'Auto Scaling',
                    data: [{ x: 0, y: 4.5 }],
                    backgroundColor: 'rgb(29, 129, 2)',
                    pointRadius: 15
                }, {
                    label: 'AWS FIS',
                    data: [{ x: 100, y: 3 }],
                    backgroundColor: 'rgb(255, 153, 0)',
                    pointRadius: 12
                }, {
                    label: 'App Mesh',
                    data: [{ x: 50, y: 4 }],
                    backgroundColor: 'rgb(0, 115, 187)',
                    pointRadius: 12
                }]
            },
            options: {
                responsive: true,
                maintainAspectRatio: true,
                scales: {
                    x: {
                        title: {
                            display: true,
                            text: '月度成本影响 ($)',
                            font: { size: 14, weight: 'bold' }
                        }
                    },
                    y: {
                        title: {
                            display: true,
                            text: '业务价值 (1-5)',
                            font: { size: 14, weight: 'bold' }
                        },
                        min: 0,
                        max: 5
                    }
                },
                plugins: {
                    title: {
                        display: true,
                        text: '成本 vs 业务价值',
                        font: { size: 16, weight: 'bold' }
                    },
                    tooltip: {
                        callbacks: {
                            label: function(context) {
                                return context.dataset.label + ': $' + context.parsed.x + '/月, 价值=' + context.parsed.y;
                            }
                        }
                    }
                }
            }
        });

        // 动画进度条
        setTimeout(() => {
            document.querySelectorAll('.progress-fill').forEach((bar, index) => {
                setTimeout(() => {
                    const values = [0, 0, 0]; // 初始都是0%，可以根据实际进度更新
                    bar.style.width = values[index] + '%';
                    bar.textContent = values[index] + '%';
                }, index * 300);
            });
        }, 500);
    </script>
</body>
</html>

English | 中文

---

AWS 系统韧性分析 Skill

这是一个全面的 AWS 系统韧性评估和风险分析 skill，整合了 2025 年最新的业界最佳实践。

安装

方式 A：npx skills（推荐）

# Install this skill
npx skills add aws-samples/sample-aws-resilience-skill --skill aws-resilience-modeling

# Install all 4 resilience skills
npx skills add aws-samples/sample-aws-resilience-skill --skill '*'

方式 B：Git clone

git clone https://github.com/aws-samples/sample-aws-resilience-skill.git

特性

✅ 基于 AWS Well-Architected Framework 可靠性支柱
✅ 整合 AWS 韧性分析框架（错误预算、SLO/SLI）
✅ 包含 混沌工程 方法论（AWS FIS）
✅ 采用 AWS 可观测性最佳实践（CloudWatch、X-Ray、分布式追踪）
✅ 应用 云设计模式（Circuit Breaker、Bulkhead、Retry）
✅ 内置 AWS 常见服务风险参考库（50+ 个风险点，覆盖存储/数据库/EKS/EC2/网络）

使用方式

方式 1：直接调用

/aws-resilience-modeling

Claude 会首先询问你的环境信息和业务背景，然后开始进行全面的韧性分析。

方式 2：自动触发

当你在对话中提到以下关键词时，skill 会自动激活：

"AWS 韧性分析"
"系统风险评估"
"AWS 韧性评估"
"AWS resilience assessment"

示例：

用户: 我想对我们的 AWS 生产环境进行韧性分析
Claude: [自动加载 aws-resilience-modeling skill]

准备工作

在开始分析前，请准备以下信息：

MCP 服务器配置

自动扫描 AWS 环境所需的 MCP 服务器详细配置指南，参见 references/MCP_SETUP_GUIDE_zh.md。

1. 环境信息

AWS 账户 ID 和区域
访问权限（建议只读访问）
现有架构文档（如有）

2. 业务背景

关键业务流程清单
当前的 RTO/RPO 目标
现有的 SLA/SLO（如有）
合规要求（如 SOC2、HIPAA、PCI DSS）

3. 分析范围

需要分析的应用和服务
是否包含多账户/多区域
预算和时间约束

输出内容

分析完成后，你将获得：

主报告

1. 执行摘要（2 页）

关键发现（Top 5 风险）
韧性成熟度评分
优先改进建议

2. 系统架构可视化

架构总览图（Mermaid）
依赖关系图
数据流图
网络拓扑图

3. 风险清单（表格）

按优先级排序
包含风险评分、影响、缓解建议

4. 详细风险分析

每个高优先级风险的深入分析
故障场景
业务影响
改进建议（架构、配置、监控）

5. 业务影响分析

关键业务功能映射
RTO/RPO 合规性分析

6. 缓解策略建议

具体的架构改进
配置优化（含参数和命令）
监控和告警配置
AWS 服务推荐

7. 实施路线图

Gantt 图
详细任务分解
资源需求和预算

8. 持续改进计划

SLI/SLO 定义
事后复盘流程
混沌工程计划

附加文件

references/common-risks-reference_zh.md - AWS 常见服务风险参考手册（English）

覆盖存储（EBS/S3/EFS/FSx）、数据库、容器（EKS）、计算（EC2）、网络五大类
50+ 个常见风险点，每个包含风险原因和改进建议
评估检查清单，按服务类型逐项确认

references/assessment-output-spec_zh.md - 混沌工程输入规范（English）

定义 chaos-engineering-on-aws skill 所需的结构化输入格式
包含 AWS 资源清单、风险可实验性标记、监控就绪度等 8 个章节
不同架构模式的填写示例（EKS/Serverless/EC2/多区域）

所有参考文件均提供英文版本，英文版文件名不带后缀（如 resilience-framework.md），中文版使用 _zh.md 后缀。

目录结构

aws-resilience-modeling/
├── SKILL.md                                    # 语言路由器（加载 EN/ZH）
├── SKILL_EN.md / SKILL_ZH.md                  # Skill 指令（双语，各 ~153 行）
├── README.md / README_zh.md                    # 说明文档（双语）
├── references/                                 # 参考文档（Agent 按需加载）
│   ├── analysis-tasks.md / _zh.md              # 8 个分析任务详细指令
│   ├── resilience-framework.md / _zh.md        # 框架索引和参考资料映射
│   ├── resilience-analysis-core.md / _zh.md    # 9 维度评分方法论
│   ├── waf-reliability-pillar.md / _zh.md      # WAF 可靠性支柱 + DR 成本基线
│   ├── common-risks-reference.md / _zh.md      # 50+ 常见 AWS 风险模式
│   ├── assessment-output-spec.md / _zh.md      # Chaos Skill 桥接：8 段输出规格
│   ├── compliance-mapping.md / _zh.md          # SOC2/ISO 27001/NIST CSF 框架映射
│   ├── cloud-design-patterns.md / _zh.md       # 云韧性设计模式
│   ├── chaos-engineering-methodology.md / _zh.md # 混沌工程方法论参考
│   ├── observability-standards.md / _zh.md     # AWS 可观测性最佳实践
│   ├── report-generation.md / _zh.md           # 报告生成工作流
│   ├── HTML-TEMPLATE-USAGE.md / _zh.md         # HTML 模板使用指南
│   └── MCP_SETUP_GUIDE.md / _zh.md             # MCP 服务器配置指南
├── scripts/
│   └── generate-html-report.py                 # Python 报告生成器
└── assets/
    ├── html-report-template.html               # HTML 交互式报告模板
    └── example-report-template.md / _zh.md     # Markdown 报告示例

分析框架

故障模式分类

类别	说明
单点故障 (SPOF)	缺乏冗余的关键组件
过度延迟	性能瓶颈和延迟问题
过度负载	容量限制和突增负载
错误配置	不符合最佳实践
共享命运	紧密耦合和缺乏隔离

韧性评估维度

使用 5 星评分系统（1星=不足，5星=优秀）评估：

冗余设计
AZ 容错能力
超时与重试策略
断路器机制
自动扩展能力
配置防护措施
故障隔离
备份恢复机制
AWS 最佳实践合规性

风险优先级评分

风险得分 = (发生概率 × 业务影响 × 检测难度) / 修复复杂度

示例场景

场景 1：电商平台

环境:
- Multi-AZ RDS (PostgreSQL)
- ECS Fargate 应用
- CloudFront + S3 静态资源
- ElastiCache Redis

关键发现:
- RDS 单区域（无 Aurora Global Database）
- 缺少 Auto Scaling 策略
- 未配置 Circuit Breaker
- 监控覆盖不足

建议:
- 迁移到 Aurora Global Database
- 实施 Target Tracking Auto Scaling
- 集成 AWS X-Ray 分布式追踪
- 建立季度 DR 演练

场景 2：金融 API

环境:
- API Gateway + Lambda
- DynamoDB Global Tables
- Aurora Serverless
- Route 53 健康检查

关键发现:
- Lambda 无 Reserved Concurrency
- 缺少 API 限流策略
- 未定义 SLO/SLI
- 无混沌工程实践

建议:
- 配置 Lambda Reserved Concurrency
- 实施 API Gateway Usage Plans
- 定义 99.99% 可用性 SLO
- 建立每周混沌实验

灾难恢复策略选择

策略	RTO	RPO	成本	适用场景
备份与恢复	小时-天	小时-天	$	非关键系统
导航灯	10分钟-小时	分钟	$$	重要系统
温备份	分钟	秒-分钟	$$$	关键业务
多站点主动-主动	秒-分钟	秒	$$$$	任务关键

参考资源

AWS 官方文档

外部资源

高级特性

错误预算管理

基于 AWS 韧性最佳实践，计算和跟踪错误预算：

错误预算 = (1 - SLO) × 时间周期

示例：
SLO = 99.9%（月度）
错误预算 = 43.2 分钟/月

混沌工程实验

使用 AWS FIS 进行故障注入：

EC2 实例终止
网络延迟/丢包
RDS 故障转移
AZ 不可用模拟
CPU/内存压力测试

可观测性三大支柱

日志：CloudWatch Logs + 结构化日志
指标：CloudWatch Metrics + 关键监控指标
追踪：AWS X-Ray + 分布式追踪

常见问题

Q: 分析需要多长时间？

A: 根据环境复杂度：

简单环境（单区域，< 10 服务）：1-2 小时
中等环境（多 AZ，10-50 服务）：3-5 小时
复杂环境（多区域，> 50 服务）：1-2 天

Q: 是否需要 AWS 账户访问权限？

A: 推荐但非必需：

有权限：可以自动扫描资源，分析更准确
无权限：基于提供的架构文档进行分析

Q: 分析会产生 AWS 费用吗？

A: 分析本身不产生费用，但实施建议可能包含：

AWS Resilience Hub（免费）
AWS FIS 混沌实验（按分钟计费）
额外的 AWS 服务（如 Aurora Global Database）

Q: 如何实施建议？

A: 分析报告包含：

具体的架构改进图
AWS CLI 命令
CloudFormation/Terraform 代码片段
分阶段实施路线图

Q: 是否支持多云环境？

A: 当前专注于 AWS 环境，提供基于 AWS Well-Architected Framework 的专业韧性评估。

更新日志

v1.1.0 (2026-03-14)

✅ 新增 common-risks-reference.md — AWS 常见服务风险参考手册
✅ 整合 50+ 个常见风险点（存储/数据库/EKS/EC2/网络）
✅ 新增按服务类型的评估检查清单
✅ SKILL.md 故障模式识别任务引用风险参考
✅ 风险分类细化对齐实际 AWS 服务

v1.0.0 (2025-02-17)

✅ 初始版本
✅ 整合 AWS Well-Architected Framework (2025)
✅ 整合 AWS 韧性分析框架
✅ 整合混沌工程方法论
✅ 整合 AWS 可观测性最佳实践
✅ 包含详细的 resilience-framework.md 参考

反馈和贡献

如有问题或建议，请通过以下方式反馈：

在对话中直接提出
更新你本地的 skill 文件

许可

本 skill 基于 AWS Well-Architected Framework 和混沌工程最佳实践编写，供学习和使用。

English | 中文

---

AWS System Resilience Analysis Skill

A comprehensive AWS system resilience assessment and risk analysis skill, incorporating the latest 2025 industry best practices.

Installation

Option A: npx skills (Recommended)

# Install this skill
npx skills add aws-samples/sample-aws-resilience-skill --skill aws-resilience-modeling

# Install all 4 resilience skills
npx skills add aws-samples/sample-aws-resilience-skill --skill '*'

Option B: Git clone

git clone https://github.com/aws-samples/sample-aws-resilience-skill.git

Features

✅ Based on the AWS Well-Architected Framework Reliability Pillar
✅ Integrates the AWS Resilience Analysis Framework (error budgets, SLO/SLI)
✅ Includes Chaos Engineering methodology (AWS FIS)
✅ Adopts AWS Observability Best Practices (CloudWatch, X-Ray, distributed tracing)
✅ Applies Cloud Design Patterns (Circuit Breaker, Bulkhead, Retry)
✅ Built-in AWS Common Service Risk Reference Library (50+ risk points covering storage/database/EKS/EC2/networking)

Usage

Method 1: Direct Invocation

/aws-resilience-modeling

Claude will first ask for your environment information and business context, then begin a comprehensive resilience analysis.

Method 2: Automatic Trigger

The skill activates automatically when you mention the following keywords in conversation:

"AWS resilience analysis"
"system risk assessment"
"AWS resilience assessment"

Example:

User: I want to perform a resilience analysis on our AWS production environment
Claude: [auto-loads aws-resilience-modeling skill]

Prerequisites

Before starting the analysis, prepare the following information:

MCP Server Configuration

For detailed MCP server setup instructions (required for automated AWS environment scanning), see references/MCP_SETUP_GUIDE.md.

1. Environment Information

AWS account ID and region
Access credentials (read-only access recommended)
Existing architecture documentation (if available)

2. Business Context

List of critical business processes
Current RTO/RPO targets
Existing SLA/SLO (if available)
Compliance requirements (e.g., SOC2, HIPAA, PCI DSS)

3. Analysis Scope

Applications and services to be analyzed
Whether multi-account/multi-region is included
Budget and time constraints

Output

Upon completion of the analysis, you will receive:

Main Report

1. Executive Summary (2 pages)

Key findings (Top 5 risks)
Resilience maturity score
Priority improvement recommendations

2. System Architecture Visualization

Architecture overview diagram (Mermaid)
Dependency diagram
Data flow diagram
Network topology diagram

3. Risk Inventory (table)

Sorted by priority
Includes risk scores, impact, and mitigation recommendations

4. Detailed Risk Analysis

In-depth analysis of each high-priority risk
Failure scenarios
Business impact
Improvement recommendations (architecture, configuration, monitoring)

5. Business Impact Analysis

Critical business function mapping
RTO/RPO compliance analysis

6. Mitigation Strategy Recommendations

Specific architecture improvements
Configuration optimizations (with parameters and commands)
Monitoring and alerting configuration
AWS service recommendations

7. Implementation Roadmap

Gantt chart
Detailed task breakdown
Resource requirements and budget

8. Continuous Improvement Plan

SLI/SLO definitions
Postmortem process
Chaos engineering plan

Additional Files

references/common-risks-reference.md - AWS Common Service Risk Reference Manual (中文)

Covers five categories: storage (EBS/S3/EFS/FSx), databases, containers (EKS), compute (EC2), and networking
50+ common risk points, each with root cause and improvement recommendations
Assessment checklist organized by service type

references/assessment-output-spec.md - Chaos Engineering Input Specification (中文)

Defines the structured input format required by the chaos-engineering-on-aws skill
Contains 8 sections including AWS resource inventory, risk experiment-readiness flags, and monitoring readiness
Fill-in examples for different architecture patterns (EKS/Serverless/EC2/multi-region)

All reference files are available in both English and Chinese. Chinese versions use the _zh.md suffix (e.g., resilience-framework_zh.md).

Directory Structure

aws-resilience-modeling/
├── SKILL.md                                    # Language router (loads EN/ZH)
├── SKILL_EN.md / SKILL_ZH.md                  # Skill instructions (bilingual, ~153 lines each)
├── README.md / README_zh.md                    # Documentation (bilingual)
├── references/                                 # Reference docs (loaded on demand by Agent)
│   ├── analysis-tasks.md / _zh.md              # 8 analysis task detailed instructions
│   ├── resilience-framework.md / _zh.md        # Framework index & references map
│   ├── resilience-analysis-core.md / _zh.md    # 9-dimension scoring methodology
│   ├── waf-reliability-pillar.md / _zh.md      # WAF Reliability Pillar + DR cost baselines
│   ├── common-risks-reference.md / _zh.md      # 50+ common AWS risk patterns
│   ├── assessment-output-spec.md / _zh.md      # Chaos skill bridge: 8-section output spec
│   ├── compliance-mapping.md / _zh.md          # SOC2/ISO 27001/NIST CSF mapping
│   ├── cloud-design-patterns.md / _zh.md       # Cloud resilience design patterns
│   ├── chaos-engineering-methodology.md / _zh.md # Chaos engineering methodology reference
│   ├── observability-standards.md / _zh.md     # AWS observability best practices
│   ├── report-generation.md / _zh.md           # Report generation workflow
│   ├── HTML-TEMPLATE-USAGE.md / _zh.md         # HTML template usage guide
│   └── MCP_SETUP_GUIDE.md / _zh.md             # MCP server configuration guide
├── scripts/
│   └── generate-html-report.py                 # Python report generator
└── assets/
    ├── html-report-template.html               # HTML interactive report template
    └── example-report-template.md / _zh.md     # Markdown report example

Analysis Framework

Failure Mode Classification

Category	Description
Single Point of Failure (SPOF)	Critical components lacking redundancy
Excessive Latency	Performance bottlenecks and latency issues
Excessive Load	Capacity limits and traffic spikes
Misconfiguration	Non-compliance with best practices
Shared Fate	Tight coupling and lack of isolation

Resilience Assessment Dimensions

Uses a 5-star rating system (1 star = inadequate, 5 stars = excellent) to assess:

Redundancy design
AZ fault tolerance
Timeout and retry strategy
Circuit breaker mechanism
Auto-scaling capability
Configuration safeguards
Fault isolation
Backup and recovery mechanism
AWS best practices compliance

Risk Priority Scoring

Risk Score = (Probability × Business Impact × Detection Difficulty) / Remediation Complexity

Example Scenarios

Scenario 1: E-Commerce Platform

Environment:
- Multi-AZ RDS (PostgreSQL)
- ECS Fargate application
- CloudFront + S3 static assets
- ElastiCache Redis

Key Findings:
- RDS single-region (no Aurora Global Database)
- Missing Auto Scaling policies
- No Circuit Breaker configured
- Insufficient monitoring coverage

Recommendations:
- Migrate to Aurora Global Database
- Implement Target Tracking Auto Scaling
- Integrate AWS X-Ray distributed tracing
- Establish quarterly DR drills

Scenario 2: Financial API

Environment:
- API Gateway + Lambda
- DynamoDB Global Tables
- Aurora Serverless
- Route 53 health checks

Key Findings:
- Lambda without Reserved Concurrency
- Missing API throttling policies
- SLO/SLI not defined
- No chaos engineering practices

Recommendations:
- Configure Lambda Reserved Concurrency
- Implement API Gateway Usage Plans
- Define 99.99% availability SLO
- Establish weekly chaos experiments

Disaster Recovery Strategy Selection

Strategy	RTO	RPO	Cost	Applicable Scenarios
Backup & Restore	Hours–Days	Hours–Days	$	Non-critical systems
Pilot Light	10 min–Hours	Minutes	$$	Important systems
Warm Standby	Minutes	Seconds–Minutes	$$$	Critical business
Multi-Site Active-Active	Seconds–Minutes	Seconds	$$$$	Mission-critical

Reference Resources

AWS Official Documentation

External Resources

Advanced Features

Error Budget Management

Based on AWS resilience best practices, calculate and track error budgets:

Error Budget = (1 - SLO) × Time Period

Example:
SLO = 99.9% (monthly)
Error Budget = 43.2 minutes/month

Chaos Engineering Experiments

Use AWS FIS for fault injection:

EC2 instance termination
Network latency/packet loss
RDS failover
AZ unavailability simulation
CPU/memory stress tests

Three Pillars of Observability

Logs: CloudWatch Logs + structured logging
Metrics: CloudWatch Metrics + key monitoring indicators
Traces: AWS X-Ray + distributed tracing

FAQ

Q: How long does the analysis take?

A: Depends on environment complexity:

Simple environment (single region, < 10 services): 1–2 hours
Medium environment (multi-AZ, 10–50 services): 3–5 hours
Complex environment (multi-region, > 50 services): 1–2 days

Q: Is AWS account access required?

A: Recommended but not mandatory:

With access: Resources can be scanned automatically for more accurate analysis
Without access: Analysis is based on provided architecture documentation

Q: Will the analysis incur AWS charges?

A: The analysis itself incurs no charges, but implementing recommendations may include:

AWS Resilience Hub (free)
AWS FIS chaos experiments (billed per minute)
Additional AWS services (e.g., Aurora Global Database)

Q: How do I implement the recommendations?

A: The analysis report includes:

Specific architecture improvement diagrams
AWS CLI commands
CloudFormation/Terraform code snippets
Phased implementation roadmap

Q: Is multi-cloud supported?

A: Currently focused on AWS environments, providing professional resilience assessments based on the AWS Well-Architected Framework.

Changelog

v1.1.0 (2026-03-14)

✅ Added common-risks-reference.md — AWS Common Service Risk Reference Manual
✅ Integrated 50+ common risk points (storage/database/EKS/EC2/networking)
✅ Added assessment checklist organized by service type
✅ SKILL.md failure mode identification task references the risk reference
✅ Risk classification refined to align with actual AWS services

v1.0.0 (2025-02-17)

✅ Initial release
✅ Integrated AWS Well-Architected Framework (2025)
✅ Integrated AWS Resilience Analysis Framework
✅ Integrated chaos engineering methodology
✅ Integrated AWS observability best practices
✅ Includes detailed resilience-framework.md reference

Feedback and Contributions

For questions or suggestions, please provide feedback by:

Raising them directly in conversation
Updating your local skill files

License

This skill is written based on the AWS Well-Architected Framework and chaos engineering best practices, for learning and use.

分析任务 — 详细指令

任务 1: 系统组件映射与依赖分析

使用工具：通过 MCP 服务器（aws-api-mcp-server）进行只读 API 调用（如可用）、Mermaid 图表。禁止通过 Bash 执行任何 aws CLI 命令访问 AWS 资源。

输出内容： 1. 系统架构总览图（Mermaid，展示 Region/AZ/组件层级） 2. 组件依赖关系图（标明同步/异步依赖、强/弱依赖、关键路径） 3. 数据流图（请求路径、数据流向、集成点） 4. 网络拓扑图（VPC、子网、安全组、路由表、NAT 网关、VPN/Direct Connect）

多账户注意事项（如果架构跨越多个 AWS 账户）：

AWS Organizations SCP（服务控制策略）对韧性的影响
跨账户资源共享和 DR 策略（如共享 VPC、跨账户备份保管库）
集中式 vs 分散式备份和监控策略
跨账户 IAM 信任关系和故障转移权限

任务 2: 故障模式识别与分类（基于 AWS Resilience Analysis Framework）

参考资源：

AWS Prescriptive Guidance - Resilience Analysis Framework
详见 resilience-framework_zh.md 索引文件。按需加载对应子文件：
waf-reliability-pillar_zh.md — DR 策略、多 AZ/多 Region
resilience-analysis-core_zh.md — Error Budget、SLI/SLO、黄金信号、事后复盘
chaos-engineering-methodology_zh.md — 实验流程、FIS 模板
observability-standards_zh.md — OpenTelemetry、日志/指标/链路
cloud-design-patterns_zh.md — 舱壁、熔断器、重试

识别以下故障模式类别：

故障类别	说明	检查要点
单点故障 (SPOF)	缺乏冗余的关键组件	单 AZ 部署、单实例数据库、未配置故障转移
过度延迟	性能瓶颈和延迟问题	网络延迟、数据库查询、API 超时
过度负载	容量限制和突增负载	Auto Scaling 配置、服务配额、流量高峰
错误配置	不符合最佳实践	安全组、IAM 策略、备份策略
共享命运 (Shared Fate)	紧密耦合和缺乏隔离	跨服务依赖、区域依赖、配额共享

对每个故障模式提供：详细技术描述、当前配置问题、涉及的 AWS 服务和资源 ARN、触发条件和场景、业务影响评估。

风险分类：基础设施 / 中间件与数据库 / 容器平台 / 网络 / 数据 / 安全与合规。

任务 3: 韧性评估（5 星评分系统）

对每个关键组件进行评分（1星=不足，5星=优秀）：

评估维度：

维度	评估问题	评分标准
冗余设计	组件是否具有足够的冗余？	1: 单点 / 2: 同AZ冗余 / 3: 多AZ手动切换 / 4: 多AZ自动切换+跨区域备份 / 5: 多区域主动-主动
AZ 容错	能否承受单 AZ 故障？	1: 单AZ / 2: 多AZ无自动切换 / 3: 多AZ自动故障转移 / 4: 多AZ+定期DR演练 / 5: 多AZ+多区域故障转移已验证
超时与重试	是否有适当的超时和重试策略？	1: 无配置 / 2: 基本固定超时 / 3: 可配置超时+简单重试 / 4: 指数退避+抖动 / 5: 指数退避+断路器+舱壁
断路器	是否有防止级联故障的机制？	1: 无 / 2: 基本健康检查 / 3: 关键路径断路器 / 4: 断路器+优雅降级 / 5: 完整断路器+降级+限流
自动扩展	能否应对负载增加？	1: 固定容量 / 2: 手动扩展 / 3: 目标追踪Auto Scaling / 4: 预测+响应式Auto Scaling / 5: 多维度Auto Scaling+容量预留
配置防护	是否有防止错误配置的措施？	1: 手动 / 2: 文档化流程 / 3: IaC模板 / 4: IaC+自动化验证+漂移检测 / 5: IaC+策略即代码+自动回滚
故障隔离	故障隔离边界是否明确？	1: 单体 / 2: 基本服务分离 / 3: 服务级隔离 / 4: 细胞架构 / 5: 细胞架构+舱壁+shuffle sharding
备份恢复	是否有数据备份和恢复机制？	1: 无备份 / 2: 手动备份 / 3: 自动备份+恢复测试 / 4: 跨区域备份+定期DR测试 / 5: 跨区域+自动化恢复测试+PITR
最佳实践	是否符合 Well-Architected？	1: 多项违反 / 2: 部分合规 / 3: 基本合规+已知差距 / 4: 完全合规+优化中 / 5: 完全合规+持续改进

映射：Modeling 9 维度 ↔ RMA 10 领域

如果用户同时完成了 RMA 评估（aws-rma-assessment 技能），可使用此映射交叉参考结果：

Modeling 维度	RMA 领域	映射说明
冗余设计	D2: 多位置设计 (Q7-Q9)	Modeling 评估单组件级别；RMA 评估组织级方法
AZ 容错	D2: 多位置设计 (Q7-Q9)、D10: 灾难恢复 (Q46-Q52)	Modeling 聚焦技术 AZ 配置；RMA 包含 DR 治理
超时与重试	D3: 交互设计 (Q10-Q13)	直接映射 — 两者都评估超时/重试/退避策略
断路器	D3: 交互设计 (Q10-Q13)、D8: 故障隔离 (Q36-Q39)	Modeling 专门评估断路器；RMA 更广泛（交互 + 隔离）
自动扩展	D1: 工作负载设计 (Q1-Q6)	Modeling 评估扩展能力；RMA 评估整体工作负载设计成熟度
配置防护	D4: 分布式系统设计 (Q14-Q17)、D5: 变更管理 (Q18-Q22)	Modeling 聚焦 IaC/验证；RMA 增加变更管理流程
故障隔离	D8: 故障隔离 (Q36-Q39)	直接映射
备份恢复	D10: 灾难恢复 (Q46-Q52)	直接映射
最佳实践	所有领域（汇总）	Modeling 评估 WAF 合规性；RMA 提供细粒度领域级成熟度

评分转换指南（近似）：

Modeling 星级	近似 RMA 级别	解释
⭐（1 星）	Level 0-1	未实现或临时性
⭐⭐（2 星）	Level 1-2	基本实现，手动流程
⭐⭐⭐（3 星）	Level 2-3	标准化，部分自动化
⭐⭐⭐⭐（4 星）	Level 3-4	良好自动化，定期测试
⭐⭐⭐⭐⭐（5 星）	Level 4-5	优化，持续改进

⚠️ 此映射为近似值。Modeling 评分反映特定组件的技术实现深度；RMA 级别反映人员、流程和工具的组织成熟度。

任务 4: 业务影响分析

1. 识别关键业务流程（用户注册/登录、订单处理、支付交易、数据分析等） 2. 评估组件故障影响（组件 → 故障场景 → 影响的业务功能 → 影响程度 → 用户影响 → 当前/目标 RTO） 3. RTO/RPO 合规性分析（当前架构能否满足业务目标、差距分析、优先改进领域）

任务 5: 风险优先级排序

风险评分矩阵：风险得分 = (发生概率 x 业务影响 x 检测难度) / 修复复杂度

风险 ID	故障模式	概率 (1-5)	影响 (1-5)	检测难度 (1-5)	修复复杂度 (1-5)	风险得分	优先级
R-001	RDS 单 AZ	3	5	2	2	15	高
R-002	缺少 Auto Scaling	4	4	1	3	5.3	中

风险得分严重性阈值：

严重性	分值范围	所需行动
关键 (Critical)	>= 20	立即修复
高 (High)	10 - 19	当前迭代内修复
中 (Medium)	4 - 9	下季度规划修复
低 (Low)	< 4	持续监控，有余力时处理

同时进行级联效应分析：识别风险之间的关联、评估多点故障场景、最坏情况影响分析。

任务 6: 缓解策略建议

针对高优先级风险，提供具体的、可操作的建议。每个风险应包含：

1. 架构改进建议：修改前/后对比（Mermaid 图），展示改进方案 2. 配置优化建议：具体 AWS CLI 命令或 IaC 代码 3. 监控与告警建议：CloudWatch 告警配置（指标、阈值、告警级别、响应 SLA） 4. AWS 服务推荐：推荐服务、价值说明、成本影响 5. 实施评估：复杂度、预期效果、实施风险、成本范围、优先级

完整缓解策略示例参见 example-report-template_zh.md。

任务 7: 实施路线图

分阶段实施计划（基于风险优先级和依赖关系），使用 Mermaid Gantt 图展示：

阶段 1：基础韧性 — Multi-AZ 部署、自动备份、基础监控告警
阶段 2：自动化 — IaC 迁移、CI/CD 流水线、Auto Scaling
阶段 3：DR 和混沌工程 — Aurora Global Database、Route 53 故障转移、AWS FIS
阶段 4：持续改进 — SLO/SLI 定义、事后复盘流程、季度韧性评估

每阶段应包含详细任务卡（任务 ID、工作量、依赖、负责人、里程碑、成功标准）、资源需求和实施风险缓解策略。

任务 8: 持续改进机制

1. 定期韧性评估：季度执行，包含自动化扫描、手动架构审查、风险清单更新、优先级调整。

2. 韧性指标持续监控：定义 SLI/SLO，建立错误预算政策（预算耗尽时冻结非关键发布，充裕时可加速功能发布和混沌实验）。

3. 事后复盘流程（Postmortem）：遵循无责任文化原则，使用标准复盘模板（时间线、根因、影响、行动项）。复盘模板示例参见 example-report-template_zh.md。

4. 韧性知识库：建立集中式知识库，包含 Runbooks/、Postmortems/、Architecture/、Playbooks/ 等目录。

5. 团队技能培养：AWS Well-Architected 认证、SRE 实践培训、混沌工程工作坊、DR 演练、灾难角色扮演（Wheel of Misfortune）。

Analysis Tasks — Detailed Instructions

Task 1: System Component Mapping and Dependency Analysis

Tools Used: Read-only API calls via MCP servers (aws-api-mcp-server) if available, Mermaid diagrams. Do not use Bash to execute any aws CLI commands to access AWS resources.

Output: 1. System Architecture Overview (Mermaid, showing Region/AZ/component hierarchy) 2. Component Dependency Diagram (marking synchronous/asynchronous dependencies, strong/weak dependencies, critical paths) 3. Data Flow Diagram (request paths, data flows, integration points) 4. Network Topology Diagram (VPC, subnets, security groups, route tables, NAT gateways, VPN/Direct Connect)

Multi-Account Considerations (if the architecture spans multiple AWS accounts):

AWS Organizations SCP (Service Control Policy) impact on resilience
Cross-account resource sharing and DR strategy (e.g., shared VPC, cross-account backup vaults)
Centralized vs. decentralized backup and monitoring strategy
Cross-account IAM trust relationships and failover permissions

Task 2: Failure Mode Identification and Classification (Based on AWS Resilience Analysis Framework)

Reference Resources:

AWS Prescriptive Guidance - Resilience Analysis Framework
See resilience-framework.md for the index of all reference files. Load only the specific sub-file relevant to your current task:
waf-reliability-pillar.md — DR strategies, Multi-AZ/Multi-Region
resilience-analysis-core.md — Error budget, SLI/SLO, golden signals, postmortem
chaos-engineering-methodology.md — Experiment process, FIS templates
observability-standards.md — OpenTelemetry, logs/metrics/traces
cloud-design-patterns.md — Bulkhead, circuit breaker, retry

Identify the following failure mode categories:

Failure Category	Description	Inspection Points
Single Point of Failure (SPOF)	Critical components lacking redundancy	Single-AZ deployment, single-instance database, no failover configured
Excessive Latency	Performance bottlenecks and latency issues	Network latency, database queries, API timeouts
Excessive Load	Capacity limits and traffic spikes	Auto Scaling configuration, service quotas, traffic peaks
Misconfiguration	Non-compliance with best practices	Security groups, IAM policies, backup policies
Shared Fate	Tight coupling and lack of isolation	Cross-service dependencies, regional dependencies, quota sharing

For each failure mode provide: Detailed technical description, current configuration issues, involved AWS services and resource ARNs, trigger conditions and scenarios, business impact assessment.

Risk Classification: Infrastructure / Middleware & Database / Container Platform / Network / Data / Security & Compliance.

Task 3: Resilience Assessment (5-Star Rating System)

Rate each critical component (1 star = inadequate, 5 stars = excellent):

Assessment Dimensions:

Dimension	Assessment Question	Rating Criteria
Redundancy Design	Does the component have sufficient redundancy?	1: Single point / 2: Same-AZ redundancy / 3: Multi-AZ manual failover / 4: Multi-AZ auto failover + cross-region backup / 5: Multi-region active-active
AZ Fault Tolerance	Can it withstand a single AZ failure?	1: Single AZ / 2: Multi-AZ without auto failover / 3: Multi-AZ with auto failover / 4: Multi-AZ + periodic DR drills / 5: Multi-AZ + multi-region failover tested
Timeout & Retry	Are there appropriate timeout and retry strategies?	1: Not configured / 2: Basic fixed timeouts / 3: Configurable timeouts + simple retry / 4: Exponential backoff + jitter / 5: Exponential backoff + circuit breaker + bulkhead
Circuit Breaker	Is there a mechanism to prevent cascading failures?	1: None / 2: Basic health checks / 3: Circuit breaker on critical paths / 4: Circuit breaker + graceful degradation / 5: Full circuit breaker + degradation + load shedding
Auto Scaling	Can it handle load increases?	1: Fixed capacity / 2: Manual scaling / 3: Target tracking Auto Scaling / 4: Predictive + reactive Auto Scaling / 5: Multi-dimensional Auto Scaling + capacity reservations
Configuration Safeguards	Are there measures to prevent misconfiguration?	1: Manual / 2: Documented procedures / 3: IaC templates / 4: IaC + automated validation + drift detection / 5: IaC + policy-as-code + automated rollback
Fault Isolation	Are fault isolation boundaries clearly defined?	1: Monolith / 2: Basic service separation / 3: Service-level isolation / 4: Cell-based architecture / 5: Cell architecture + bulkhead + shuffle sharding
Backup & Recovery	Is there a data backup and recovery mechanism?	1: No backup / 2: Manual backups / 3: Automated backups + tested restore / 4: Cross-region backup + periodic DR testing / 5: Cross-region + automated recovery testing + PITR
Best Practices	Does it comply with Well-Architected?	1: Multiple violations / 2: Partial compliance / 3: Mostly compliant + known gaps / 4: Fully compliant + optimization in progress / 5: Fully compliant + continuous improvement

Mapping: Modeling 9 Dimensions ↔ RMA 10 Domains

If the user has also completed an RMA Assessment (aws-rma-assessment skill), use this mapping to cross-reference results:

Modeling Dimension	RMA Domain(s)	Mapping Notes
Redundancy Design	D2: Design for Multi-Location (Q7-Q9)	Modeling rates per-component; RMA rates organizational approach
AZ Fault Tolerance	D2: Design for Multi-Location (Q7-Q9), D10: Disaster Recovery (Q46-Q52)	Modeling focuses on technical AZ config; RMA includes DR governance
Timeout & Retry	D3: Design Interactions (Q10-Q13)	Direct mapping — both assess timeout/retry/backoff strategies
Circuit Breaker	D3: Design Interactions (Q10-Q13), D8: Fault Isolation (Q36-Q39)	Modeling covers circuit breaker specifically; RMA is broader (interactions + isolation)
Auto Scaling	D1: Design Your Workload (Q1-Q6)	Modeling rates scaling capability; RMA rates overall workload design maturity
Configuration Safeguards	D4: Design Distributed Systems (Q14-Q17), D5: Change Management (Q18-Q22)	Modeling focuses on IaC/validation; RMA adds change management process
Fault Isolation	D8: Fault Isolation (Q36-Q39)	Direct mapping
Backup & Recovery	D10: Disaster Recovery (Q46-Q52)	Direct mapping
Best Practices	All Domains (aggregate)	Modeling rates WAF compliance; RMA provides granular domain-level maturity

Score Conversion Guide (approximate):

Modeling Star Rating	Approximate RMA Level	Interpretation
⭐ (1 star)	Level 0-1	Not implemented or ad-hoc
⭐⭐ (2 stars)	Level 1-2	Basic implementation, manual processes
⭐⭐⭐ (3 stars)	Level 2-3	Standardized, partially automated
⭐⭐⭐⭐ (4 stars)	Level 3-4	Well-automated, regularly tested
⭐⭐⭐⭐⭐ (5 stars)	Level 4-5	Optimized, continuously improving

⚠️ This mapping is approximate. Modeling scores reflect technical implementation depth for specific components; RMA levels reflect organizational maturity across people, process, and tools.

Task 4: Business Impact Analysis

1. Identify Critical Business Processes (user registration/login, order processing, payment transactions, data analytics, etc.) 2. Assess Component Failure Impact (component -> failure scenario -> affected business functions -> impact severity -> user impact -> current/target RTO) 3. RTO/RPO Compliance Analysis (can the current architecture meet business objectives, gap analysis, priority improvement areas)

Task 5: Risk Prioritization

Risk Scoring Matrix: Risk Score = (Probability x Business Impact x Detection Difficulty) / Remediation Complexity

Risk ID	Failure Mode	Probability (1-5)	Impact (1-5)	Detection Difficulty (1-5)	Remediation Complexity (1-5)	Risk Score	Priority
R-001	RDS Single AZ	3	5	2	2	15	High
R-002	Missing Auto Scaling	4	4	1	3	5.3	Medium

Risk Score Severity Thresholds:

Severity	Score Range	Action Required
Critical	>= 20	Immediate remediation required
High	10 - 19	Remediation within current sprint
Medium	4 - 9	Plan remediation in next quarter
Low	< 4	Monitor and address as capacity allows

Also perform Cascading Effect Analysis: Identify correlations between risks, assess multi-point failure scenarios, worst-case impact analysis.

Task 6: Mitigation Strategy Recommendations

For high-priority risks, provide specific, actionable recommendations. Each risk should include:

1. Architecture Improvement: Before/after comparison (Mermaid diagrams) showing the improvement plan 2. Configuration Optimization: Specific AWS CLI commands or IaC code 3. Monitoring & Alerting: CloudWatch alarm configuration (metrics, thresholds, alarm levels, response SLA) 4. AWS Service Recommendations: Recommended services, value proposition, cost impact 5. Implementation Assessment: Complexity, expected outcomes, implementation risks, cost range, priority

See example-report-template.md for complete mitigation strategy examples.

Task 7: Implementation Roadmap

Phased Implementation Plan (based on risk priority and dependencies), using Mermaid Gantt charts:

Phase 1: Foundational Resilience -- Multi-AZ deployment, automated backup, basic monitoring and alerting
Phase 2: Automation -- IaC migration, CI/CD pipelines, Auto Scaling
Phase 3: DR and Chaos Engineering -- Aurora Global Database, Route 53 failover, AWS FIS
Phase 4: Continuous Improvement -- SLO/SLI definition, postmortem process, quarterly resilience reviews

Each phase should include detailed task cards (task ID, effort, dependencies, owner, milestones, success criteria), resource requirements, and implementation risk mitigation strategies.

Task 8: Continuous Improvement Mechanisms

1. Regular Resilience Assessments: Quarterly execution including automated scanning, manual architecture review, risk inventory updates, priority adjustments.

2. Continuous Resilience Metrics Monitoring: Define SLI/SLO, establish error budget policies (freeze non-critical releases when budget is exhausted; accelerate feature releases and chaos experiments when budget is ample).

3. Postmortem Process: Follow blameless culture principles, use a standard postmortem template (timeline, root cause, impact, action items). See example-report-template.md for postmortem template examples.

4. Resilience Knowledge Base: Build a centralized knowledge base including Runbooks/, Postmortems/, Architecture/, Playbooks/ directories.

5. Team Skill Development: AWS Well-Architected certification, SRE practice training, Chaos Engineering workshops, DR drills, Wheel of Misfortune exercises.

合规框架映射

将韧性分析任务映射到合规框架的参考指引。这不是正式的合规认证。

合规框架	相关控制域	映射到分析任务
SOC2 CC7.x（系统运营）	监控、事件响应、变更管理	任务 2（故障模式）、任务 5（风险排序）
SOC2 CC9.x（风险缓解）	风险评估、缓解策略	任务 5（风险）、任务 6（缓解）
ISO 27001 A.17（业务连续性）	BC 规划、DR 实施、测试	任务 4（业务影响）、任务 6（缓解）
NIST CSF PR（保护）	保护性技术、数据安全	任务 1（架构）、任务 3（评估）
NIST CSF DE/RS/RC（检测/响应/恢复）	检测、响应、恢复	任务 2、5、6、8

使用说明

此映射为参考指引，帮助识别哪些分析任务与特定合规要求相关
不构成正式的合规认证或审计证据
某些合规要求可能限制架构选项（如数据驻留）
确保 DR 策略符合审计要求
文档和审计跟踪对合规至关重要

Compliance Framework Mapping

Reference guide for mapping resilience analysis tasks to compliance frameworks. This is not a formal compliance certification.

Compliance Framework	Relevant Control Areas	Mapping to Analysis Tasks
SOC2 CC7.x (System Operations)	Monitoring, incident response, change management	Task 2 (Failure Modes), Task 5 (Risk Prioritization)
SOC2 CC9.x (Risk Mitigation)	Risk assessment, mitigation strategies	Task 5 (Risk), Task 6 (Mitigation)
ISO 27001 A.17 (Business Continuity)	BC planning, DR implementation, testing	Task 4 (Business Impact), Task 6 (Mitigation)
NIST CSF PR (Protect)	Protective technology, data security	Task 1 (Architecture), Task 3 (Assessment)
NIST CSF DE/RS/RC (Detect/Respond/Recover)	Detection, response, recovery	Task 2, Task 5, Task 6, Task 8

Usage Notes

This mapping is a reference guide to help identify which analysis tasks are relevant for specific compliance requirements
It does not constitute formal compliance certification or audit evidence
Certain compliance requirements may limit architecture options (e.g., data residency)
Ensure DR strategies meet audit requirements
Documentation and audit trails are critical for compliance

Related skills

Azure AiIntegrates Azure AI Content Safety, Document Intelligence, Speech, and Search services into Java-based agents and applications.495k1.4k

Azure PrepareGenerate the exact Azure infrastructure files, Dockerfiles, and azure.yaml configuration needed before deploying any new or modernized application.494k1.4k

Azure StorageConnect agents and applications to Azure Blob Storage, File Shares, Queues, Tables, and Data Lake without leaving the coding environment.494k1.4k

Appinsights InstrumentationAutomatically instrument web applications running on Azure App Service with Application Insights for observability without manual configuration.493k1.4k

Azure Resource LookupInstantly list, query, and discover any Azure resources across subscriptions without leaving the agent chat.493k1.4k

Azure AigatewayConfigure Azure API Management as a secure, governed gateway for routing traffic to LLMs, MCP servers, and agent tools.493k1.4k

FAQ

Does aws-resilience-modeling need MCP servers?

No. If MCP is not configured it falls back to analyzing IaC code, architecture documentation, or interactive Q&A.

Is it safe to run against production?

Yes. All MCP servers run in read-only mode using only Describe, Get, and List calls.

Cloud & Infrastructureinframonitoring