得物FinOps落地实践

1、背景

随着得物电商、社区业务迅速发展，云计算已成为支撑业务运行的关键基础设施。然而，云计算的便利性和灵活性也带来了一系列云成本管理挑战，包括成本增速过快、成本归属不清晰、缺乏有效成本控制手段、对云厂商高度依赖等，因此云成本治理成为各公司的重要方向。作为快速发展中的互联网公司，得物在业务增长的同时，开展了成本治理和FinOps项目落地工作，实现年度云成本节省上亿元，成功抑制云成本的不合理上涨趋势。

此次分享得物FinOps实践经验，希望能为读者提供一些借鉴思路。

2、得物FinOps引入​

2.1   什么是FinOps？

FinOps 是“Finance”和“DevOps”的综合体，强调运维过程中的成本管理和资源优化。

FinOps有一个权威组织，FinOps 基金会，该基金会是Linux 基金会发起的项目，致力于通过最佳实践、教育和标准来推动实践云财务管理学科。近年发展迅速，社区拥有超过 8,700 名成员，致力于解决云的爆炸式增长以及云成本管理挑战。

在当今数字化转型的重要时刻，FinOps不仅仅是一个将财务和技术结合起来的领域，而且是云计算的关键领域之一。通过FinOps，IT和财务部门可以更好地合作，实现更好的业务成果和财务可持续性。因此，越来越多的企业积极开展FinOps实践项目，并跨过了他们在实践中所面临的壁垒，得物正是一家在FinOps实践中持续探索的公司。

FinOps基金会对FinOps定义：

• FinOps是一种不断发展的云财务管理学科和文化实践，通过帮助工程、财务、技术和业务团队在数据驱动的支出决策上进行协作，使组织能够获得最大的业务价值。
• FinOps的核心是一种文化实践，通过跨职能团队协同工作，以实现更快的产品交付，同时获得更多的财务控制和可预测性。
• FinOps的特点是将问责制引入云支出，FinOps是财务责任文化变革带入云的可变支出模型的实践，使分布式工程和业务团队能够在其云架构和投资决策中的速度、成本和质量之间进行权衡。

FinOps成熟度模型：

FinOps Framework定义了关于FinOps 的“爬、走、跑”成熟度特征。

在落地FinOps实践时，了解成熟度模型和指标可以帮助团队准确评估其当前水平，发现改进点和推进方向。例如，对于初步实践的团队，最初的重点可能是寻找成本和资源的可视化方法，而更成熟的团队则可能更加关注云开销和预算分析、成本优化和分配、以及团队间的协作和沟通等方面。

成熟度模型的应用，可以帮助企业实现可持续的FinOps成果，进而达到支出透明度和控制、优化云资源和实现最大化业务价值的目标。​

2.2   FinOps实践路线

得物从2021年开始关注云成本效能。经过对FinOps体系深入研究，反复讨论，持续了近2年的落地实践，FinOps成熟度级别已逐步进入到 “跑” 阶段。下文会介绍得物FinOps建设的历程，以及各阶段行动路径，供读者参考。

结合公司现状，得物借鉴FinOps社区主推的成本洞察、成本优化、成本运营层层递进，多管齐下的方式开展得物FinOps落地。按技术驱动、业务驱动、运营驱动三个方面来推动机制流转。最终实现成本透明度和控制、优化云资源、并最大化业务价值。

3、得物FinOps构建历程

3.1   FinOps - Inform(Visibility & Allocation)

成本可视化阶段，FinOps基金会对企业云成本治理的第一步“爬”，就是需解决Inform(Visibility&Allocation) 可视化、账单分摊的问题，这是FinOps之旅的第一阶段，它赋予组织和团队可视性、分配、基准、预算和预测能力，使其有必要为智能决策提供准确和及时的可见性。

得物从2021年开始打造基于多云环境的资管与成本运营平台 - 成本中心，在这一阶段，优先支持了成本数据分摊能力，分摊到部门、业务域。支持成本预测、预算管控、成本结算等功能。

