1. 课程导入与优化思维建立

在 AWS 生产环境中，成本与性能经常被当成一对矛盾：为了省钱就降配、缩容、缩短日志保留期，结果延迟上升、错误率增加；为了性能就无脑加实例、换更大规格、开更多缓存，结果账单失控。真正成熟的优化不是二选一，而是把两者放进同一个决策框架里，寻找“单位性能成本”最低的工作点。本课程的核心命题是：成本优化不能以牺牲可接受的性能为代价，性能提升也必须能说清它换来了什么业务价值。

一、为什么成本与性能必须协同看

先看一个典型的生产现象。某在线服务在 us-east-1 运行，使用 Application Load Balancer 后接 6 台 m6i.large 的 EC2 实例，平均 CPU 利用率约 18%，P99 延迟 420 ms，每月计算成本约 620 美元。直觉上“利用率这么低，砍掉一半实例就行”。但如果直接降到 3 台，峰值时段 CPU 会冲到 75% 以上，P99 延迟可能升到 900 ms 以上，触发前端超时重试，反而放大后端压力。这说明：利用率低不等于资源过剩，延迟指标才是判断能否缩容的约束条件。

反过来，性能优化也可能带来成本收益。例如把一次请求中 5 次串行的数据库查询改为 1 次批量查询，单请求处理时间从 120 ms 降到 45 ms，同样的实例数可以承载约 2.5 倍的并发，于是可以在不增加成本的前提下提升吞吐，或者减少实例数而保持原有延迟。这里成本与性能是同向改善的，关键在于找到“瓶颈在哪、改动影响哪条链路”。

二、FinOps 与性能工程的结合框架

FinOps 关注“谁在花什么钱、花得值不值”，性能工程关注“系统在什么负载下表现如何”。两者结合，才能回答“这笔钱该不该花、花在哪里最有效”。一个可落地的工作框架包含四个层次：

• 可见性层：把成本数据（Cost Explorer、CUR、标签）与性能数据（CloudWatch、X-Ray、ALB 目标组指标）对齐到同一资源、同一时间窗口。没有对齐，就无法判断“贵”和“慢”是否同源。
• 归因层：按服务、环境、团队、业务域打标签，把账单拆到可负责的粒度；同时把延迟、错误率、吞吐按同一维度聚合。
• 决策层：用 SLO 作为硬约束，用单位性能成本作为优化目标，评估扩缩容、规格调整、缓存、存储分层、预留与 Spot 等杠杆。
• 执行与验证层：小步变更、灰度发布、对比变更前后的成本与性能指标，确认没有把风险转移到别处。

下面这张图把上述框架与“成本—性能”双向影响关系放在一起，便于建立整体心智模型。

三、核心原则：不牺牲性能的成本优化

把上面的框架落到日常决策，可以归纳为四条原则。

第一，先定义“可接受的性能”，再谈省钱。没有 SLO 的优化是盲目的。例如一个内部报表服务可以接受 P95 2 秒，而一个支付接口必须 P99 小于 300 ms。前者可以大胆使用 Spot 实例和较低规格，后者则要保留冗余和更保守的扩缩容策略。SLO 不同，优化空间完全不同。

第二，用数据定位瓶颈，而不是凭感觉降配。如果 CPU 利用率低但延迟高，瓶颈可能在数据库连接池、下游 API 或磁盘 IOPS，此时缩容只会让情况更糟。正确做法是先看 CloudWatch 的 CPU、内存、网络、磁盘队列，再看 X-Ray 链路中各段的耗时占比，确认瓶颈位置后再选择杠杆。

第三，优先做“同向优化”。即那些既降成本又提性能的改动，例如：减少不必要的跨可用区数据传输、把频繁读取的小对象放入 ElastiCache、把冷数据从 gp3 迁到 S3 Glacier、合并串行调用为并行或批量。这类改动风险低、收益明确，应优先执行。

第四，任何变更都要有前后对比和回滚路径。成本优化最怕“省了小钱、赔了大钱”。建议在变更前记录基线：单位请求成本、P99 延迟、错误率、CPU 峰值；变更后观察至少一个完整业务周期（例如 7 天），确认 SLO 未破、成本确实下降，再固化到标准配置中。

四、一个可复用的决策示例

假设某 API 服务当前使用 8 台 c6i.xlarge，月成本约 980 美元，P99 延迟 380 ms，SLO 要求 P99 小于 500 ms，日均请求 2000 万次。通过分析发现：CPU 平均利用率 22%，但 P99 延迟中有 60% 消耗在一次同步的第三方调用上。此时直接缩容到 5 台，CPU 会升到 35% 左右，延迟可能因排队而恶化；而如果把第三方调用改为异步加本地缓存，单请求耗时下降 150 ms，则可以在保持 P99 约 300 ms 的同时缩容到 5 台，月成本降到约 610 美元，单位请求成本下降约 38%。这个例子说明：真正的降本空间往往来自架构和调用链优化，而不是简单地减少实例数量。