主题 6.5 — 技术成本管理与云 FinOps

在卫生与照护中，技术的运营成本是无论是否有人在看都每小时都在花费的公共资金，因此管理这项成本——尤其是在云端——是一门管理纪律，而不是一年一度的财务演习。

为什么这在卫生与照护中至关重要#

在 NHS 技术的大部分历史中，钱是一次性花掉的。你购买一台服务器、一个存储阵列或一份许可证，将其资本化，然后它在机架上静静地折旧五年。成本是可见的、有边界的，且在很大程度上是固定的。云计算打破了这个模式。现在计量表持续运转，账单每天都在变化，工程师们做出的成千上万个小决定都在动用真实的钱，发票在花费已经完成一个月后才到达。一项在银行假日周末被遗忘运行的错误配置作业、一个没有人关掉的测试环境、一个悄悄增长的存储桶——每一个都是实时流失的公共资金。

这在卫生与照护中之所以重要，除了普通的节俭之外还有三个原因。首先，这是以信托方式持有的公共资金：花在闲置计算能力或重复软件许可证上的每一英镑，都是没有花在照护上的一英镑，你要向审计人员、你的董事会，最终向公众负责（参见主题 6.4——治理与保证）。其次，这笔钱遵循着特殊的规则。NHS 预算在资本和营运支出之间严格分开，从购买资产转向租用服务悄悄地把一种转换成了另一种——一个具有预算后果的技术决策，能让一位财务总监措手不及。第三，未受管理的成本是一种变相的安全和连续性风险：害怕意外账单的团队会削减韧性配置、推迟补丁，或负担不起运行一个安全服务所需的环境。

这种失败模式是独特且常见的。机构迁移到云端时期望节省成本，庆祝迁移成功，然后十八个月后发现账单比它所取代的数据中心还要大——却没有人能说出为什么。问题很少出在技术上。而是没有人把运营成本当作一门实时纪律来拥有：工程师为交付速度优化，财务看到一张不透明的单一发票，一个设计决策与其成本之间的反馈循环从未闭合。本主题讲的就是如何闭合这个循环。

核心概念#

云计算（Cloud computing）以一种按需、计量的服务的形式提供计算资源——服务器、存储、数据库、网络——而不是作为自有设备。它的决定性商业特征是弹性：你可以在几分钟内获取和释放产能，只为你消耗的部分付费。正是同样的弹性，使得成本管理变得困难。云和遗留系统的技术架构在主题 4.0有所涵盖（参见主题 4.0——技术架构、云与遗留系统）；本主题负责的是那个架构运行之后成本发生的事情。

核心的会计转变，是从资本支出（Capital expenditure）（capex）——为获取一项固定资产而花费的钱，然后在数年内折旧——转向营运支出（Operating expense）（opex），即运行一项服务的持续成本。购买一台服务器是资本支出；租用等量的云端产能是营运支出。在 NHS 中，这不是一个中立的记账细节：资本和营运支出被分别拨款、分别控制，且很少能相互替代，因此将支出从资本转向营运支出，可能会缓解一种压力，同时制造另一种压力。这些选择的前期评估——五案例模型、资本与营运支出的基础知识——属于财务管理和商业论证案的范畴（参见主题 6.0——财务管理与商业论证案）；本主题从商业论证案结束、计量表开始运转的地方接手。

FinOps——"云财务运营（cloud financial operations）"的缩略语——是一门把工程、财务和业务团队聚集在一起、把云成本当作一项共享的、数据驱动的责任来管理的运营纪律。由 FinOps Foundation（Linux Foundation 的一部分）推广，它通常被描述为一个有三个迭代阶段的生命周期：知情（Inform）（通过分配和报告，让每个人都能看到正在花费什么、为什么），优化（Optimize）（依据那种可见性采取行动，消除浪费，更便宜地购买），以及运作（Operate）（把成本意识嵌入日常工作方式和治理之中）。FinOps 刻意不仅仅是削减成本；它的目标是最大化每一英镑云端支出的业务价值，这有时意味着要花更多的钱，因为回报能证明它的合理性。