3.1.1 成本分摊

在数据分析前需要进行着手的事情便是基础数据汇聚。在这里不得不提得物CMDB系统，CMDB是一套自研的基础资源管理平台，涵盖了云上、云下（IT资产）等资源管理。云上应用向下管理资源，向上挂在技术组织架构、业务域等不同维度，总体形成了一棵应用树。以应用为中心，把组织架构部门/业务域、人、应用、资源关系串了起来。

成本中心通过对接云厂商、CMDB、发布系统、内部监控系统，获取所有成本关联数据。成本按实例账单汇聚，实例级维度分摊到到业务域、组织架构、人。支持日、周、月维度成本数据和成本预测。数据分析方面则构建轻量化BI能力，满足多维度分析，并辅助高层决策。

成本中心上线后带来改进：

• 将成本按人头归属后，研发成本意识得到提升，开始关注项目资源的利用率。
• 多维度的成本拆分：部门维度、产品维度、业务维度和场景维度。
• 支持成本预测，当月、下月各部门成本预测，便于提前规划优化动作。

3.1.2 预算机制

得物技术部2022年开始云上预算管控流程，由成本管理团队组织并推动预算管控体系的落地，包括目标责任体系、信息反馈系统、预算指标系统。

• 预算编制：以半年或季度为预算周期，设置总体目标和要求，逐级分解到部门/项目，落实到具体负责人；
• 预算执行：根据预算规划业务，预算水位预警及工单审计联动；
• 预算考核：对照设定的预算指标，总结预算执行情况、差异分析、归因分析、改进措施，形成预算反馈报告。

实际执行中，业务发展存在并非完全沿着预算发展，因此得物采用的是固定预算+滚动预测相结合的方式，预算编制是自下而上的预算收集与审核，动态调度分配预算资源。

3.1.3 新增成本收口

成本新增管控：成本中心解决了存量成本可视化和治理闭环，对于新增资源申请，也要进行卡口，得物自研的穷奇审批平台，可结合成本预估功能、预算体系，智能化生成资源申请审批流程，有效提高研发人员成本意识及对新增成本进行合理性评估。

所有资源的申请都要经过如下步骤：成本预估---->预算水平判断----->智能审批节点生成。

• 成本预估：在资源申请阶段，系统会自动进行成本预估，帮助研发人员更好地了解资源需求对成本的影响。
• 预算管理：可拉取部门预算水位，结合预估成本，综合展示申请资源对于本部门预算影响。
• 智能审批节点：结合预算和成本预估、预算信息，工单系统会自动添加相应的审批节点，确保资源申请的合理性和合规性。

实施了上述治理措施，得物的FinOps实践第一个难关得到解决，实现了能力的具备和实际应用。这些措施帮助得物更好地管理成本，提高资源使用效率，避免不必要的成本浪费，实现优化资源管理、提高效率、降低成本的目标。

3.2   FinOps - Optimize(Rates & Usage)

成本优化阶段，按照FinOps落地要求，当具备成本账单分摊和可视化后，得物在FinOps基金会定义的成熟度模型Maturity 中由“爬” 进入到“走” 阶段。进入到Optimize阶段，需要进行多维度考虑，包括云产品计费方式最优、商务折扣竞争力、技术降本（自研paas/弹性计算/多云等）、精细化成本运营（资源投入和业务收益的roi分析）等。

3.2.1 提升计算资源利用率

云服务器成本治理

云服务器ECS作为云上基础设施，成本占比达第一，并随着技术架构改造的深入，ECS成本占比会逐步增加，因此，提高ECS成本合理性是云成本治理的首要任务。主要推动以下内容：

• 计费模式优化：包年包月计费&按量计费择优选择
• 空跑或低利用率资源巡检：制定不同巡检规则、及时释放闲置资源
• 服务器&&应用的完整生命周期管理：建立服务器或者应用的上下线管理制度确保不会出现死应用或者服务器

