9.4 成本、可持续性与绿色软件

概述与动机

软件运行在会消耗资金、电力、水和材料的物理基础设施之上。在计算机发展史的大部分时间里，这些成本都是别人的问题：资本预算把硬件藏了起来，能源对工程师来说也是看不见的。云计算改变了这一点。它让消耗变得细粒度化、按需化、可直接归因，从而把成本、乃至越来越多的碳排放，变成了工程层面的关切。本章涵盖两个相互交织的学科：FinOps，即为可变的云支出引入财务问责的实践；以及绿色软件，即构建用更少能源和更低碳排放完成同样工作的系统的实践。这两者有很大重叠，因为高效的软件通常既更便宜，又更清洁。

对大型团队而言，这些数字十分巨大。一家大型企业的云账单每年可能达到数千万甚至数亿，而几个百分点的浪费就代表着本可以用来支持人力或产品的真金白银。大型数字资产的碳足迹同样是实质性的，组织正面临来自监管机构、投资者、客户以及自身员工不断增长的压力，要求他们去衡量并减少碳足迹。当数百个团队各自独立地就实例规模、数据保留和架构做出决策时，微小的低效会累积成巨大的成本和排放。使成本和碳排放变得可见、可问责的治理机制，对于控制两者都至关重要。

企业和政府场景与此直接相关。公共部门组织花费的是纳税人的钱，并且越来越受到可持续性授权和净零承诺的约束，因此展示高效、低碳的运营方式既是一项财政义务，也是一项政策义务。企业则面临投资者对环境绩效的审视，以及利润率方面的竞争压力。在这两种场景下，成本和可持续性都已从事后考虑事项，上升为董事会层面关注的问题。工程层面的选择，正是这些关切最终得以实现或落空的地方。

关键原则

让消耗变得可见。 你无法优化你看不到的东西；成本和碳排放必须归因到造成它们的团队和服务。
问责应落在所有者身上。 配置资源的工程师应当能看到、并对自己造成的成本和碳影响负责。
效率同时服务于成本和碳排放。 用更少的资源完成同样的工作，通常能同时节省资金和减少排放。
持续地合理调整规模。 需求会变化，因此资源配置必须被重新审视，而不是设定一次就置之不理。
碳排放有时间和地点之分。 同样的计算，排放量会因发电的时间和地点不同而有多有少。
权衡好三者关系。 成本、性能和可靠性彼此制约；要有意识地优化，而不是盲目地优化。
尽早为效率而设计。 架构层面的选择，对长期成本和碳排放的影响，远大于后期的调优。

建议

建立 FinOps 的可见性、优化机制与问责制

FinOps 分三个迭代阶段推进。知情（Inform）： 通过标签、分摊和仪表盘建立可见性，使每一笔成本都归因到一个团队、一项服务和一个业务目的，共享成本也被公平地分摊。优化（Optimize）： 消除浪费（闲置和孤立的资源），对过度配置的服务进行合理缩减，为稳定的基础负载采用基于承诺的折扣（如预留实例或节省计划），并为可中断的工作使用竞价型或可抢占容量。运营（Operate）： 通过预算、异常告警、预测和定期评审，把成本管理嵌入日常工程实践之中。最重要的是，要把成本数据摆在制造这些成本的工程师面前。要让效率成为工程、财务和产品部门共同的目标，而不仅仅是财务部门的关切。

构建具有碳意识、节能高效的软件

减少碳排放有三个杠杆。能源效率： 通过更好的算法、缓存，以及避免不必要的计算，编写和配置软件，使其用更少的 CPU 周期、更少的内存和更少的数据移动来完成同样的工作。硬件效率： 通过提高利用率、整合资源以及使用现代高效硬件，充分利用资源，因为闲置容量仍然会耗电，也承载着制造过程中产生的碳排放。碳意识： 在时间和空间上转移灵活的工作负载，使其在电网更清洁的时候、在电网更清洁的地方运行，例如在可再生能源发电量高时运行批处理任务，或者在低碳电力的地区运行。使用诸如 Software Carbon Intensity 规范之类公认的方法来进行度量。优先选择在可再生能源方面有坚定承诺、并进行透明报告的供应商和地区。

设计可持续的架构并合理调整规模