两种分配机制使成本变得可见。**内部核算（Showback）**向每个团队或服务报告其技术消费的成本，为了透明和行为改变，而不移动资金。转嫁核算（Chargeback）更进一步，真正从消费单位的预算中收回成本——一种把共享服务成本分配给消耗它们的成本中心（Cost centre）的内部成本分配（Cost allocation）形式。两者都依赖于标签化：用元数据（服务、团队、环境、是否面向患者）标注每一份云资源，从而使一张未加区分的发票能够被拆分为有意义的条目。

另外三个概念贯穿本主题。总拥有成本（Total cost of ownership，TCO）是一项技术在其整个生命周期内的全部直接和间接成本——不仅仅是许可证或计算能力，还有围绕它的人员、集成、支持、退出和退役。软件资产管理（Software asset management，SAM）是跟踪和优化一个机构所拥有和租用的软件的纪律，如今日益由软件即服务（Software-as-a-service，SaaS）订阅和悄悄续期的按用户软件许可证（Software license）所主导。而单位经济学将成本表达为相对于机构关心的某个事物的一个比率——每患者、每次预约、每次转诊、每次 API 调用的成本——从而使一张不断上涨的账单能够依据不断上升的价值、而不是在真空中被评判。自动扩缩容（Autoscaling），即产能自动调整以匹配负载，以及更广泛的 ITIL 财务管理实践，与这些一起构成了运营杠杆。

最佳实践#

1. 在你试图削减成本之前先让它可见——先知情。 你无法管理没有人能看到的东西，而默认的云端发票是一个月后才到达的、不透明的单一数字。建立按服务、团队、环境细分的、近乎实时的成本可见性，并在可能的情况下按临床服务细分，从而使做出设计决策的人在几天内、而不是几个季度内就能看到这些决策的成本。仅仅是可见性就能改变行为：能看到自己支出的团队，常常能发现任何中央财务报告都不会捕捉到的浪费。

2. 给一切打上标签，把未标记的支出当作缺陷来对待。 成本分配的好坏取决于其下方的元数据；一份未标记的资源，是你无法归因、质疑或收回的资金。商定一个强制性的标签标准——所有者、服务、环境、成本中心、数据分类——通过自动化政策强制执行，使不合规的资源在创建时被标记或阻止，并把被正确分配的支出比例作为一项头条指标来报告。在卫生环境中，标记一个工作负载是否面向患者或对临床至关重要，也能让你在优化其余部分时保护正确的东西。

3. 有意识地选择内部核算或转嫁核算，并使其与你的问责相匹配。 内部核算温和地建立成本意识，是大多数机构的正确起点；转嫁核算创造了真实的预算后果，但需要成熟的分配能力和捍卫这些数字的政治意愿。决定你想要创造的是什么行为——意识，还是真正的财务所有权——并诚实地承认，用不成熟、有争议的分配数据过早实行转嫁核算，会产生使整个努力失去信誉的争议。无论你选择哪种，目标都是一个闭环，在其中一个团队的决定明显影响它认为是自己的预算。

4. 不懈地消除浪费：调整规模、安排时间表并删除。 在大多数资产中，很大一部分云端支出是纯粹的浪费——过度配置的实例、超大的数据库、孤立的存储，以及为一个朝九晚五团队每天二十四小时运行的非生产环境。将资源规模调整为观察到的负载，而不是猜测的峰值，安排开发和测试环境在夜间和周末自动关闭，为存储和快照设置一个生命周期，使其不会永远累积。这是可用的最快、风险最低的节省，一旦自动化，每个月都会重复出现。

5. 为你可预测的基线购买承诺产能。 云提供商为换取一年或三年的承诺——通过预留实例、节省计划或承诺使用协议——通常会提供大幅折扣，而一项卫生服务的稳定基线（核心电子病历、始终在线的集成引擎）正是这些工具所奖励的那种可预测负载。分析你稳定的使用情况，承诺投入以获取折扣，并为可变的高峰部分保留按需或自动扩缩容的产能。定期审查承诺，以免锁定你后来已经重新架构掉的产能，并与采购和商业同事协调采购（参见主题 6.3——采购与商业事务）。