最终成果：

全站容器化

作为拥抱云原生不可或缺的一环，服务容器化的实践将提高资源利用效率，加快部署速度，并确保应用程序在不同环境下的一致性和可重现性。得物自2021年开始，在KubeOne的基础上建立了自己的容器平台，启动了全站容器化项目，成功完成了涉及数十个业务领域上千个应用的容器化改造，标志着得物容器化元年的开启。该项目的完成大幅提高了资源利用率，整体资源利用率环比上升了10%。此外，硬件成本和管理成本也得到了降低，应用程序的可靠性和可伸缩性也得到了提高。

垂直自动伸缩（VPA）

FinOps落地实践指的是一种运用自动化容器资源管理技术的方法，该技术能够根据容器实时使用情况自动调整所需的CPU和内存资源。使用垂直自动扩缩容技术（VPA），容器可以在实际需要的资源水平上运行，避免不必要的资源浪费和成本开销。

得物依托VPA和宿主机超售技术，启动了容器技术方案的实施，旨在降低基础设施成本。

服务画像

在实施FinOps的过程中，应用画像是解决单应用资源配额问题的一个有效方法。应用画像主要是通过描绘在一定时间周期内应用集群对资源需求的情况来达成这一目的。资源包括了cpu、内存、磁盘、网络等。应用画像不仅可以展示应用的当前状态，还可以通过对固定周期的CPU、内存等资源消耗数据进行分析，从而预估未来一段时间对某种资源使用的趋势。下图展示了应用画像的流程：

最终降本增效成果：

3.2.2 内部结算，资源售卖模式

针对实施FinOps时遇到的产品定价问题，得物提出了一种差异化的产品定价方案，以应对不同计算资源使用情况下的SLA需求。为此，得物自研了容器管理平台KubeOne，实现了按照细分SLA标准差异化定价，并引导业务按照实际需求选用不同标准的SLA产品，并将分摊成本实时推送至成本中心的各维度场景成本拆分中。

3.2.3 混合部署

统一调度混部实现

实现容器统一调度平台管理系统可以有效地利用集群级别的碎片资源，从而降低单位成本30%。这种解决方案还可以解决K8S集群孤岛和直接暴露K8S机器api给上层平台的问题，提高稳定性并为后续更多的PAAS自建做好准备。

资源管理系统：实现应用画像、任务画像、节点画像，为精准调度提供数据决策支持

联邦调度可以根据每个集群的资源情况和特定应用或任务的自定义需求选择最适合的集群，然后将该应用分发到相应集群的kube-apiserver。这种分散式的调度可以最大程度地优化资源的利用，并有效地保障不同业务的独立性。在项目实施过程中，我们的工作主要集中在以下两个方面：

混部资源的隔离与保护

在混合部署后，为提升集群资源利用率的同时保障高优在线应用的SLO，我们需要即刻采取措施，对离线应用进行压制或直接驱逐。

绑定核心可确保高优应用的算力，因为一台物理主机上可分配多个 socket、每个 socket 上有多个 NUMA、每个 NUMA 内有多个物理核，且每个物理核还有多个逻辑核。我们还可以通过将 CPU 划分为不同级别，供高优应用独占使用（见图右）。

针对I/O资源竞争问题，不同的应用程序可以使用不同的磁盘挂载解决。此方法有效解决I/O资源竞争问题，改善应用程序稳定性和性能。此外，每个应用程序都有自己的磁盘分区，这使得备份和恢复数据更加方便。

同时，我们还优化了内核参数，以确保在线应用程序可以优先获得所需资源，而离线应用程序的CPU范围也可缩小。除了缩小离线应用程序可使用的CPU范围，我们还将采取一系列措施，以保障在线应用程序的SLO。

混部资源调度优化