架构决定了成本和碳排放的下限。优先选择能够根据实际需求弹性伸缩、闲置时能够缩容至零的设计，这样你就永远不必为闲置未用的容量付费。无服务器计算和自动扩缩容能减少突发性工作负载造成的浪费，托管服务则可以通过多租户提高利用率。根据真实使用情况合理调整计算、存储和数据库的规模，而不是出于担忧而过度配置。设定数据生命周期策略，使冷数据迁移到更便宜、能耗更低的层级，或被删除。减少数据量和网络传输，既能降低存储成本，也能减少数据移动所消耗的能源。要把效率当作一项设计要求，与性能和可靠性一起被纳入评审范围。

有意识地权衡成本、性能和可靠性

成本、性能和可靠性构成了一个三元组。如果你在某一项上用力过猛，通常会对其他两项造成负担：更多的冗余和更低的延迟意味着更高的成本，往往也意味着更多的能源消耗。要让这些权衡变得明确，并把它们与业务价值联系起来。使用 SLO（服务水平目标）来定义一项服务实际需要多少可靠性和性能，然后按这个目标来配置资源，而不是对一切都统一地做到极致。非关键的、内部使用的工作负载可以接受更便宜、冗余更少、碳排放上更灵活的配置。把高端配置留给那些真正值得的场景。

治理而不扼杀

提供护栏，而不是关卡。中央平台团队可以提供高效的默认配置、强制执行的标签规范、预算告警和自助式仪表盘，同时把日常决策留给拥有相应工作负载的团队。为成本效率和减碳设定组织范围内的目标，透明地报告进展，并为节省下来的成果予以表彰。避免繁重的审批官僚体系，因为那会拖慢交付。目标是让高效的选择成为轻松的默认选项。

权衡：优点与缺点

决策	优点	缺点
承诺型折扣	在基础负载上带来可观的节省	存在锁定风险，需求变化时有风险
竞价型/可抢占容量	计算成本最低，利用了电网的闲置容量	会中断，增加了复杂性
激进的规模调整	降低成本和碳排放	在流量高峰时存在配置不足的风险
碳感知调度	降低排放	任务被延迟，需要额外的工程投入
多区域冗余	更高的可靠性	更高的成本、能耗和碳排放

这里统一的权衡是：最高的可靠性和性能很少能与最低的成本和碳排放同时兼得。冗余、始终在线、低延迟的系统既昂贵又耗能，因此对不需要这种水准的工作负载进行统一的“镀金式”配置，会同时浪费金钱和排放。这里的纪律在于：使用 SLO 把雄心与业务价值相匹配，把高端资源只花在真正重要的地方。承诺型折扣和竞价型容量能带来切实的节省，但也引入了你必须管理的锁定风险和中断风险。碳感知调度能节省排放，但只适合能够容忍延迟或迁移的工作负载。

与团队讨论的问题

