5.4 工程的成本与单位经济学

概述与动机

本主题把第5部分明确转向财务：如何用一位财务利益相关方能够直接使用的说法来表达工程成本，以及如何建立单位经济学，按每一个有意义的产出或使用单位表达成本，而不是把它当作一条不透明的、汇总的部门预算条目。工程成本通常是一个软件驱动型组织中最大的可控支出项，然而它却常常是财务职能最不理解的一项，被报告为一个单一的大数字，几乎看不出是什么在驱动它，或它随增长如何扩展。本主题的存在，正是为了弥合这个缺口，因为一位无法用具体财务说法回答”运行这个系统需要花我们多少钱”或”我们的成本随我们的增长如何扩展”的工程领导，在每一场预算对话中都处于真正的劣势。

本主题所建议的具体纪律，单位经济学，意味着按每次部署、每个被服务的客户、每笔被处理的交易，或另一个对业务而言真正重要的单位来表达成本，而不只是作为总人力成本或总云支出。这种重新构建，直接连接到主题 1.3 的结果优先于产出原则：一个下降的总成本数字，如果它来自服务了更少的客户，并不自动就是好事；一个上升的总成本数字，如果它来自按比例服务了更多的客户，也并不自动就是坏事。单位经济学正是让成本趋势变得可解读、而不只是可见的东西。

对大团队而言，本主题的纪律把工程财务从一个黑箱变成一个清晰、可管理的系统。企业组织用单位经济学来在公平的基础上比较不同产品、平台或团队的成本效率；政府组织用同样的纪律来证明财政责任，并为随时间推移降低每位公民服务成本的基础设施投资建立基于证据的论证。

核心原则

单独的总成本，如果没有一个分母，是无法解读的。 单位经济学，也就是每个有意义单位的成本，把一个不透明的数字变成一个可操作的趋势。
选择一个反映真实业务或使命价值的单位， 而不是一个任意的或容易被操纵的分母。
成本有多个组成部分：人力、基础设施和工具。 分别跟踪它们，因为每一项都有不同的成本驱动因素和不同的可拉动杠杆。
FinOps实践把本书应用于交付和质量指标的同等严谨性，带到了云成本上。 把成本当作可测量、可管理的东西，而不是一个不可避免的、不透明的既定事实。
总成本下降并不自动是好事，总成本上升也并不自动是坏事， 除非同时检查单位度量发生了什么。

建议

选择一个反映真正交付价值的单位，而不是一个任意的分母

为你的单位经济学计算选择一个真正跟踪业务或使命价值的单位：每位被服务客户的成本、每笔被处理交易的成本、每次部署的成本，或对一项公共部门服务而言，每次被处理的公民互动的成本。避免使用一个太容易被虚增以美化这个比率的分母，例如一个内部的、很大程度上可自主决定的计数，它并不对应任何真正的、外部的交付价值单位。

把人力、基础设施和工具成本分开

工程成本至少有三个具有不同驱动因素和不同杠杆的独立组成部分：人力成本（薪资、福利，短期内很大程度上是固定的）、基础设施成本（云支出，很大程度上随使用量而变动，可以通过工程实践直接优化），以及工具和许可成本（通常是按席位或按使用层级的固定成本）。分别跟踪这些成本，而不是作为一个混合总数，因为由基础设施随真实增长而扩展所驱动的总成本上升，与由未受管理的工具泛滥所驱动的同样的总成本上升，需要非常不同的应对。

专门对云基础设施成本应用FinOps纪律

FinOps是通过工程、财务和业务团队之间的跨职能协作，为可变的云支出带来财务问责的纪律。直接应用它的核心实践：按团队和服务标记云资源以进行成本归因，按固定节奏对照预算审阅支出，并把基础设施成本效率（每个实际使用单位的成本）当作一项值得刻意优化的工程指标，而不是一项只能被动接受的、不可避免的固定开销。

随时间跟踪单位成本趋势，并明确调查其变动

单一的单位成本快照，其用处不如它的趋势：每位被服务客户的成本，是随着平台成熟和扩展而下降（真正效率提升的迹象），还是在上升（累积的低效率、技术债务驱动更高维护成本，或被服务客户构成转向更消耗资源的细分市场的迹象）。明确调查一次显著的单位成本趋势变化，而不是不加解释地报告这个数字。

把成本数据与本书其他地方的技术债务和质量指标连接起来