为了实现实时资源感知，我们需要通过每个节点实时采集每个WorkLoad-Pods的CPU水位情况。然而，这样产生的大量数据需要聚合，以便调度器可以实时感知并做出决策。为了解决延迟和数据失效等问题，我们采用了一种名为 EXPMA（指数平均数指标）的算法来聚合数据，类似于股票指标中的移动平均线。与定期聚合不同，EXPMA可以更及时地探测到资源需求的变化，并且对历史数据的贡献逐渐减少，从而更好地反映当前的需求情况。

EXPMA是一种支持递推计算的波动指标，其自身具有历史连续权重且在当前时刻拥有最高的权重，因此非常实用。为了保持系统的稳定性和正确性，我们可以准备24个槽位，并将每小时的EXPMA值写入对应的槽位。此外，我们采用FUTURE-SUM计算每个节点上Pod的CPU-EXPMA值，并在基于24个FUTURE-SUM的基础上进行SD方差计算。根据计算结果，我们将节点的FUTURE-SD值进行排序，从而得出最适合调度Pod的节点。排序越靠前的节点越适合调度，因为这意味着在调度Pod后，未来上面Pod的CPU相位相互抵消的概率更高，从而波动率得以抑制，资源波动会更平稳，稳定性也更高。

混部落地情况

完成了以上一系列的能力完善后，在2022年初，得物正式启动了实时计算平台任务(Flink)混部项目，第一批基于 kube-adapter 与实时计算平台的对接，实现了自动扩缩容和动态调度。

Flink选择采用我们的动态资源分配，BE类型的应用程序能够充分利用BE范围内的CPU核心资源，从而有效地降低了单核成本。为任务平台提供更为高效和低廉的的算力，进而提升其整体的资源使用率和稳定性。

下图为整个迁移混部的具体步骤：

截至发文，得物已经成功完成了Flink任务的全量混部，这一成就不仅使得任务平台的单核成本下降了50%，而且还为包括基础架构、日志平台等在内的10多个业务线的算力成本优化提供了显著的支持。这次混部的成功为未来更多的大数据离线业务混部奠定了坚实的基础，并将在确保核心业务稳定的情况下进一步将单核成本降低，实现更多的业务增长。

3.2.4 PAAS自建

自建KubeAI替代Pai

我们在实践中发现，PaaS类服务的公有云优势在快速部署和简易维护方面是无可比拟的，但相较自建，其定价更高。在得物容器化项目中，我们收集了算法团队对于模型训练以及模型服务管理的需求，以及其他业务部门有关AI场景的容器化需求。通过利用KubeOne容器平台的能力，我们建立了面向AI业务场景的KubeAI平台。这个项目的完成让算法PAI任务的整体成本降低了35.6%。

KubeAI平台的设计理念在于让用户摆脱繁琐而重复的资源调度工作，专心致力于模型整个生命周期的开发，从需求到任务的编排，轻松管理模型的训练和推理服务。KubeAI通过KubeOne对资源的调度能力，合理规划资源并分配给不同的任务，包括弹性资源、非弹性资源和按一定比例超卖的资源。

不仅如此，KubeAI还支持平台用户的需求，为当前CV团队的模型开发提供全面覆盖的支持，使其可以在KubeAI上方便地进行模型训练、管理和推理服务管理操作。同时，KubeAI还支持OpenAPI对接，并且可以与其他平台无缝集成，如DPP召回引擎管理平台的引擎构建任务、风控算法平台的模型及推理服务管理、DML平台的搜推模型训练任务等。综上，KubeAI平台的优势在于其极致的用户体验和完备的功能模块，为模型生命周期管理提供全方面的支持。

随着公司业务的快速增长，云Redis的成本也不断增加，从成本角度来看已经逐步形成挑战。为应对这一挑战，得物在2022年下半年启动了自建Redis研发与迁移计划，目前取得了不错的成果。生产环境接入自建的Redis涵盖了高 QPS、高流量、大容量的特征，同时也验证了这套方案的可靠性。经过测算，从云Redis迁移到自建Redis，成本收益至少 50%。

