sustainability-optimization

可持续性优化评估

步骤 1：收集背景信息

询问用户：

你希望我评估哪个工作负载的可持续性？请提供以下信息：

• 工作负载名称以及要分析的代码包/目录
• 可持续性目标（可选 — 组织碳排放目标、报告要求）
• 已知的空闲时段（可选 — 非工作时间、周末、季节性模式）

如果已提供背景信息，或你当前位于代码库中，请直接继续。

步骤 2：计算资源效率发现

分析计算资源配置的效率。

你必须检查：

• 实例类型选择（Graviton 与 x86 — Graviton 的每瓦价格性能最高可提升 40%）
• 自动扩缩配置（资源能否缩减至零？）
• Lambda 配置（内存规格优化、arm64 与 x86_64 架构）
• 容器配置（基础镜像大小、多阶段构建、运行时效率）
• 批处理配置（调度、实例选择）
• 定时扩缩（非生产环境、非工作时间的容量）
• 无服务器与预置资源的选择（Lambda/Fargate 与始终运行的 EC2）

对于每项计算资源，请记录：

• 文件路径和行号
• 架构（arm64/x86_64）
• 扩缩配置（最小值/最大值、能否缩减至零）
• 是否始终运行或由事件驱动

你必须标记：

• 存在 Graviton/arm64 可用且受支持时仍使用 x86_64 的实例/Lambda
• 为可变或事件驱动工作负载使用始终运行的计算资源（Lambda/Fargate 可缩减至零）
• 非生产环境以生产规模 24/7 运行
• 存在明显空闲时段的环境未配置定时扩缩
• Lambda 上非延迟关键型的预置并发
• 可采用多阶段构建或 distroless 的大型容器镜像

步骤 3：数据与存储效率发现

分析数据管理的可持续性。

你必须检查：

• S3 生命周期策略（转换至成本更低/效率更高的存储层、过期规则）
• S3 Intelligent-Tiering 的采用情况
• CloudWatch 日志保留设置
• 数据压缩配置（S3、API 响应、数据库）
• 备份保留策略（过度保留会浪费存储空间）
• 用于旧版本的 S3 版本控制生命周期规则
• DynamoDB TTL 配置
• 快照保留和自动清理

对于每项存储资源，请记录：

• 文件路径和行号
• 生命周期策略（有或无）
• 保留设置
• 压缩设置
• 与访问模式的匹配情况

你必须标记：

• 未配置生命周期策略的 S3 存储桶（数据会无限累积）
• 保留策略设置为“永不过期”的 CloudWatch 日志
• 存储时序数据的 DynamoDB 表未配置 TTL
• 可压缩却未压缩的数据存储
• 备份保留超过 90 天且没有合规性依据
• 配置了 S3 版本控制却没有版本过期规则
• 访问模式未知的存储桶未使用 Intelligent-Tiering

步骤 4：架构效率发现

分析架构模式的可持续性。

你必须检查：

• 托管服务与自管理服务的使用情况（MSK 与自管理 Kafka、ElastiCache 与自管理 Redis）
• 事件驱动模式与轮询模式
• 批处理与实时处理（是否可以将操作批处理？）
• 缓存层（减少重复计算）
• 数据传输模式（在靠近数据的位置进行处理，尽量减少跨区域/跨 AZ 传输）
• API 设计效率（过度获取、频繁往返调用的 API）
• 对非时效性操作采用异步处理

你必须标记：

• 存在托管替代方案却仍使用自管理基础设施（托管服务可在规模化时提高资源利用率）
• 存在事件驱动模式可减少空闲计算资源却仍采用轮询模式
• 存在批处理操作却仍逐项调用 API
• 缺少缓存导致重复计算
• 频繁往返调用的 API 导致网络通信过多

步骤 5：提升开发与部署效率

分析 CI/CD 和开发实践的可持续性。

你 MUST 检查：

• 容器镜像优化（多阶段构建、层缓存、镜像大小）
• CI/CD 流水线效率（缓存、增量构建、并行执行）
• 构件管理（保留、清理）
• 测试环境生命周期（自动销毁、TTL）
• 部署策略效率（测试时采用最小化部署）

你 MUST 标记：

• 未使用多阶段构建且体积较大的 Docker 镜像
• CI/CD 流水线中没有缓存（每次都重新构建所有内容）
• 未配置自动销毁的测试环境
• 可以采用增量部署却仍进行冗余的全量部署

步骤 6：提升区域与硬件效率

分析区域和硬件的选择。

你 MUST 检查：

• 区域选择（不同区域的碳强度有所差异）
• 所有资源类型中 Graviton 的采用情况
• 实例代际（较旧代际每次操作的效率更低）
• 存储层级选择效率

你 MUST 标记：

• 较旧代际的实例（例如，用 m4 而非 m7g，用 t2 而非 t4g）
• 工作负载运行时支持 Graviton/ARM，却仍选择 x86
• 位于高碳排放区域且没有延迟方面理由的资源

---STOP--- 检查点：发现阶段已完成 — 已准备好依据 WA Framework 进行评估