每单位不断上升的基础设施或维护成本，有时是累积的技术债务（主题 4.5）或复杂度热点扩散（主题 4.1、主题 4.3）的一个直接、可测量的后果：低效的代码路径、冗余的基础设施，以及优化不佳的查询，最终都会以升高的单位成本形式显现出来。把上升的单位成本，与第4部分的变动量和复杂度信号一起，作为你债务优先排序讨论的一项输入，因为一项拥有已证明、可测量成本影响的债务条目，比一句未经量化的质量抱怨，为补救投资提出了更有力的论证。

权衡取舍：利与弊

方案	优点	缺点
只报告总成本	简单，符合预算通常被分配的方式	没有分母就无法解读；掩盖了效率趋势
用一个精心选择的分母做单位经济学	可解读，具可操作性，可跨时间和团队比较	需要谨慎选择一个真正有意义、难以操纵的单位
混合成本报告（人力、基础设施、工具合并）	简单的单一数字	掩盖了具体是哪个成本驱动因素在真正变化，以及为什么
分开的成本组成部分	揭示出针对一个给定成本趋势应当拉动的正确杠杆	需要更详细的成本归因和跟踪基础设施

核心张力是简单性与可操作性之间的张力。一个单一的总成本数字容易报告，也符合许多组织已经分配预算的方式，但它同时掩盖了是什么在驱动成本变化，以及这些变化反映的是真正的效率还是真正的增长。解决这种张力的办法，是投资于本主题所建议的、略微更复杂的单位经济学和组成部分分离报告，因为由此产生的可操作性，也就是准确知道当成本变动时该拉动哪个杠杆，对任何超过最小规模的组织来说，都值得这份适度的额外跟踪努力。

与团队讨论的问题

我们是按每个有意义单位（客户、交易、部署）跟踪工程成本，还是只作为一个不透明的总数？ 如果只存在一个总数，识别出什么单位能让你的成本趋势真正可解读，讨论开始跟踪它需要什么条件。
我们能否把当前的成本拆分成人力、基础设施和工具组成部分，我们知道任何近期变化是由哪一项驱动的吗？ 拉出你实际的成本细目，如果存在的话，检查它是否详细到足以有信心地回答这个问题。
我们是否已经对我们的云基础设施成本应用了FinOps标记和归因实践，还是它是一个单一的、未被归因的条目？ 如果支出无法被归因到具体的团队或服务，讨论迈向真正归因的第一步会是什么样子。
我们的单位成本趋势最近在任一方向上是否显著变动过，我们知道为什么吗？ 调查一次真实的近期变动，如果存在的话，看看你能否有信心地解释它，还是它依然是一个谜。
我们当前的基础设施成本趋势，是否与我们第4部分中任何技术债务或复杂度热点信号相关联？ 明确地交叉引证这些数据来源，看看是否浮现出一种能够强化债务补救商业理由的联系。
如果明天一位财务利益相关方问”再多服务一位客户要花我们多少钱”，我们能否有信心地回答？ 这个具体、实用的问题检验了你的单位经济学是否真正已经建立并准备就绪，还是仅仅是一个理论上的愿望。

行业视角

初创公司。 在早期，单位经济学极为重要，因为投资者和创始人都需要知道，服务每一位额外客户的成本，是在趋向可持续，还是趋向一种无法扩展的商业模式。从很早的阶段就跟踪这一点，哪怕只是粗略的估算，而不要等到公司大到足以支撑正式的FinOps工具。

小型企业。 云服务提供商的账单仪表盘通常在不需要专门FinOps工具的情况下，提供了足够的基本成本可见性；主要的纪律，是选择一个合理的单位（每位客户的成本，或每笔交易的成本），定期检查趋势，而不是只孤立地看总账单。

企业。 在这个规模上，FinOps实践和分开的成本组成部分跟踪至关重要，因为云支出可能代表一条非常庞大、常常审查不足、分散在许多团队之间的预算条目。投资于恰当的成本归因标记和一个专门的成本审阅节奏，并用单位经济学来公平地比较不同产品线或平台之间的成本效率。

政府。 财政责任和可证明的成本效率，与预算论证和公共问责直接相关。以每位被服务公民的成本，或每笔被处理交易的成本表达的单位经济学，对预算委员会而言，往往比一个原始的总支出数字远更有说服力、也更可解读，并直接支持了随时间降低每单位成本的基础设施投资的商业理由。

案例

企业。 一家软件即服务公司的财务团队，连续几个季度都对不断上升的云基础设施总支出感到警觉，最初假定存在低效率或浪费。一次单位经济学分析，每位活跃客户的成本，显示单位成本实际上一直在稳步下降，即使总支出在上升，因为客户数量的增长速度超过了基础设施成本，这是一次真正的效率改善，却被单看总支出所掩盖了。这种重新构建，把财务对话从”为什么工程支出更多了”转变为”我们如何维持这种高效的扩展”，这是一场更有成效得多的讨论，避免了一项不必要、可能有害的削减成本要求，那本会针对真正健康、由增长驱动的支出。

