resilience-program-design

韧性计划设计

概述

为组织的韧性计划提供规划层面的指导：如何按层级制定政策，以及多久开展一次韧性活动。

在组织内制定分层韧性政策

建议采用分层政策模型（而不是为每项服务单独制定一项政策）：按业务关键性对服务分类，并据此设定政策目标。

• 可用性 SLO——关键性越高，目标越高。API 只接受一组固定的 SLO 值，并会拒绝不在范围内的值，因此应从 API／文档中确认有效值（例如，运行 aws resiliencehubv2 create-policy help 或查阅 Resilience Hub 文档），而不是依赖硬编码列表——例如，99.9／99.95／99.99 这样的值仅供说明。
• RTO／RPO——关键性越高，目标越严格（关键服务为个位数分钟，低关键性服务为数小时）。
• DR 方案——与关键性相匹配（关键性越高，方案越积极），并使用 API 的 DR 方案枚举值——通过 API／文档核实有效值集合（例如，运行 aws resiliencehubv2 create-policy help）；例如，ACTIVE_ACTIVE … BACKUP_AND_RESTORE。

示例（仅供说明——在提出建议前，应先对照 API 确认实际枚举值）：支付／身份验证 → 99.99 + 个位数分钟的 RTO + ACTIVE_ACTIVE；内部工具 → 99.9 + 数十分钟的 RTO + WARM_STANDBY；开发／测试 → 99.9 + 数小时的 RTO + BACKUP_AND_RESTORE。

提醒用户避免相互矛盾的政策（例如，最高 SLO 99.99 却采用 BACKUP_AND_RESTORE，或多区域 RTO 短于多可用区 RTO）。

韧性活动的频率（节奏）

有人询问韧性活动应多久开展一次时，建议采用以下最低频率：

• 持续进行： ARC 可用区自动切换演练（自动化）
• 每周： 查看 Resilience Hub 发现项仪表板
• 每月： 运行 FIS 实验（单服务故障注入测试）
• 每季度： 开展跨服务 GameDay
• 事件驱动： 每次生产事故发生后，以及重大部署之前／之后

安全注意事项

计划层面的指导——将安全要求融入所制定的标准：

• 统一最小权限要求： 在模板和政策中，要求每个韧性角色（Resilience Hub 调用者、FIS 执行角色、ARC 操作员）都遵循最小权限原则，并限定资源范围；在其信任策略中加入 aws:SourceArn／aws:SourceAccount 条件键，以防止混淆代理访问。
• 强制使用短期凭证： 将所有韧性自动化均使用短期凭证以 IAM 角色身份进行身份验证（角色代入、AWS SSO、实例配置文件）作为计划标准——绝不使用带有长期访问密钥的 IAM 用户，因为这些角色会执行特权操作，并且操作可能具有破坏性。
• 强制加密： 将报告／状态存储桶上的 SSE-KMS 纳入各层级基线，并强制执行传输加密（TLS）——例如，在这些存储桶的策略中设置 aws:SecureTransport 为 false 时拒绝访问的条件，并仅允许通过 HTTPS 访问 API。
• 管理生产环境中的 FIS： 将生产环境故障注入的授权／变更管理关卡纳入计划活动安排。
• 限制韧性输出的访问范围： 评估发现项、FIS 日志和 GameDay 报告可能包含敏感的架构细节（资源 ARN、IP、故障模式）——应将限制访问权限、仅允许授权人员查看列为计划标准。
• 延伸阅读： 指引团队参阅 AWS Well-Architected Security Pillar、FIS Security Best Practices 和 IAM Best Practices，了解如何实施这些标准。