reliability-improvement-plan

可靠性改进计划

步骤 1：收集背景信息

询问用户：

你希望我评估哪项工作负载的可靠性？请提供：

• 工作负载名称以及要分析的代码包／目录
• 可用性目标（99.9%、99.95%、99.99% 等）
• 恢复目标（如已定义，请提供 RTO 和 RPO）
• 过往事故（可选，例如近期的服务中断或险些发生的事故）

如果已提供相关背景信息，或你正在检查的代码库中包含 IaC，请直接继续。

步骤 2：发现容错能力

分析基础设施是否存在单点故障。

你必须检查：

• 计算部署（AZ 分布、实例数量、ASG 配置）
• 数据库配置（Multi-AZ、只读副本、集群拓扑）
• 缓存配置（集群模式、副本数量、故障转移）
• 负载均衡器配置（跨区、运行状况检查、目标组）
• NAT Gateway 部署位置（单个或每个 AZ 一个）
• DNS 配置（Route 53 运行状况检查、故障转移路由）
• 队列和消息传递配置（DLQ、重新投递策略）
• 存储冗余（S3 复制、EBS 快照、EFS）

对于每个组件，请记录：

• 文件路径和行号
• 当前冗余级别（单 AZ、多 AZ、多区域）
• 故障影响范围
• 故障转移机制（自动、手动、无）

对于以下情况，你必须标记为 HIGH RISK：

• 面向生产工作负载的单 AZ 数据库部署
• 没有自动扩缩的计算资源（实例数量固定）
• 负载均衡目标没有运行状况检查
• 单个 NAT Gateway 为多个 AZ 提供服务
• 未配置复制的有状态服务
• 异步调用（Lambda、SQS、EventBridge）缺少 DLQ
• 调用外部服务时没有熔断器或超时设置

步骤 3：发现恢复能力

分析备份和恢复配置。

你必须检查：

• AWS Backup 计划和规则
• RDS 自动备份设置（保留期、PITR）
• S3 版本控制和复制规则
• DynamoDB PITR 和备份设置
• EBS 快照配置
• 跨区域复制规则
• 灾难恢复配置（pilot light、warm standby 资源）

对于每项有状态资源，请记录：

• 备份频率和保留期
• 恢复点能力（RPO）
• 恢复时间估算（RTO）
• 是否测试过恢复（查找 DR 操作手册、FIS 实验）

对于以下情况，你必须标记为 HIGH RISK：

• 有状态资源未配置备份
• 生产数据的备份保留期少于 7 天
• 关键数据没有跨区域备份
• 没有恢复测试的证据（没有 FIS 实验或 DR 操作手册）

步骤 4：发现扩缩能力和容量

分析扩缩和容量配置。

你必须检查：

• Auto Scaling Group 配置（最小值、最大值、期望值、扩缩策略）
• ECS 服务扩缩（目标跟踪、分步扩缩）
• Lambda 并发设置（预留并发、预置并发）
• DynamoDB 容量模式（按需或预置、自动扩缩）
• SQS／Kinesis 吞吐量配置
• API Gateway 节流设置
• 服务配额用量和警报

对于以下情况，你必须标记为 HIGH RISK：

• 计算资源没有自动扩缩策略
• ASG 的 min = max（没有扩缩余量）
• 没有服务配额警报
• 关键函数的 Lambda 没有预留并发
• 过载场景下没有负载削减或节流机制

步骤 5：韧性模式发现

分析应用程序代码中的韧性模式。

你必须检查：

• 重试配置（SDK 客户端、自定义重试逻辑）
• 超时设置（HTTP 客户端、数据库连接、Lambda 超时）
• 熔断器实现
• 失败回退逻辑和优雅降级模式
• 幂等性处理（幂等键、去重）
• 健康检查端点实现
• 连接池配置

对于每项外部集成，请记录：