6. 像管理云计算一样有意识地管理 SaaS 和许可证蔓延。 云账单是可见的；用部门卡购买的二十个 SaaS 订阅、仍分配给离职者的按席位许可证，以及做着同一件事的重叠工具却不是——但它们加在一起，常常能与基础设施支出相媲美。维护一份实时的软件订阅和授权登记册，将许可证与实际具名用户和使用情况进行核对，取消或降级未使用的部分，并整合重复的工具。这里的软件资产管理既是一门成本纪律，也是一门安全纪律，因为未知的 SaaS 也是未受管理的数据流（参见主题 1.7——信息治理、数据保护与网络安全）。

7. 以单位经济学、而不是账单大小来评判成本。 一张上涨的账单不自动等于坏事，一张下降的账单也不自动等于好事；重要的是成本相对于交付价值的比率。定义在临床和运营上说得通的单位成本指标——每监测患者、每预订的预约、每处理的转诊、每千次 API 调用的成本——并随时间跟踪它们，这样你就能区分效率与单纯的增长，并为真正物有所值的支出辩护（参见主题 6.2——收益实现与价值管理，以及主题 10.1——关键绩效指标）。单位经济学也是你把运营成本与该服务的卫生经济学案例联系起来的方式（参见主题 6.1——卫生经济学）。

8. 以整个资产的总拥有成本、包括退出成本来思考。 一个平台的标价只是其生命周期成本的一小部分；集成、数据迁移、支持人员、培训、出口费用，以及最终离开的成本，都属于这幅图景。在一个现实的生命周期内依据总拥有成本评估各方案，要对提高退出成本的数据出口费用和专有服务尤为警惕，并记住锁定是一项未来的成本，即使它今天看起来是免费的（采购部门拥有锁定的合同方面——参见主题 6.3——采购与商业事务）。TCO 视角也能防止机构为一个悄悄运营成本高昂的廉价平台而沾沾自喜。

9. 将成本嵌入工程和治理，使其持续运作。 当 FinOps 是一次季度清理运动时，它会失败；当成本是设计评审、架构决策和交付管道中的一项常设考量时，它会成功（参见主题 3.6——DevOps 与工程卓越）。给团队成本预算和异常告警，把估算的成本影响纳入重大架构决策，并设置自动化告警和硬性支出护栏，使一次失控的作业在几小时内、而不是在下个月的发票上被发现。运作阶段的目标是让成本意识变成普通的工程卫生习惯，而不是一次外部审计。

10. 权衡成本与临床价值和可持续性，而不仅仅是成本本身。 最便宜的选项并不总是正确的：一次激进的节省，若削弱了韧性、推迟了补丁，或降低了一项面向患者的服务，就是在向错误的方向用金钱换取风险。将成本决策明确地与临床价值和碳排放进行权衡，因为你消除的浪费计算能力也是你避免的排放——成本和可持续性优化常常指向同一个方向（参见主题 8.5——可持续性与净零排放）。让这些取舍变得可见并被拥有，而不是让成本压力悄悄侵蚀安全。

与团队讨论的问题#

1. 我们技术的运营成本究竟由谁拥有——那个负责人是否既有可见性又有权力去改变它？ 这很重要，因为无人拥有的成本正是会不受控制地增长的成本：工程师为交付而优化，财务看到一张发票，没有人对两者之间的缺口负责。辩论成本所有权是位于一个无法影响工程决策的中央财务团队，还是位于看不到账单的工程师，还是理想情况下位于一个横跨两者的联合能力。探究这个负责人是否能够真正采取行动——他们能否关掉一个闲置的环境、阻止一份未标记的资源，或拒绝一个不必要地昂贵的设计——还是他们只能在钱花掉之后进行报告。考虑卫生领域特有的张力：成本负责人绝不能以节省的名义损害临床安全或连续性，那么这些护栏在哪里。一个好的、诚实的答案会指明一位具体的问责负责人或论坛，确认它拥有近乎实时的可见性和真实的决策权，并坦率地承认在今天哪些地方的答案是"发票就这样到了，我们就付了"。

2. 我们的云和软件支出中，有多少真正在交付价值，我们怎么知道？ 大多数机构无法回答这个问题，因为它们跟踪的是总账单，而不是它买到的价值，因此每一项成本看起来都同样合理或同样可疑。讨论你是否有把支出与某个临床或运营事物联系起来的单位成本指标——每患者、每预约、每 API 调用的成本——还是你只有一个不断上升的、未加区分的数字。揭示削减成本与价值之间的取舍：目标不是最小的账单，而是最佳的回报，这有时意味着为一项明显物有所值的服务多花钱。考虑你的支出中有多少是可衡量的浪费——闲置的环境、过度配置的实例、离职者的许可证——相对于真正有生产力的负载，并诚实地说明你对那个划分有多大信心。一个好的答案会用证据区分浪费和价值，至少有几个真实的单位经济指标，并抵制"账单更小就自动更好"这种反射。