你们今天的云支出中，实际被打上标签并归因到某个团队的比例是多少？ FinOps 的知情阶段是基础：你无法优化你看不到的东西，未打标签、未分摊的支出意味着没有人对浪费负责。请把真实的覆盖率数字，而不是一个愿景性的数字，带到讨论现场，并附上最大的几项未打标签的支出。对于一个有数百个团队各自独立进行资源配置的大型组织而言，一个较低的归因率意味着共享的低效正在无形中累积成数百万的损失。在政府和企业场景中，归因也是你为纳税人或股东的支出进行辩护、以及为共享平台分摊公平份额成本的方式。这个答案决定了你的第一步行动：如果覆盖率很低，那么在进行任何规模调整之前，都应先做标签强制执行和成本分摊，因为没有可见性的优化只是在猜测。
你们的基础负载中有多少被承诺型折扣覆盖，如果需求发生变化，这些承诺会怎么样？ 预留实例和节省计划能为稳定的基础负载带来可观的节省，但也引入了锁定风险，因此过于激进地购买，会在某个产品下线或迁移时，把一项折扣变成一项负债。请带来具体数字：你的承诺覆盖率百分比、你的基础负载趋势，以及未来一年最可能改变形态的工作负载。这里的纪律是只承诺你确信会持续存在的那部分底线，用按需或竞价容量覆盖可变的那一层，并随着需求演变而重新审视。对于一家大型企业而言，这是一项类似资金管理的决策，具有真实的财务风险敞口，因此财务和工程部门应当共同拥有这项决策，而不是由任何一方单独决定。答案应当把你稳定的基础负载与不确定的需求区分开来，并按前者的规模来确定承诺量。
你们的机群中有多少处于闲置状态，你们统计的是制造环节所固化的碳排放，还是只统计运行时燃烧的能源？ 闲置容量仍然会耗电，并且承载着制造这些硬件时已经付出的碳排放，因此只关注运行时能耗、却对过度配置视而不见，会遗漏碳足迹中真实存在的一部分。请带来利用率数据：平均值和峰值、已配置和实际使用之间的差距，以及哪里可以实现缩容至零或资源整合。更高的利用率能同时服务于成本和碳排放，这正是贯穿本章的主线，因此闲置浪费是你最容易拿到的一项收益。对于受净零承诺约束的组织而言，一个包含固化排放在内的诚实碳排放度量方式，正是真正的进步与招致监管和声誉反噬的“漂绿”之间的分界线。答案应当把你利用率最低的工作负载列为整合、自动扩缩容或缩容至零的目标，并设定一种不会悄悄忽视制造环节碳排放的度量方法。
你们的工程师能看到自己所负责服务的成本和碳排放吗？有没有人根据看到的数据采取行动？ 可见性只有在它触达那些配置资源的人、并改变他们的行为时才有价值，因此一个财务部门每月查看、工程师却从不打开的仪表盘，只是一种摆设，而不是问责机制。这里存在真实的拉扯：平台团队想要中央控制和整洁的报告，而交付团队则反感任何让人感觉像监视、或者又多了一道交付关卡的东西。请带来证据，说明究竟是谁在查看成本和碳排放数据、多久查看一次，以及上个季度是否有任何规模调整或清理工作因此而发生。对于一个有数百个团队各自独立进行资源配置的大型组织而言，一个被工程师真正拥有的信号，与一份被忽视的报告之间的差别，正是持续累积的节省与持续累积的浪费之间的差别。在企业和政府场景中，要把单位经济指标（每次请求、每个客户或每个案例的成本和碳排放）摆在拥有该服务的团队面前，因为一个汇总数字能够为预算辩护，但一个单位数字才能改变一项设计决策。
你们哪些工作负载在时间或地区上真正具有灵活性，要把它们调度到电网更清洁的地方需要付出什么？ 碳感知调度把灵活的工作转移到电力低碳的时间和地点，但它只适合那些能够容忍延迟或迁移的任务，因此第一项工作是把真正可延后的批处理工作，与任何面向用户或对延迟敏感的工作区分开来。这里的权衡是：跨地区调度任务，或把任务挪到非高峰时段，会增加工程投入、数据传输成本，有时还会带来可能超过所节省排放量的数据驻留风险。请带来一份候选的批处理和分析任务清单，包括它们对延迟的容忍度、它们的数据驻留约束，以及你在法律上能够运行它们的那些地区的碳强度。对企业而言，这是在规模调整基础之上的一项适度优化，因此应把它排在成本基本功之后，而不是之前。在政府场景中，数据驻留和主权规则可能会禁止跨境移动公民数据，无论电网是否清洁，因此地区选择首先是一个法律问题，其次才是一个碳排放问题。
你们设定了哪些效率和可持续性目标，这些目标的写法是否能确保达成它们不会悄悄破坏可靠性？ 目标能够聚焦精力，但一个粗糙的成本或碳排放目标会诱发错误的行为：团队可能会配置不足、削减冗余，或以牺牲大规模事故为代价换取微小的节省来延后工作。这里的张力在于：一个领导层可以对外汇报的雄心勃勃的自上而下数字，与一个基于每项服务真实 SLO 的自下而上目标之间，需要相互协调，而不是单方面强加。请带来你目前的目标、这些目标所对照的基线，以及能够阻止优化悄悄侵蚀服务真实所需水平的可靠性护栏。对于一个大型组织而言，汇总目标必须公平地分解到工作负载各不相同的团队，因此一个面向客户的支付服务和一个内部报表任务，不应背负相同的效率期望。在成本和可持续性数字会出现在公开披露文件中的企业和政府场景下，要把每一个上报的数字与一种经得起审计的度量方法绑定，因为一个在审视下站不住脚的目标是一项负债，而不是一项成就。

行业视角

初创企业。 成本就是你的资金跑道，因此花一个下午打标签、设置一个预算告警，就能为你争取到下一轮融资前多一个月的时间。完全跳过 FinOps 流程和碳核算；只需盯紧账单、清理闲置资源，并选择一个能够缩容至零的托管平台，让你只为实际负载付费，而不是为待命的容量付费。你最稀缺的资源是工程注意力，因此把明显的浪费自动化处理掉，然后继续前进。