为了研发无感下云，我们自建 Redis 服务也采用了类似云 Redis 的架构。整套系统由 ConfigServer、Proxy、Redis-server 等核心组件构成，整体架构图如下所示：

自建日志平台替代SLS

为了降低公司的日志存储成本，提高日志查询的能力，同时为业务方提供更加便捷的日志订阅服务，公司决定推出自己的日志平台替代SLS。该平台将统一管理公司内部的日志数据，实现运维化管理，并利用先进的技术手段提高日志的查询能力和用户体验。通过这一平台，公司将获得更高效、更经济、更可靠的日志管理服务，进一步提升业务的运营效率和核心竞争力。

得物日志平台具有以下特点：

成本低廉：通过自建日志平台，可以降低存储成本、日志查询成本等，从而提高整体效率。

查询能力强：得物日志平台具有快速、精准的查询能力，支持关键词搜索、过滤、聚合等功能。

订阅方便：得物日志平台提供了方便的订阅功能，支持将日志信息推送到指定的接收方，如邮件、短信等。

运维化管理：得物日志平台提供了完善的运维管理功能，如权限管理、监控告警等，以确保系统的稳定和安全运行。

经过全面的项目实施与精细的成本控制，得物成功将日志平台从云上迁移至自建环境，最终实现了成本总计优化，并节约了至少30%左右的成本。这一成果不仅充分彰显了得物在技术创新方面的卓越实力和经验，同时也为公司的发展注入了新的动力。

除以上，得物还进行了CK、LB、Flink、Hbase、kafka、Mq等paas组件自研，相比公有云paas产品，单位成本有较大幅度下降，自研和多云将是得物技术取得更多成本收益的方向。

3.2.5 SRE平台能力建设

目前得物CMDB、发布系统已具备多云管理控制和身份验证、网络安全和漏洞管理等能力。同时依托分布式部署监控采集端部署，具备跨云统一视图的可视化监控能力、双活网络环境能力。保证生产、测试网络资源规划符合高可用原则。这些基础平台能力使得得物可以有效控制云资源成本并优化资源配置，最终灵活的多云腾挪，在服务容灾和商务议价有更大灵活性，进而实现FinOps的目标。

整体框架如下：

SRE平台基础能力决定了应用是否可迁移至多云架构。其主要能力包括应用依赖关系分析、应用调用量分析、应用RT零容忍度分析及内核级分析排障等。该平台运用ebpf技术实现，如下图所示：

3.2.6 CDN的多厂商容灾和调度

作为互联网厂商，CDN成本是重要的网络流量成本。为优化得物CDN，主要有两个方向：1）引入多云容灾和调度能力；2）引入PCDN技术对视频进行加速。PCDN是一种产品，它通过充分利用网络上空余资源并确保稳定性，实现了网络的加速。得物PCDN的实现架构如下：

最终成果：

3.3  FinOps - Operate(Continuous Improvement & Operations)

成本持续改进和运营阶段，到这里，FinOps基金会定义的成熟度模型Maturity 中由“走” 进入到“跑” 阶段，得物目前正处于这个阶段，持续探索中。精细化成本运营势在必行。

3.3.1 FinOps组织协同

对标FinOps基金会建议的协同职能组织结构，得物建立一个成本运营虚拟组织，推进云成本优化。该组织架构主要包括以下部门和职责：

• 成本运营岗：负责日常云成本的运营管理，监控资源使用情况，发现并解决成本问题，推动各部门提高成本意识和优化资源使用。同时负责制定预算、分析成本数据，并确保云成本的合规性和合理性。
• 业务技术研发：各业务域都会有一名研发对接人，作为该部门成本负责人，认领成本运营下发的优化、预算等需求，协调部门内部优化落地，对部门成本健康状况负责。
• 财务部门：从财务视角对云成本进行管理和推动。
• SRE：作为云成本技术治理的专家，负责优化资源配置、提升系统性能，降低云计算成本，同时保障业务稳定运行。
• 采购部门：负责与多家云服务商进行商务谈判，争取更优惠的价格和服务条款，降低整体采购成本，提高企业在云市场的竞争力。