3. 当我们把支出从资本转向营运支出时（过去或现在），谁理解预算和长期后果？ 从资本支出到营运支出的转变常常被当作一次纯粹的技术迁移来对待，但它改变了资金来自哪个预算，把一次性成本转变为永久性的经常性成本，并可能悄悄地使机构承诺了多年不断上升的负债。辩论你的财务和数字团队在做出承诺之前是否共同为此建模——有没有人绘制多年期的营运支出轨迹、退出成本，以及对 NHS 严格控制的资本与营运支出平衡的影响。考虑诚实的陷阱：云迁移常常是靠假设有纪律的成本管理所带来的节省来推销的，而那种纪律后来从未实现，那么你的商业论证案是否基于一种你实际上已经建立起来的 FinOps 能力。探讨当经常性账单增长速度快于为其提供资金的预算时会发生什么，以及届时谁对此负责。一个好的答案会展示财务和数字部门共同就整个生命周期进行推理，而不是一个为迁移速度优化的技术团队、财务部门之后才发现后果（参见主题 6.0——财务管理与商业论证案）。

4. 我们有多大信心，一次失控的成本会在几小时内、而不是在下个月的发票上被发现？ 计量式云计算的决定性危险，是一个错误与其被发现之间的延迟：一个配置错误的作业、一次意外的过度配置，或一个被遗忘运行的测试环境，可能在一份月度账单揭示它之前，就已经悄悄地烧掉了数周的公共资金。讨论你是否有异常告警和硬性支出护栏连接到能够采取行动的人，还是你唯一的检测机制是一个月后才到达的发票。探究护栏——真正阻止浪费——与那些过于激进、以至于在错误的时刻扼杀一个合法临床工作负载的控制措施之间的平衡——一个总是狼来了的告警很快会被忽视，一个阻止一项安全服务的护栏比它所防止的支出更糟糕。考虑谁会在凌晨两点收到一次异常告警，以及他们是否既有权威、又有信心去据此行动，而不必担心会破坏某个面向患者的东西。一个好的答案会描述一个以小时计的、经过测试的检测和响应循环，指明谁拥有它，并诚实地说明过去有多少次意外只是在账单到来时才被发现的。

5. 我们在为多少看不见的软件付费——如果一份没有人使用的工具的订阅续订了，谁会注意到？ 云计算账单至少是可见的；用部门卡购买的一堆 SaaS 订阅、仍分配给离职者的按席位许可证，以及做着同一件事的重叠工具则不是——但它们加在一起，常常能与基础设施支出相媲美。讨论你是否持有一份与实际具名用户核对过的实时软件授权登记册，还是续订悄悄通过，因为没有任何一个人拥有整体图景。同时揭示安全维度和成本维度：未知的 SaaS 也是未受管理的数据流，因此影子软件既是资金流失，也是一个信息治理缺口（参见主题 1.7——信息治理、数据保护与网络安全）。考虑这种情况发生的组织性原因——下放的预算和便捷的刷卡付款，使购买软件毫无摩擦，退役它却几乎不可能——以及需要改变什么，才能让某人对总量负责。一个好的答案会承认资产的软件支出中有多少真正被绘制出来，将刻意选择的工具与逐渐累积的蔓延区分开来，并能指出一次真正取消了某项订阅的核对。