• 超时配置（或未配置）
• 重试策略（指数退避、最大尝试次数、抖动）
• 熔断器（存在或不存在）
• 失败时的回退行为

你必须将以下情况标记为高风险：

• 调用外部服务时未设置超时
• SDK 客户端没有重试逻辑
• 事件驱动处理缺少幂等性
• 未验证实际功能的健康检查（浅层检查）
• Lambda 超时 ≥ API Gateway 超时（调用方将始终超时）

步骤 6：变更管理发现

分析部署安全配置。

你必须检查：

• 部署策略（金丝雀、蓝绿、滚动、一次性全部部署）
• 部署时的健康检查门控
• 自动回滚配置（基于告警）
• 数据库迁移策略（向后兼容、蓝绿架构）
• 功能标志的使用

你必须将以下情况标记为高风险：

• 在生产环境中一次性全部部署
• 健康检查失败时没有自动回滚
• 数据库迁移不向后兼容
• 没有拓扑与生产环境一致的预生产环境

---STOP--- 检查点：发现阶段已完成——请先呈现发现结果，再进行评估。

以下是我对你的工作负载可靠性的发现：

• 架构：{组件和依赖项摘要}
• 单点故障：{目前发现的数量}
• 恢复能力：{备份/灾难恢复状态摘要}

要继续进行完整的可靠性评估，还是要调整范围？

在用户明确确认之前，不得越过此处继续。

---

步骤 7：根据 WA 框架问题进行评估

对于每个问题，请提供：状态、证据（文件:行号）、差距、风险。

REL 1 — 如何管理服务配额和限制？

• 证据：配额告警、SDK 重试配置、限流处理代码

REL 2 — 如何规划网络拓扑？

• 证据：子网定义、AZ 分布、NAT 冗余

REL 3 — 系统如何适应需求变化？

• 证据：ASG 配置、扩缩策略、Lambda 并发、DynamoDB 容量模式

REL 4 — 如何设计分布式系统中的交互以防止故障？

• 证据：重试逻辑、超时配置、SQS 解耦、幂等令牌

REL 5 — 如何设计交互以缓解或抵御故障？

• 证据：熔断器代码、回退路径、舱壁模式、负载削减

REL 6 — 如何监控工作负载资源？

• 证据：健康检查端点、告警定义、复合告警、仪表板配置

REL 7 — 如何设计工作负载以适应需求变化？

• 证据：扩缩策略指标、计划扩缩、预测性扩缩配置

REL 8 — 如何实施变更？

• 证据：部署配置、健康检查门控、回滚触发告警

REL 9 — 如何备份数据？

• 证据：AWS Backup 计划、PITR 设置、复制规则、快照配置

REL 10 — 如何利用故障隔离保护工作负载？

• 证据：AZ 分布、基于单元的模式、随机分片、隔离边界

REL 11 — 如何设计工作负载以抵御组件故障？

• 证据：多可用区配置、故障转移策略、无状态设计、基于健康状况的路由

REL 12 — 如何测试可靠性？

• 证据：FIS 实验、故障注入代码、演练日运行手册、灾难恢复测试脚本

REL 13 — 如何规划灾难恢复（DR）？

• 证据：跨区域资源、DR 自动化、备份恢复流程、RTO/RPO 文档

步骤 8：风险评估

对每项发现，使用影响 × 可能性进行评估：

影响：轻微（短暂降级，自动恢复）| 中等（部分用户长时间无法使用，需要人工干预）| 严重（全面中断、数据丢失、无法在 RTO 内恢复）

可能性：低（需要多个故障同时发生）| 中（单个组件故障即可触发）| 高（常见运维事件即可触发，且没有冗余）

影响	可能性	风险等级
严重	高	严重
严重	中	高
严重	低	高
中等	高	高
中等	中	中
中等	低	中
轻微	高	中
轻微	中	低
轻微	低	低

---STOP--- 检查点：评估已完成——请在生成修复计划前确认发现。