小型企业。 你没有 FinOps 专家，预算也很紧张，因此应依靠云服务商已经提供给你的成本工具，而不是购买一个专门的平台。设置一个月度预算告警，开启服务商提供的规模调整建议功能，并优先选择那些把运营效率折算进价格中的托管服务和无服务器服务。把可持续性当作选择一个低碳地区和一个高效的默认配置，而不是当作一个你需要专门配人手去运营的报告项目。

企业。 这里的问题是跨众多团队的治理：一致的标签规范、共享平台成本的公平分摊、由财务和工程共同拥有的承诺型折扣策略，以及让每个团队都能看到的成本和碳排放信号。要把高效的默认配置和一种度量方法标准化，使数百个独立的资源配置决策不会累积成浪费，并把云支出和排放当作一个投资组合来管理，配以目标、异常告警和透明报告，而不是散乱的局部优化。

政府。 采购规则、透明度和公共问责制塑造着每一个选择。你花的是纳税人的钱，通常还受到净零承诺的约束，因此你必须同时展示财政上的审慎和经过审计的减排进展，这意味着需要一种包含固化硬件碳排放的诚实碳排放度量方式，而不是漂绿。数据驻留和主权规则可能会限制你能使用哪些地区，无论电网是否清洁，效率和排放指标也可能需要公开供公众审视，因此要选择你能在审计中站得住脚的度量方法。

示例

初创企业。 一家种子期初创企业发现自己的云账单在两个月内翻了一番，却说不清楚原因。一位创始人花了一个下午的时间，按功能为每一项资源打上标签，并开启了一个简单的预算告警。这些标签揭示出一个被遗忘的预发布集群，以及一个为夜间任务而全天候运行的过大数据库。关闭这个集群、把该任务改为在非高峰时段用一个更小的实例定时运行，把账单削减了三分之一，为团队多争取到了一个月的资金跑道。

企业。 一家拥有庞大、分散云资产的跨国零售商建立起了一套 FinOps 实践。它强制执行标签规范，把每一笔成本分摊到某个产品团队，并把支出情况展示在工程师每天都会查看的仪表盘上。一年之内，它清除了闲置资源，对过度配置的服务进行了规模调整，并为稳定的基础负载购买了节省计划，把云支出削减了大约四分之一。随后，它把夜间的分析批处理任务调度到碳排放更低的地区和非高峰时段运行，同时降低了成本和排放，并在其年度可持续性披露文件中报告了这些碳排放节省。

政府。 一个在国家净零承诺下运营公民服务的政府机构，必须同时展示对纳税人资金的财政审慎，以及在排放目标上的进展。它对工作负载进行了规模调整和整合，设定了数据保留策略，把很少被访问的记录迁移到低能耗的冷存储层，并选择由高比例可再生电力供电的云地区。它度量其主要服务的碳强度，并公开效率和排放指标以接受公众问责。高效的默认配置和自助式仪表盘让数十个交付团队能够做出可持续的选择，而不必经过中央瓶颈。

商业案例：动机、投资回报率与总体拥有成本

这里的回报异常直接。经过有纪律的努力，FinOps 优化通常能把云支出降低五分之一到三分之一，这笔节省直接流入利润底线，或者可以用来资助新的工作。碳排放的减少也越来越具有财务价值，体现在避免的碳定价成本、获得具有可持续性要求的合同资格，以及降低的监管和声誉风险上。由于提高效率能同时降低成本和碳排放，一项对可见性和规模调整的投资，能在两个维度上都得到回报。

总体拥有成本必须计入采纳的成本：用于成本和碳排放可见性的工具、运行这项实践所需的 FinOps 或平台人员，以及用于规模调整和重新架构的工程时间。相对于所节省的成本，这些投入是适度的，而且随着高效默认配置被嵌入进来，它们还会进一步缩小。不采纳所带来的代价则在无声中累积：增速超过业务本身的失控云账单、因无人负责而永远不会浮现的浪费，以及在可持续性方面不断加重的监管、投资者和声誉风险敞口。要向领导层论证这一点，应展示当前支出及其增长轨迹、估算的浪费程度，以及采纳 FinOps 后可参照的节省基准，然后把它与减排和合规价值结合起来。要把成本和可持续性描述为同一项效率倡议的两个视角，这样企业就不必在省钱和减碳之间做选择。

反模式与陷阱