6. 当成本压力和临床安全拉向相反方向时，我们如何确保安全获胜——我们能证明它确实获胜了吗？ 本主题中的每一个优化杠杆——调整规模、关掉东西、推迟支出、购买最便宜的选项——如果粗心地应用，都可能削弱韧性、推迟补丁，或降低一项面向患者的服务，正好在错误的方向上用金钱换取风险。辩论你的成本决策是否带有一次明确的安全检查，使一个被标记为临床关键的工作负载在任何变更触及它之前被单独审查，还是成本目标被允许悄悄地、无形地侵蚀安全。考虑那个通常一致而不是冲突的可持续性角度：作为浪费而被消除的计算能力，也是被避免的碳排放，因此成本和净零排放优化常常指向同一个方向（参见主题 8.5——可持续性与净零排放）——但要诚实面对两者分歧、必须有所取舍的情况。探讨当一个节省目标和一项韧性要求发生冲突时谁来坚守底线，以及这个取舍是被公开做出并有归属，还是在预算压力下悄悄做出。一个好的答案会展示安全和连续性被当作成本不得凌驾其上的约束条件，有一个真实的机制来执行它，而不仅仅是一个在发票增长时就会弯曲的口头价值观。

实践中：一个卫生与照护案例#

Northmarsh 整合照护系统在两年内将其分析平台、若干面向患者的服务和一个大型数据湖迁移到公共云，资金由一份商业论证案支持，该案承诺相对于它所取代的老化数据中心有适度的节省。迁移按时交付并受到庆祝。十八个月后，月度云发票的运行水平几乎是商业论证案数字的两倍，每个季度都在增长，当财务总监要求数字团队解释这次增长时，没有人能够分解这个数字。这张发票是来自提供商的单一一行，其下方没有任何东西被打上标签。

董事会委托了一个小型 FinOps 举措，而不是一道一刀切的削减成本命令。它的第一项工作是知情：团队建立了一个成本可见性工具，强制执行一个标签标准，花了六周时间为资源补打标签，并将其与拥有它们的服务进行核对。浮现出的图景是熟悉的。数据科学团队的开发和测试环境——庞大、昂贵的实例——持续运行，包括没有人使用它们的夜晚和周末。被迁移的数据湖被原封不动地搬到了高级存储上，没有任何生命周期策略，因此五年的过时快照正在以全价累积。三个独立的团队正在为用不同预算购买的重叠 SaaS 分析工具付费。一项在迁移期间被错误配置的批处理作业，已经连续数月每晚重新处理同一个数据集。

优化阶段被刻意按风险分阶段进行。非生产环境被安排在工作时间之外自动关闭，节省了一大笔经常性资金，对临床没有任何影响。存储被分层并赋予了生命周期，使旧快照自动过期。始终在线的面向患者服务的稳定基线负载被分析，并覆盖了一份与采购同事协商的三年期承诺使用折扣。重复的 SaaS 工具被整合为一个。至关重要的是，在任何变更触及面向患者或临床关键工作负载之前，其标签会将其标记为需要单独、谨慎审查——成本从未被允许凌驾于安全或韧性之上。

然后是运作阶段，这是最重要的部分。每个服务团队都获得了一份月度内部核算报告和一个成本预算，异常告警被连接起来，能在几小时内标记出任何突然的跳跃，一项轻量级的成本检查被加入架构评审清单，使新设计带有一个估算的运营成本。在两个季度内，账单回落到低于原始数据中心基线的水平，更重要的是，它不再是一个谜团——每一英镑都可以归因于一项服务，该 ICS 现在能够报告其分析平台每活跃用户的成本，并将其作为价值来辩护。这份节省是真实的，但持久的胜利是那个闭合的循环：决策现在有了可见的、有归属的财务后果。

行业视角#

初创企业#

对一家数字健康初创企业而言，云成本是生存的数学：它常常是单一最大的基础设施条目，燃烧率直接决定了资金跑道。创始时的优势是，FinOps 纪律可以从第一次提交起就被建立起来——从第一天起就打标签、每个工程师都能看到的成本仪表板，以及作为核心业务指标被投资人审视的单位经济学（服务一个患者或一个客户的成本）。风险在于过早过度优化，把稀缺的工程时间花在削减一张仍然微小的账单的几分钱上，或在架构稳定之前就锁定长期承诺。能够规模化的纪律是文化性的：把成本当作一项产品指标，而不是财务的事后补充，这样当这家初创企业赢得一份 NHS 合同时，其服务成本已经是已知且站得住脚的。

小型企业#

