性能、可靠性与成本归因
性能、可靠性和成本需要落到同一个业务单位与责任边界，团队才能判断一次架构优化是否真正创造了价值。
1. 先选择业务单位
只看云账单总额，很难解释成本为何变化。可以根据产品选择单位：
- 每千次 API 请求成本；
- 每笔成功订单成本；
- 每 GB 存储月成本；
- 每个活跃租户成本；
- 每次模型推理或消息处理成本。
业务单位需要同时连接使用量和结果。电商系统如果只算每请求成本，缓存命中产生的大量便宜请求会掩盖下单链路的真实投入；按成功订单计算更接近业务价值。
同一指标长期保持定义稳定。口径变化时记录版本，否则优化前后无法比较。
2. 建立资源所有权
专用数据库或集群可以直接归属服务、团队或租户。共享网关、Kubernetes 集群和消息平台则需要分摊。
成本元数据至少包含：
- 产品、服务和负责团队；
- 环境、地域和 deployment stamp；
- 租户或客户层级；
- 资源类型和采购方式；
- 共享成本分类。
云资源使用账号结构、标签和命名约定；应用层通过 trace、请求数、CPU 时间、存储量和消息量补充归因。标签通常不能追溯应用到历史费用，因此要在资源创建流程中强制校验。
3. 共享成本选择可解释的分摊方式
共享成本可以按固定比例、收入、租户数、请求量或实际资源消耗分配。选择标准是成本驱动关系和可操作性。
例如共享 Kafka 集群按消息字节和保留时长分摊，比按团队人数更接近真实消耗；公共身份平台按活跃用户或认证次数分摊，可能比 CPU 时间更容易理解。
无法准确归因的成本可以暂时作为平台公共预算，但要明确标记。强行使用一个失真的精确公式，会诱导团队优化代理指标而不是整体成本。
4. 性能测量包含负载和尾延迟
优化前记录工作负载、吞吐、错误率、延迟分位数和资源用量。平均延迟降低，但 P99 变差，核心用户仍可能受到影响。
有效基线需要固定：
- 请求和数据分布；
- 缓存冷暖状态；
- 并发、地域和依赖条件；
- JVM、实例和数据库规格；
- 是否达到目标 SLO。
单位资源安全吞吐比单次基准峰值更适合容量和成本计算。安全吞吐要求错误率和尾延迟仍在目标内，并保留故障接管余量。
5. 可靠性投入由用户风险约束
副本、跨地域、冗余供应商和更大的容量余量都会增加成本。可靠性目标从 99.9% 提高到 99.99% 时，新增投入可能包括更独立的故障域、更快复制、更严格发布和更多值班能力。
决策需要比较：
- 当前错误预算消耗和用户影响；
- 故障造成的收入、合规和信任损失；
- 新方案能减少哪些具体故障；
- 建设成本、持续运行成本和操作复杂度；
- 是否存在产品降级或流程补偿等更低成本方案。
在用户无法感知的范围继续提高可用性，会挤占其他产品与工程投入。SLO 提供停止过度建设的边界。
6. 优化先减少无效工作
常见优化顺序是：
- 删除闲置、重复和无人负责的资源；
- 修复无界重试、轮询、日志和数据保留；
- 调整实例规格、资源请求和自动扩缩容；
- 优化查询、缓存、批处理和数据布局；
- 评估采购折扣与架构级变更。
先处理无效工作，风险和验证成本通常最低。直接迁移数据库或重写服务，可能节省单价，却增加研发、迁移和可靠性成本。
7. 为优化设置护栏
每项优化都要同时观察成本、性能和可靠性。例如降低副本数可以立刻省钱，也会减少故障余量；提高缓存 TTL 可以减轻数据库压力，也会增加数据陈旧时间。
可以为实验写出：
- 目标单位成本；
- 不得退化的 SLO 与业务指标；
- 灰度范围和观察周期；
- 预期节省、实现成本和回收周期；
- 回滚触发条件。
节省金额要扣除迁移、平台和人力维护成本。一次性账单下降不代表长期单位经济性改善。
8. 用差异定位责任
月度或版本复盘可以把成本变化拆成：
总成本变化 = 业务量变化 + 单位成本变化 + 采购价格变化 + 共享分摊变化
业务增长造成的合理支出与效率退化要分开。单位成本上升后，再沿服务、租户、地域、资源类型和版本定位驱动因素。
归因用于找到可以行动的所有者，不用于把共享平台账单机械转嫁给团队。平台团队也要对自身固定成本、利用率和服务质量负责。
9. 面试题
9.1 怎样判断一次性能优化是否值得投入
出现公司：阿里巴巴
考察重点
- 业务单位、基线和资源成本归因。
- 尾延迟、安全吞吐与 SLO 护栏。
- 实现成本、持续成本和业务收益比较。
相关内容：第 1 节“先选择业务单位”至第 8 节“用差异定位责任”。
参考回答
我会先把目标落到业务单位，例如每笔成功订单成本，并记录同一负载下的吞吐、错误率、P95/P99、资源用量和当前 SLO。云资源通过服务、团队、环境和租户标签归属，共享资源再按请求、CPU 时间、存储或消息量等可解释驱动因素分摊。
方案比较同时计算用户收益、预计节省、研发迁移成本、持续运维成本和回收周期，并为灰度设置 SLO、业务正确性和容量余量护栏。优化后把总成本变化拆成业务量、单位成本、价格和分摊变化，确认改善来自效率，而不是流量下降或风险转移。如果用户收益和错误预算不支持更高目标，我不会为了技术指标继续增加复杂度。