没有成本归因。 未打标签、未分摊的支出意味着没有人对浪费负责，也没有人能对其进行优化。
一次配置，永不过问。 只对资源进行一次规模设定、之后再也不重新审视，必然会导致漂移到过度配置的状态。
只属于财务部门的 FinOps。 把成本当作一个后台部门的事情，而不是一个工程信号，注定会失败，因为正是工程师在做出驱动支出的决策。
漂绿。 在没有度量的情况下宣称可持续性，会招致监管和声誉方面的反噬。
以牺牲可靠性为代价换取效率。 削减得过于激进，导致服务在负载下出现故障，用微小的节省换来了一场大事故。
忽视固化碳排放。 只关注运行时能耗，却对过度配置的闲置硬件视而不见，遗漏了制造环节的碳足迹。
官僚式的审批关卡。 繁重的支出审批流程拖慢交付，并促使团队绕开治理机制。

成熟度模型

第 1 级，启动（Initiate）。 云成本是月度账单上的一个意外。没有标签、没有分摊、也没有碳排放意识，资源配置宽松且很少被重新审视。浪费是不可见的，因为没有人对它负责，任何发生的清理工作都是对账单冲击的一种被动反应，而不是一种常规实践。

第 2 级，发展（Develop）。 基本的成本可见性和标签机制已经存在，也有一些规模调整和闲置资源清理工作在进行，但覆盖率和严谨程度在各团队之间差异很大。一些团队关注自己的支出并尝试使用低碳地区；另一些团队两者都不做。可持续性被承认，但未被度量，良好习惯依赖于个人的主动性，而不是任何共享的期望。

第 3 级，标准化（Standardize）。 一套 FinOps 实践已被记录并在整个组织范围内应用：标签规范被强制执行，共享成本按一种约定的方法进行分摊，预算、预测和异常告警都是标准做法。承诺型折扣和规模调整遵循一份明确的操作手册，主要服务的碳排放使用诸如 Software Carbon Intensity 规范之类公认的方法进行度量，地区和调度选择被一致地考虑，而不是逐案决定。

第 4 级，管理（Manage）。 成本和碳排放被对照基线进行度量和控制。团队跟踪单位经济指标（每次请求、每个客户或每个案例的成本和碳排放）、包括闲置和固化碳排放估算在内的利用率、承诺覆盖率相对于基础负载的比例，以及预测准确性，所有这些都对照组织目标进行报告。异常会触发调查，效率和 SLO 达成情况被放在一起审查，以确保优化不会悄悄侵蚀可靠性，资源配置的是否批准决策也是基于这些数据而不是直觉来做出的。

第 5 级，编排（Orchestrate）。 成本和碳排放是持续存在、有明确归属的工程信号，被嵌入日常实践之中。高效的默认配置、自动化的规模调整和碳感知调度都是常态，组织会随着需求、价格和电网碳强度的变化而持续重新平衡其资产。成本、性能和可靠性通过 SLO 被有意识地权衡，可持续性指标以经得起审计的方法输入到公开和投资者报告之中，这套实践也随着业务、市场和监管的演变而不断调整。

讨论思路

在你的组织中，谁应当拥有云成本：财务部门、一个中央 FinOps 团队，还是配置资源的工程团队？
你如何在众多消费团队之间公平地分摊共享平台的成本？
在成本节省与你为此可能牺牲的可靠性或性能之间，正确的平衡点在哪里？
你会如何度量你的服务的碳足迹？你对现有数据的可信度如何？
你的哪些工作负载在时间或地区上有足够的灵活性，可以进行碳感知调度？
你如何设定既能激励团队、又不会诱使他们做出危险的资源配置不足行为的效率和可持续性目标？

关键要点

云计算把成本和碳排放变成了工程层面的关切；可见性和责任归属是控制两者的基础。
FinOps 分三个阶段运作：知情（可见性）、优化（规模调整与折扣）和运营（嵌入日常实践）。
高效的软件通常能同时节省资金和碳排放，因此应把它们当作一项倡议的两个视角来对待。
通过能源效率、更高的硬件利用率，以及在时间和地点上的碳感知调度来减少碳排放。
架构和规模调整主导着长期的成本和碳排放；要为弹性和缩容至零而设计。
使用 SLO 有意识地权衡成本、性能和可靠性，用护栏而不是关卡来进行治理。

参考文献与延伸阅读

J.R. Storment, Mike Fuller, Cloud FinOps: Collaborative, Real-Time Cloud Financial Management
FinOps Foundation, FinOps Framework documentation
Green Software Foundation, Principles of Green Software Engineering and Software Carbon Intensity (SCI) Specification
Anne Currie, Sarah Hsu, Sara Bergman, Building Green Software
Adrian Cockcroft, writings on cloud efficiency and sustainability
The Shift Project, Lean ICT: Towards Digital Sobriety