评估摘要：

• 严重问题：{count}
• 高风险问题：{count}
• 中/低风险问题：{count}

要我生成完整的修复计划，还是先讨论具体发现？

在用户明确确认前，请勿继续。

---

步骤 9：制定计划

# Reliability Improvement Plan: {Workload Name}

## Executive Summary
- **Date**: {date}
- **Availability Target**: {target}
- **Packages Analyzed**: {list}
- **Findings**: {X} Critical, {Y} High, {Z} Medium, {W} Low
- **Overall Reliability Maturity**: {1-5} — {one-line justification}

## Reliability Scorecard
| Domain | Score (1-5) | Key Strength | Key Gap |
|--------|-------------|--------------|---------|
| Fault Tolerance | {score} | {strength} | {gap} |
| Recovery & Backup | {score} | {strength} | {gap} |
| Scaling & Capacity | {score} | {strength} | {gap} |
| Resilience Patterns | {score} | {strength} | {gap} |
| Change Management | {score} | {strength} | {gap} |
| Testing & Validation | {score} | {strength} | {gap} |

## Single Points of Failure
| Component | Evidence | Failure Impact | Current Mitigation | Risk Level |
|-----------|----------|---------------|-------------------|------------|
| {component} | {file:line} | {impact} | {mitigation or "None"} | {Critical/High/Medium/Low} |

## Critical and High Risk Findings
{For each: ID, domain, title, description, evidence (file:line), impact assessment, recommendation, effort, AWS services}

## Medium and Low Risk Findings
{Condensed format}

## Prioritized Remediation Plan

### Quick Wins (< 1 week)
| Finding | Action | Impact | Effort |
|---------|--------|--------|--------|
{Enable Multi-AZ, add health checks, configure DLQs, add timeouts}

### Foundation (1-4 weeks)
| Finding | Action | Impact | Effort | Dependencies |
|---------|--------|--------|--------|--------------|
{Auto-scaling, circuit breakers, backup configs, deployment safety}

### Strategic (1-3 months)
| Finding | Action | Impact | Effort | Dependencies |
|---------|--------|--------|--------|--------------|
{Multi-region DR, chaos engineering, cell-based architecture}

## Testing Plan
| Test | Validates | Frequency | AWS Service | Evidence Exists |
|------|-----------|-----------|-------------|-----------------|
| AZ failover | Compute survives AZ loss | Monthly | FIS | {Yes/No} |
| Database failover | RDS failover < 60s | Quarterly | FIS | {Yes/No} |
| Load test | Handles 2x peak | Before releases | Load Testing | {Yes/No} |
| Backup restore | RPO met, data recoverable | Monthly | AWS Backup | {Yes/No} |
| Deployment rollback | Bad deploy reverted < 5 min | Every deploy | CodeDeploy | {Yes/No} |

## Next Steps
{Top 5 concrete reliability actions the team should take this week}

步骤 10：提供后续选项

交付计划后，提供以下选项：

你希望我：

• 为特定组件设计多可用区架构？
• 生成用于混沌工程的 FIS 实验模板？
• 为服务依赖实现熔断器模式？
• 为有状态资源创建备份和 DR IaC？
• 设计带自动回滚功能的部署安全配置？

校准指南

• 具备多可用区、自动扩缩容、运行状况检查、自动回滚和备份的工作负载属于成熟状态——重点关注高级测试（混沌工程、DR 演练、演练日）
• 每项发现都必须有代码证据——未经 IaC 检查，不要标记“缺少多可用区”
• 对于数据管道：优先保障数据持久性，而非计算可用性——消息丢失比处理延迟更糟
• 根据可用性目标设定预期：99.9% 不需要多区域，99.99% 则需要
• 对于代码中不可见的运维事项，“无法确定”是合理结论（例如，是否实际进行了 DR 演练）
• 在列出差距前，醒目地说明现有的可靠性模式