一家成熟的小型服务提供者——一家全科诊所、一家社区药房、一家养老院、一家单点诊所，或一家小型健康科技供应商——支付着与一家大型信托机构相同的计量制云和 SaaS 账单，却没有专职的 FinOps 或 IT 能力来管理它们，因此实际的优先事项是一小撮高杠杆的习惯，而不是一整套纪律。现实的胜利是消除明显的浪费（关掉未使用的东西，删除旧存储），保留一份简单的、列出每份订阅和许可证及其续订日期的清单，使没有任何东西在无人察觉的情况下续订，并对一个小型机构难以轻易解开的长期承诺或锁定保持警惕。成本可见性通常意味着每月查看一次提供商控制台，而不是一个实时仪表板，资产的很大一部分可能是为让别人运行而选择的 SaaS，这将纪律的重点从调优基础设施转向管理订阅和阅读合同。不可避免的张力是，与一家大型机构相同的信息治理和连续性责任同样适用，但在现金紧张和人手稀少的情况下，为了省钱而推迟补丁或降低韧性的诱惑是真实的——因此即使在这里，一条明确的"安全不能用来交换成本"的规则也很重要，最好由共享或框架采购来支撑，使小型提供者不必独自谈判云和许可证价格（参见主题 4.1——平台与共享服务）。

大型机构#

一家大型 NHS 信托机构或 ICS 运行着一片庞杂的资产——遗留数据中心、多个云账户、数百个跨越数十个预算购买的 SaaS 订阅——它的挑战是规模化的协调和分配。现实的目标是一个中央 FinOps 能力，为分散的团队提供可见性和护栏，而不会变成一个瓶颈：一个共同的标签标准、对每项服务的内部核算、集中协商的承诺使用采购，以及嵌入架构治理中的成本考量。最难的问题通常不是技术性的，而是组织性的——让说着不同语言、向不同董事报告的工程和财务部门，共享同一个真相视图。在这种规模上，最大的胜利来自一致应用的几项资产范围纪律（打标签、消除浪费、承诺使用、SaaS 合理化），而不是对任何单一服务的英雄式优化，成本工作必须被明确地划定边界，使其永远不会侵蚀临床安全或连续性。

政府#

一个国家机构——NHS England、一个权力下放的卫生部门、一个共享服务组织——塑造着每个提供者运营所在的成本环境。它的杠杆是聚合：协商国家云和许可协议，使单个信托机构不必各自从弱势地位谈判；发布 FinOps 和 TCO 指导，使良好实践成为默认做法；构建单位成本随着更多机构使用而下降的共享平台（参见主题 4.1——平台与共享服务）。政府还拥有使资本支出到营运支出转变如此重要的资本与营运支出规则，它能够通过如何分配和调整预算来缓解或加剧那种摩擦。它对议会和公众负有整个系统物有所值的责任，因此它承担着让成本在各机构之间透明和可比较的义务，并确保成本压力不会悄悄扩大患者所获得服务中的不平等。

常见失败模式#

• 神秘发票。 一张不透明的账单每月到达，没有人能够分解它，等到有人质疑它时，钱早已花掉。用标签化和近乎实时的可见性先解决这个问题。
• 原封不动地搬迁，然后感到惊讶。 把服务器原封不动地迁移到云端，让它们全天候以全尺寸运行，并期望云端经济效益凭空出现。云只有在你使用它的弹性时才能省钱——调整规模、安排时间表并扩缩容。
• 削减成本而不是管理成本。 一次性的恐慌式清理，为一个季度省钱，损害了韧性，却悄悄地重新长回来，因为底层行为什么都没改变。FinOps 是一个持续的循环，不是一场运动。
• 优化掉了安全。 为了达到一个成本目标而关闭冗余、推迟补丁，或使一项临床服务配置不足。成本决策必须明确地与临床价值权衡，绝不能凌驾于它之上。
• 潜伏在阴影中的 SaaS。 用部门卡购买的数十份订阅、仍分配给已离职人员的许可证，以及三个做着同一件事的工具——因为它们不在云账单上而不可见。维护一份实时的软件登记册并加以核对。
• 过早的转嫁核算。 使用不成熟、有争议的分配数据从团队那里收回成本，产生使整个努力失去信誉的争论。从内部核算开始；先赢得数据质量，再移动资金。
• 盲目承诺。 为六个月后就会被重新架构掉的产能购买三年期预留，或从不为一个稳定基线购买承诺，永远支付全额的按需费率。将承诺与真正可预测的负载相匹配，并对其进行审查。