政府。 一家州政府的数字服务机构，被要求向一个预算委员会论证继续投资云基础设施的正当性，该委员会正把成本与它正在取代的遗留本地系统进行比较。一次单位经济学分析，每笔被处理公民交易的成本，显示新的基于云的系统，尽管名义总支出更高，其单位成本却大幅低于遗留系统曾经的水平，因为新系统用同等或更低的总基础设施预算，处理了远更高的交易量。这种单位成本比较，而不是一个更难解读的总支出比较，成为了一场成功论证中的核心证据，支持了继续并扩大云投资。

商业理由：动机、投资回报与总拥有成本

严谨的单位经济学的回报，是对每一位财务利益相关方最终都会问的那个问题给出一个站得住脚、可解读的答案：这项支出是否高效，它是否在可持续地扩展。上面的企业案例展示了把这件事做错的风险：一种只看总支出的视角，差一点触发了一项不必要、适得其反的削减成本要求，针对的是那些按单位计算正变得更高效、而不是更低效的支出。

总拥有成本包括成本归因工具（FinOps标记实践），以及分开成本组成部分、随时间跟踪单位趋势所需的分析纪律。相比单靠一种信息不足的总成本视角，做出一项重大预算决策的风险，削减了实际上高效的支出，或未能捕捉到正在真正变得低效的支出，这份投入是适度的。

反模式与陷阱

报告没有分母的总成本： 无法解读，也掩盖了成本是在高效地还是低效地扩展。
为成本计算选择一个容易被操纵或任意的单位： 产生一个讨好人、而不是提供信息的比率。
把人力、基础设施和工具成本混合成一个数字： 掩盖了具体是哪个驱动因素在真正变化，以及什么杠杆能解决它。
没有云成本归因（FinOps标记）： 让基础设施支出在团队或服务层面实际上不受管理、不受问责。
在不检查单位趋势的情况下对总成本变化做出反应： 可能触发一项针对真正高效、由增长驱动的支出的不必要削减成本要求。
从不把成本趋势与技术债务或复杂度数据连接起来： 错过了一个为债务补救投资量化、强化的论证。

成熟度模型

第一级，启动： 工程成本只被报告为一个不透明的总数，没有单位经济学或组成部分分离。
第二级，发展： 存在一些成本细目，但单位经济学不一致，云成本归因也大体缺失。
第三级，标准化： 用一个精心选择的分母做出的单位经济学被一贯地跟踪，成本在全组织范围内被分成人力、基础设施和工具组成部分。
第四级，管理： FinOps归因和审阅实践已经建立，单位成本趋势被主动调查，并与技术债务和质量信号连接起来。
第五级，协奏： 组织能够有信心地回答来自财务利益相关方的详细单位成本问题，成本数据在最高层级直接为工程投资决策和预算论证提供依据。

讨论思路

什么单位能让我们的成本趋势真正可解读，我们跟踪它吗？
我们能否把一次近期的成本变化拆分成它的人力、基础设施和工具组成部分？
我们目前基础设施支出中，是否有任何部分未被归因到一个具体的团队或服务？
我们的单位成本趋势最近变动过吗，我们知道为什么吗？
上升的单位成本，可能在哪里是未被解决的技术债务的一种症状？

要点回顾

单位经济学，每个有意义价值单位的成本，把一个不透明的总成本数字变成一个可解读、可操作的趋势。
选择一个反映真实业务或使命价值的单位，避免一个容易被操纵或任意的分母。
把成本分成人力、基础设施和工具组成部分，因为每一项都有不同的驱动因素和不同的杠杆。
专门对云基础设施成本应用FinOps纪律，包括归因标记和定期审阅。
除非同时检查单位趋势，否则总成本下降并不自动是好事，总成本上升也并不自动是坏事。

参考文献与延伸阅读

Cloud FinOps，J.R. Storment、Mike Fuller著（关于云成本管理FinOps实践的奠基性著作）。
Accelerate: The Science of Lean Software and DevOps，Nicole Forsgren、Jez Humble、Gene Kim著（交付效率与成本之间的关系）。
Site Reliability Engineering，Betsy Beyer、Chris Jones、Jennifer Petoff、Niall Richard Murphy编（把成本当作一项明确的可靠性工程权衡）。
FinOps基金会的FinOps框架，finops.org（云财务管理的从业者指导和成熟度模型）。