已发现计算效率（{X} 个资源，其中 {Y} 个使用 Graviton/arm64）、数据/存储生命周期配置、架构效率模式、开发/部署实践，以及跨 {packages analyzed} 的区域和硬件选择。

我是否可以继续依据 WA Sustainability 支柱问题评估这些发现并判定影响级别？

在用户明确确认之前，禁止继续。

---

步骤 7：依据 WA Framework 问题进行评估

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

SUS 1 — 你如何选择区域以支持可持续发展目标？

• 证据：区域配置、关于区域选择理由的文档

SUS 2 — 你如何利用用户行为模式？

• 证据：缩容至零配置、计划伸缩、事件驱动架构模式

SUS 3 — 你如何利用软件和架构模式？

• 证据：托管服务、异步处理、批处理操作、缓存层

SUS 4 — 你如何利用数据访问和使用模式？

• 证据：生命周期策略、压缩、分层、Intelligent-Tiering、TTL 配置

SUS 5 — 硬件管理和使用模式如何支持你的可持续发展目标？

• 证据：Graviton/arm64 使用情况、实例代际、恰当调整规格、托管服务

SUS 6 — 开发和部署流程如何支持你的可持续发展目标？

• 证据：多阶段 Docker 构建、CI 缓存、增量部署、构件清理

步骤 8：影响评估

针对每项发现，评估：

资源影响：低（效率略有提升）| 中（资源显著减少）| 高（大量资源被消除或效率大幅提升）

实施工作量：低（配置更改）| 中（需要一定开发工作）| 高（架构更改）

按以下标准排序：影响 / 工作量比（从高到低）

步骤 9：生成发现

# Sustainability Assessment: {Workload Name}

## Executive Summary
- **Date**: {date}
- **Packages Analyzed**: {list}
- **Findings**: {X} High Impact, {Y} Medium Impact, {Z} Low Impact
- **Overall Sustainability Maturity**: {1-5} — {one-line justification}
- **Key Opportunities**: {top 3 highest-impact changes}

## Sustainability Scorecard
| Domain | Score (1-5) | Key Strength | Key Gap |
|--------|-------------|--------------|---------|
| Compute Efficiency | {score} | {strength} | {gap} |
| Data & Storage | {score} | {strength} | {gap} |
| Architecture Efficiency | {score} | {strength} | {gap} |
| Development & Deployment | {score} | {strength} | {gap} |
| Hardware & Region | {score} | {strength} | {gap} |

## High Impact Findings
{For each: ID, domain, title, description, evidence (file:line), resource impact, recommendation, effort, AWS services}

## Medium Impact Findings
{Same format, condensed}

## Low Impact Findings
{Summary table: ID | Domain | Title | Recommendation}

## Resource Efficiency Opportunities
| Resource | Current Config | Optimized Config | Efficiency Gain | Evidence |
|----------|---------------|-----------------|-----------------|----------|
| {resource} | {current} | {optimized} | {gain description} | {file:line} |

## Prioritized Remediation Plan

### Quick Wins (< 1 week)
| Finding | Action | Resource Impact | Effort |
|---------|--------|----------------|--------|
{Set log retention, add lifecycle policies, enable Intelligent-Tiering, schedule non-prod}

### Foundation (1-4 weeks)
| Finding | Action | Resource Impact | Effort | Dependencies |
|---------|--------|----------------|--------|--------------|
{Graviton migration, right-sizing, scale-to-zero, multi-stage Docker builds}

### Strategic (1-3 months)
| Finding | Action | Resource Impact | Effort | Dependencies |
|---------|--------|----------------|--------|--------------|
{Serverless migration, managed service adoption, event-driven architecture, region optimization}

## AWS Sustainability Tools
- **Customer Carbon Footprint Tool** — Track emissions in the AWS console
- **Compute Optimizer** — Right-size recommendations with Graviton suggestions
- **S3 Storage Lens** — Storage efficiency and access pattern insights
- **Trusted Advisor** — Idle resource detection

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

步骤 10：提供后续选项

交付评估后，提供以下选项：

你希望我：

• 为已识别的资源生成 Graviton 迁移 IaC？
• 为非生产环境设计缩容至零策略？
• 为已识别的存储桶实施 S3 生命周期策略？
• 为容器镜像创建多阶段 Docker 构建？
• 设计事件驱动架构以替代轮询模式？
• 实施计划伸缩，以便在非工作时间减少容量？

校准指南

• 使用 Graviton、无服务器架构、生命周期策略和托管服务的工作负载已达到成熟水平——应重点关注高级效率优化（数据本地化、批量聚合、开发实践）
• 每项发现都必须有代码证据——检查基础设施即代码（IaC）之前，不要指出“缺少生命周期策略”
• 应以积极的方式描述可持续性发现（资源效率提升），而非负面描述
• 始终指出可持续性改进是否也能降低成本（双重收益）
• 对于需要 CloudWatch 指标才能获取的利用率数据，“无法确定”是有效结论（建议使用 Compute Optimizer）
• 建议更改区域时，务必考虑延迟要求和数据驻留要求
• 列出差距之前，先肯定已有的可持续性实践