成熟度模型#

检查清单#

• 云和技术支出对做出设计决策的人而言，是按服务和团队细分的、近乎实时可见的。
• 一个强制性的标签标准被自动执行，正确分配的支出比例是一项被跟踪的指标。
• 内部核算（或，在成熟的情况下，转嫁核算）为每项服务提供了一个可辨认的、关于其技术消费的视图。
• 非生产环境被安排在工作时间之外关闭；资源被调整为观察到的负载规模；存储有一个生命周期。
• 可预测的基线由承诺使用或预留产能折扣覆盖，并定期审查。
• 一份实时的软件资产登记册将 SaaS 订阅和许可证与实际用户和使用情况进行核对。
• 单位成本指标（每患者、每预约、每转诊、每 API 调用的成本）被定义并依据价值被跟踪。
• 各方案在一个现实的生命周期内依据总拥有成本被评估，包括出口和退出成本。
• 成本影响是架构评审中的一个常设项目，自动化护栏和异常告警能在几小时内捕捉到失控的支出。
• 影响面向患者或临床关键工作负载的成本决策被单独审查，绝不凌驾于安全、韧性或可持续性之上。
• 财务和数字部门在做出重大承诺之前，共同为资本支出到营运支出的轨迹建模，包括多年期的经常性负债。

关键资料来源#

• FinOps Foundation ——《FinOps 框架（FinOps Framework）》（知情/优化/运作生命周期、原则、能力和角色）——云财务运营的公认知识体系。
• HM Treasury ——《绿皮书》（评估与评价）以及关于资本和营运（资源）支出区分的公共支出规则。
• NHS England ——云、技术和数字支出指导，包括云采纳以及 NHS 数字投资中资本和营运支出的处理方式。
• 云提供商的良好架构成本优化指导——AWS Well-Architected Cost Optimization Pillar、Microsoft Azure Well-Architected Framework（Cost Optimization）、Google Cloud Architecture Framework（Cost optimization）。
• AXELOS / PeopleCert —— ITIL 4，《IT 财务管理（IT financial management）》实践（IT 服务的预算编制、会计和计费）。
• Technology Business Management（TBM）Council —— TBM 分类法和标准，用于透明地核算和管理技术支出。

参考文献#

1. Cloud computing — Wikipedia — https://en.wikipedia.org/wiki/Cloud_computing
2. Capital expenditure — Wikipedia — https://en.wikipedia.org/wiki/Capital_expenditure
3. Operating expense — Wikipedia — https://en.wikipedia.org/wiki/Operating_expense
4. Cost allocation — Wikipedia — https://en.wikipedia.org/wiki/Cost_allocation
5. Cost centre — Wikipedia — https://en.wikipedia.org/wiki/Cost_centre_(business)
6. Total cost of ownership — Wikipedia — https://en.wikipedia.org/wiki/Total_cost_of_ownership
7. Software asset management — Wikipedia — https://en.wikipedia.org/wiki/Software_asset_management
8. Software as a service — Wikipedia — https://en.wikipedia.org/wiki/Software_as_a_service
9. Software license — Wikipedia — https://en.wikipedia.org/wiki/Software_license
10. Autoscaling — Wikipedia — https://en.wikipedia.org/wiki/Autoscaling
11. ITIL — Wikipedia — https://en.wikipedia.org/wiki/ITIL
12. Unit cost — Wikipedia — https://en.wikipedia.org/wiki/Unit_cost
13. FinOps Foundation — FinOps Framework — FinOps Foundation (Linux Foundation) — https://www.finops.org/framework/
14. HM Treasury — The Green Book: appraisal and evaluation in central government — GOV.UK — https://www.gov.uk/government/publications/the-green-book-appraisal-and-evaluation-in-central-government
15. NHS England — Cloud and technology guidance — NHS England — https://www.england.nhs.uk/
16. Amazon Web Services — Well-Architected Framework: Cost Optimization Pillar — AWS — https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/welcome.html
17. Microsoft — Azure Well-Architected Framework: Cost Optimization — Microsoft Learn — https://learn.microsoft.com/en-us/azure/well-architected/cost-optimization/
18. Technology Business Management Council — TBM Framework and taxonomy — TBM Council — https://www.tbmcouncil.org/