3.3.2 精细化成本运营

精细化运营的核心在于平衡成本、稳定和效率。基于数据分析呈现客观事实、基于分析结果做出成本管理策略。精细化运营包含单位成本的获取、效率指标的构建、持续化的跟踪优化

• 单位成本获取

根据经典的“ABC成本法”，完成云产品成本在生命周期各环节的拆分、挖掘成本驱动因素、建立云成本与业务大盘的关系，建立具有业务指标的单位成本。

• 效率指标构建

“业务场景梳理—>场景成本拆分—>场景核心指标—>建立效率指标模型”，建立一个场景的效率指标，提供成本决策数据依据。

• 持续化跟踪优化

大量资源申请时，需要AB实验数据支撑，由成本运营和业务部门根据AB实验数据预估推全数据单位成本变化及效率指标数据来评估ROI，并持续监控单位成本和效率指标是否恶化，定期复盘确认ROI是否达预期并干预优化。

下面以得物算法分业务场景模型推全过程，来了解下具体如何实施精细化成本运营。得物算法主要服务于电商、社区业务，通过场景考核指标趋势，来倒推算法资源成本合理性，是科学的办法。

算法场景成本运营内容：

如算法的一个交易瀑布流模型申请上线会走如下流程：

3.3.3 成本运营分析平台

上文讲到，在FinOps “爬” 的阶段，我们建设了成本中心系统，支持了基础的云账单分摊、云成本预测能力，将云账单合理的分摊给人、部门、业务域。但在Operate阶段，成本的持续优化进入深水区，需要更加完善的数据辅助分析决策，成本中心也在不断成长。

经过周维度的敏捷开发 持续了1年多，成本中心发展为集利用率分析、容量分析、智能算法推荐优化、财务-业务场景&资源roi分析的 一站式运营分析平台。已累计推荐驱动业务降本几百万元/月。

架构蓝图：

成本优化管家

成本优化管家帮忙解决云上资源运营难题，通过持续分析云资源性能监控指标，付费方式、云资账单等多个维度数据，提供合理的优化调整建议，优化建议在确保应用性够用的基础上，降低资源费用，并联动CMDB、工单系统、发布系统实现整体闭环：

• 优化逻辑：低利用率降配/释放、闲置资源释放、付费方式调整、状态巡检、规格调整等
• 支持产品：容器应用、常规应用、块存储、负载均衡、共享带宽、文件存储等

大促/日常容量评估

得物22年双12大促，凭借成本运营分析平台，对全网应用容量扫描，最终服务器扩容相比以往大促减少50%以上，并完美支持大促完成。是通过以下方法做到的：

对线上应用日常、大促时期的资源水位合理性确立统一标准，避免存量资源冗余多造成浪费，防止应用在大促时存在容量不足的风险。通过打通成本中心、CMDB、发布系统、监控系统、工单系统、容器平台、压测平台等系统的数据交互，获取应用在各个场景下的真实负载情况，并提供大促/日常的资源扩缩容推荐。

应用容量评估模块介绍：

• 评估依据：根据应用的资源利用率、流量相关度，大促/日常/压测期间的QPS、报错率、Rt。根据场景设定合理的目标阈值，满足优化前后应用的报错率、Rt在合理的区间时，再基于此时的状态对应用做扩缩容评估
• 评估合理化：基于数据支持，再通过严谨的评估方案，最终得到合理的评估推荐，有效的降低大促扩容成本，提升大促容量评估效率
• 评估闭环：平台针对容量评估提供一键操作。当应用缩容时，预测并保证应用缩容后的CPU、内存、错误率、Rt保持在合理范围内，保证够用的应用性能。当然针对负载较高的应用也会做扩容推荐，此时就会通知和推动SRE、业务方来评估处理，提前避免资源不足的风险点。

日维度自动化对账

为确保基础数据的准确性及减少资损，得物基于不同云厂商账单，制定自动化对账策略：

• 按照厂商、产品、账单类型及计费规则建立实例级的对账逻辑；
• 每日完成T-1日的百万条明细订单对账，逐一发现异常实例和异常订单，人工追溯处理异常信息；
• 每月完成千万条明细订单对账，汇总异常订单及资损，与云厂商完成结算。

结合FinOps基金会对Operate阶段的预期，成本的持续改进和运营可以将Infrom和Optimize阶段不断的夯实、升级；得物精细化成本运营进入这一阶段后，组织协同、体系化管控成为不可或缺的抓手；为更好的实现各职能协作关系，需进行FinOps人才培养和文化建设，考核机制也成为近期的工作重点。

3.4  FinOps - 人员能力和文化建设

为确保FinOps的顺利落地，必不可少的是人员能力培养。SRE团队作为最接近资源成本的一支队伍，扮演着降本增效推进的关键角色。得物公司在推进FinOps的同时，也进行了SRE能力建设。在保证业务稳定性的前提下，SRE团队不断探索挖掘，通过技术降低业务资源成本。

SRE驱动降本案例：节省百万/年云成本

背景：为了优化算法预估服务的性能和降低成本，我们需要改善在线推理服务的整体利用率。然而，当前在线推理服务因为使用过大的JVM导致了较高的GC时延，为了加快GC效率，必须保留较高的CPU算力，这进一步降低了整体利用率。

方案：我们的SRE团队通过内存分析发现，可以引入JDK17的ZGC来降低GC的STW时间，从而抑制甚至消除RT99的毛刺抖动。并且SRE工程师直接深入分析和理解业务源码，帮助业务优化缓存模型架构代码。

成果：通过优化，业务的RT性能翻翻，错误率下降10倍，大幅提升稳定性。从而以不牺牲 稳定性 和 性能 的情况下，大幅降低CPU资源的成本。

Devops和FinOps实际上都是在降本增效的背景下应运而生的岗位。需要不断的打磨，提升。关于FinOps的人才培养，除公司要求和文化宣导外，建议考取FinOps基金会官方认证，完成系统化的学习，成为该领域专家。

3.5   FinOps - KPI考核

FinOps 严重依赖关键绩效指标 (KPI)。KPI 用于获得可见性和度量视角，以简化成本控制过程。FinOps KPI 可大致分为以下几类：

• 云可见性 KPI包括与跨云环境的成本、消耗、性能、配置、安全性和可用性相关的指标

• 得物考核角色：成本中心产品、研发

• 云优化 KPI包括与成本节约、预算履约、生产成本事件、平均修复时间、安全漏洞等相关的指标

• 得物考核角色：技术成本负责人、业务负责人

• 云治理和自动化 KPI包括与财务管理治理、运营治理、安全性和运营治理相关的指标

• 得物考核角色：技术成本运营、财务、采购

参考FinOps基金会考核指标，得物制定了FinOps KPI 类别的一部分跟踪的关键指标。KPI 建立可衡量的基准和指标，以支持监控云资源及其消耗。以下是跟踪的关键指标：

4、总结

得物在实践FinOps近两年后，优化了成本管理，通过成本洞察、治理和运营形成完整的成本管理链路，结合企业文化、流程和工具，实现高效、协同的云资源和成本管理。这帮助得物降低了云成本，提升了单位资源的产出。

未来得物将继续推进成本治理，完成自建paas全量接入、扩大k8s混部范围、服务器基础机型更新迭代、应用多云部署等，通过技术持续提升服务器利用率、摆脱云商绑定及PaaS产品价格约束。成本运营侧，进一步完善预算、资源申请流程，把单位订单/dau成本等效能指标拆分到各部门，加入考核kpi；联合财务进行大宗资源申请业务roi分析，达到FinOps成本治理成熟阶段。​