52家企业，48家要降本：FinOps 能否拯救“下云潮”
“2020 年起，我们走访了很多客户，发现大家云资源的使用其实并不是很好，浪费很严重。”腾讯云 FinOps 产品负责人孟凡杰说道。今年初的一个月，腾讯云原生团队集中走访的 52 家客户中，48 家有降本需诉求，企业不只关心产品新能力，反而对降本能力更感兴趣。
近几年，企业为了迅速发展，上云时很少考虑过成本问题，即使有企业有成本控制的意识，但上云带来的整个预算模式的改变，也让企业在实践中感到无从下手。
传统 IDC 是强管控的模式：企业先做年度预算，然后集中采购硬件设备再放到机房，这个周期很长，而且期间通常不会再增加新的设备。但云计算改变了这种模式：云厂商通常会无限提供云资源，这相当于取消了资源管控。
现在，越来越多的云资源由边缘化团队来购买，每个人都可能发生采购行为，比如工程师做一次自动化扩容可能就会有一次采购。原来传统的集中式采购变成了分布式采购。但这种采购方式很难集中管控，如果缺乏预算管理、配额管理，那么很多人同时采购就会造成浪费。
同时，云上资源的计费模型非常灵活，有的按年或月计费，有的按量计费，可能预付费也可能后付费，最终导致企业的云帐单有成千上万条，甚至可能上十万条。面对这些多账单，财务部门很难核对这些钱的去处，因此也很难做后续的管控。
FinOps 基金会分享过国外某企业的真实案例，开始企业只顾技术创新，积极上云，不顾成本。直到有一天，高层介入喊停：“这个云不能再上了，成本已经远大于收益了！”。该企业因为成本失控导致上云进度延迟两年，严重影响企业技术创新。
2021 年开始，很多企业把成本降低、利用率提升变成了公司关键的 OKR，指导云财务管理的 FinOps 理念便吸引了大家的注意，并开始用这个理念做云成本优化。
FinOps 的历史并不悠久，公有云早期用户 Adobe 和 Intuit 在 2012 年首次描绘出了 FinOps 的雏形。FinOps 本质上是一个理论框架，没有特定的技术栈，其方法论来自各个云厂商最佳实践的整合和抽象，从组织流程、识别浪费、优化措施等方面给出建议。
FinOps 基金会的这张图被引用了很多次，图里简单列出了 FinOps 理论的原则、目标和参与方等。
FinOps 理论的最终目的是要最低的成本来创造最大的价值，但这个理论非常抽象。简单来说，FinOps 理论倡导开发团队、运维团队、业务团队和财务团队彼此合作，数据驱动，构建成本可视化能力，并将成本考核分配给每个团队和项目。FinOps 理论指出了成本优化的三个阶段：成本感知节点关注成本可视化、成本分摊等；成本优化阶段可聚焦目标制定，然后通过费率优化和用量优化来节省成本；运维阶段通过持续优化流程、规范和资源运营手段等实现持续成本优化。FinOps 还有一些成熟度评估模型，来评估企业做得好不好。
孟凡杰表示，FinOps 主要涉及三个方面：第一，财务管理层面，做成本分摊和成本可视化，将云账单上的成本分配到业务单元，并提供可视化能力；第二，经营管理层面，把云资源进行盘活，将采购的云资源的利用率达到最高；第三，制定成本优化措施，平台侧和业务侧的开发运维人员配合做相应的优化动作。
这三个方面牵扯广、执行难，是一个需要拉动企业全员参与的系统工程，因此成功的前提是组织目标的高度对齐，全员经营意识的建立，组织坚定的执行力和不断提升的执行效率，实践的本身就是对组织效率的大练兵。
云原生技术栈跟 FinOps 息息相关，云原生本身对工作负载、业务归属等信息非常清晰，又基于统一的监控、统一的 API，所以面向云原生的 FinOps 很容易定义一些标准化模型和组件。
不过，目前 FinOps 相关的开源项目不是特别多。OpenCost 目前是 CNCF 沙盒项目，开源的部分希望能够在成本模型领域形成统一共识，优化能力收费，背后是商业化公司 Kubecost。腾讯 2021 年开源的 Crane 是 FinOps 基金会首个开源认证方案，不仅定义了成本模型，也定义了全球首个面向云原生应用的碳排放模型，同时提供了面向业务的资源配置优化建议、面向平台的调度优化能力和面向差异化 SLA 业务的混部能力。
FinOps 开源产品 Crane 的架构展示
在孟凡杰看来，开源产品是厂商中立的。“开源产品通常是通用技术，面向的场景很窄的话不会有很多人拥抱这个项目。而开源项目所使用的通用技术，可以支持在腾讯、华为、阿里、AWS 等云原生平台上面运行。”
除了开源，现在更多的是各厂商提供的商业化产品，尤其国外跨厂商提供 FinOps 产品的公司非常多，如 CloudZero、ProsperOps、Harness、Densify 等，生态更加丰富。
孟凡杰介绍道，云商业化产品通常跟自身的内部基础架构息息相关，比如腾讯的商业化产品更多立足于腾讯内部上下产品的全栈打通，追求一个极致的利用率。
孟凡杰举例道，混部场景下的 TencentOS，利用率达到 60%、70% 时，对在线业务的干扰率依然低于 1%，这在开源技术上很难做到。“所以，如果一个企业的资源利用率目标是 30%，开源产品可能是一个可选项。如果企业希望得到极致的利用率，那商业化产品是更优的选择。”
那么，商业化产品会产生厂商锁定问题吗？孟凡杰对此表示，Kubernetes 基于统一 API，天然支持多云，FinOps 商业化产品支持多云也是可以的，由上层调度层抽象 API，并适配每个厂商的内核能力即可。
实际上，各厂商的实践是优先于 FinOps 理论的，是厂商的反馈和抽象形成了 FinOps 理论。拿腾讯来说，其数年前就开始盘整闲置资源加入统一调度平台，通过货币化结算做精细化运营，通过考核方式推动业务资源利用率提高。这些经营手段在 FinOps 系统理论出现之前就已经存在，但在 2021 加入 FinOps 基金会以后，随着对 FinOps 理论的更加深入的理解，腾讯才意识到这与 FinOps 的概念不谋而合，并这些实践经验回馈给社区，进一步丰富 FinOps 理论框架。
现在，虽然像得物、作业帮这样的先行企业有了优秀的实践成果，但总体来看大部分企业还是处在比较早期的阶段，并不知道如何去做这件事情。
《FinOps 云成本优化》（《Cloud FinOps》）一书指出，成功的 FinOps 实践包括三部分：实时报告 + 即时流程 + 团队协作 =FinOps 实践。在孟凡杰看来，在具体实践之前，一项重要工作就是企业必须在战略层面确认成本优化是不是全公司自上而下的共同目标。
根据孟凡杰的经验，有些企业并没有将 FinOps 作为公司自上而下的战略目标去执行，只是某个团队自己去实行，这种情况往往不会成功，因为这个团队没有拉通所有团队来理解和配合，自然也不会有结果，毕竟“业务稳定性高于一切”是无法反驳的真理。
团队协作重要性的本质在于，FinOps 实践更多是一种涉及到各个部门的企业文化重塑：
管理层，常为 CIO、CTO 或事业群负责人，介入制定公司战略目标，确定职责边界，确保公司员工认同理念并愿意配合执行，保证团队的执行效率。
FinOps 专业团队，真正推动整个事情的核心团队，主要职责就是定义原则和最佳实践，制定考核机制，并指导大家怎样实践并达成目标。
面向用户业务的产品负责人或类似角色，对业务中产生的收益和成本负责，确保投入产出比保持在较高水平。
工程运维团队，需要花费很多精力来建设整个支撑系统。比如自动扩缩容该怎样分配成本、怎样识别闲置资源、怎样优化，成本监控体系的建设等等都要技术支撑。因此，无论是面向平台还是业务，都需要工程运维团队的支持。
财务和采购团队。财务团队主要保证财务安全，确保每个业务部门不超支。采购团队统一谈判和采购云资源，借此享受较好的折扣等。
上述目标对齐后，企业需要做文化建设，让大家理解为什么成本这么重要、为什么每个人都要为成本负责。当大家达成共识后，企业要建立面向成本的考核机制，用考核的方式推动和执行。
“在整个流程中，谁来牵头拉通不同的团队、谁定目标、谁推动执行等等都要明确，只有大家配合好，再加上产品能力的支持，这件事情才能做好。”孟凡杰说道，“初创型公司可能业务部门、平台运维可能就是一个团队，这种可以直接闭环搞定。但对于一定规模的企业来说，内部角色划分比较明确，通常需要一系列的机制保证。”
相比传统平台，云原生平台在运行某个工作负载时就会定义该工作负载属于哪个部门的哪个产品下的哪个项目，类似带上了业务属性标签。做数据采集时，企业可以把这些标签一起采集下来形成监控指标，再基于业务属性归类和汇总，这是虚拟机时代没有办法轻易做到的。
但业界一直缺少细粒度的成本可视化。很多云原生平台是混合调度平台，相当于一个账户购买资源，不同的业务共用该资源池。理论上，资源共享意味着高利用率、低成本，但数十或数百个业务共用一个资源池，很难分清楚每个业务用了多少。另外，研发人员在用资源时候也会偏向选择最好规格的资源，买最大规格、性能最好的。但很多时候，真实需求远低于预期。
面向 FinOps 的监控系统会有很多成本指标，包括利用率、申请量等多个维度。
只看利用率层面，FinOps 监控跟传统监控会有一些差异。传统的运维监控通常以稳定性为目标，利用率越低说明系统资源越充足，系统越不会出问题。一旦把成本作为监控目标，监控思路就不一样了：利用率越低，意味着浪费越严重。可以看出，两者的监控目标是完全相反的。
面向成本的监控，不仅看峰值还要看均值，当峰值来临的时候有资源保障，峰值过去能及时把资源退回，这样总体的平均利用率才会提升。所以，均值利用率也是一个重要的考核目标。
FinOps 的指导理论是越及时越好。腾讯内部现在每天上报资源数据、利用率数据和核算数据，第二天就会在绩效看板中呈现各种数据，如利用率、成熟度、核算数据等，每个业务的负责人、平台成熟度负责团队和个人都要为结果负责，促进大家去做实时决策。
孟凡杰坦言，成本确实给了大家非常大的压力，但这样的压力却是必要的。比如系统的一些 Bug 造成资源飙升，如果每天多采购 1000 核，一个月就是 30000 核，造成了很大的浪费。“可能不需要每天盯看板，但需要有监控告警机制及时发现问题，避免长周期浪费。”
当然，频次越高的实时数据意味着建设成本和运营成本越高，所以体量越大的企业，从中获得的收益也会越高。
优化永远没有尽头，企业要找到一个平衡点，判断投入产出比。优化过程中要抓大放小，哪里浪费最严重就从哪里优化。
那么，企业需要优化到什么程度呢？孟凡杰表示，第一是看损益，如果一个业务亏钱就要一直优化，优化到不亏钱为止；第二个是看成熟度，比如成熟度的考核目标是 80 分，那不到 80 分就应该一直优化。当然，一个部门可能有多个业务，部分业务赚钱部分业务亏钱，如果整体损益是正的，也没问题。
在孟凡杰看来，任何企业都应该采用或参考 FinOps，并且在上云的第一天就应该有成本意识，成本控制越早越好。
“云上费用很多是按周期计费的，比如 12 月份和 1 月份去做相同的优化，1 月份做的话相当于前 11 个月都有节省。但拖到 12 月的话，前 11 个月的浪费就真实地发生了。”孟凡杰举例道，“在日常运营中，很多优化措施门槛非常低，不一定要留到某个时间点才去做优化。”
小规模企业由于人数较少，整个文化建设、目标对齐相对比较简单。也没有必要自己建设一套平台能力建设，可以使用 FinOps 能力相关的商业化产品或者开源项目解决。而很多大规模企业通常会自己建一套完整的流程和工具体系，包括考核机制、二次定价的货币化结算机制等，配合云上产品的 FinOps 能力实现成本优化。
当然，FinOps 实践中涉及到的大量的人力和流程成本问题。对此，Gartner 在去年发布的新兴技术趋势中提出了增强型 FinOps 理念，即 AI 驱动决策，AI 根据监控信息判断好坏、预测未来走势，并给出智能化建议。
腾讯有海量的自研业务，CPU 规模达到了 5000 万核，云成本优化总节省 30 亿元。下面，我们看下腾讯内部多年的 FinOps 实践。
FinOps 理念首先在腾讯内部已经从公司层面得到认可，降本增效是自研上云过程中重要的目标之一，并将这个目标给到了每个团队和部门进行考核。
腾讯内部海量自研业务上云过程中同时进行成本优化是全公司的共识，经过高层的充分授权，且设立了专门的运管团队从资源效能管理、目标设定、绩效追踪、进展推动等全面推进成本优化的落实。运管团队充当着 FinOps 专业团队的角色，没有运管团队的规划与推进，FinOps 就是空中楼阁，不可能走向成功。
腾讯内部构建了丰富的成本和利用率绩效看板，每天晾晒绩效，做得好或不好都会及时披露。腾讯内部的成本看板主要包括两个维度：第一个是哪个帐号买了哪些资源，第二个是哪些业务使用了这些资源，包括一些分摊细节。此外，还有面向平台和业务的利用率、成熟度等成熟度指标看板，主要了解资源大盘的整体情况，看投入使用部分用得好不好，同时盘活闲置资源、减少浪费。
平台侧提供的 FinOps 能力从以下几个角度助力业务和平台达成目标：
业务优化。在云控制台上提供了资源优化专项页面，基于业务的资源用量历史进行预测，构建业务资源画像，并给出资源优化建议。
规格建议：通过对比业务资源的申请量和使用量，可以告诉业务可以节省的成本数据，然后业务可以通过系统的控制台直接做优化。
弹性建议：比如某个工作日资源使用非常高，但周末基本没有流量，这时候周末就要缩容，这些业务也可以通过控制台自己优化。
平台优化。云平台在进行业务调度时，提供了众多基于资源画像的调度能力。
调度优化：提出了面向真实利用率的动态调度能力，管理员设定节点目标利用率，只要利用率还未达标，调度器就可以调度更多业务进来。
混部能力：引入差异化 SLA，允许高优在线业务和低优近离线业务混部，压榨每一分算力，同时离线服务可以在发生资源竞争时立即让渡资源需求，实现对在线业务零干扰。
据悉，腾讯内部的在线业务通过调度优化手段把资源利用率拉到 48%，再加上离线混部，部分集群资源利用率可以达到 65% 以上。
资源运营最核心的目标就是降低单位成本，让云平台上的海量自研业务以更低的成本运行。但海量资源场景下的货币化定价与结算也并非易事。业务和地域的匹配度、不同代次的设备怎么支撑不同的业务、采购资源的最优购买、买了资源后如何做更好地售卖等等，这些因素都会影响最终的单价。同时，差异化定价也是牵引业务更高效的利用资源的有效手段。
云厂商下场做 FinOps 产品，部分人持有疑虑，他们觉得这其中的逻辑似乎是冲突的：企业努力省钱，云厂商帮着他们省钱的话，怎么盈利？目前腾讯的做法是在产品溢价与企业节省成本之间，定义一个双赢区间，通过技术赋能，实现企业成本降低、厂商净利提升的双赢。这种方式下，企业通常需要一定的试用期做 PoC，效果好的话才会做大规模生产部署。
这种做法目前在腾讯被验证是行得通的。孟凡杰透露，今年腾讯相关产品附加了 FinOps 能力后呈现了健康快速的增长趋势。
在 Google Trends 上，“FinOps”关键字的搜索量在 2019 年到 2023 年的四年间增长了 410 倍。在国外，有 18000 多人把 FinOps 技能列在了自己的 LinkedIn 简历里。
“我因为担任 CNCF 大使要公开 LinkedIn 资料，在加上了 FinOps 关键字后，一个月里面有十几个猎头问我，‘我这边有 FinOps 的职位，你愿不愿意聊一下？’”孟凡杰开玩笑说道。但可以看出，业界对 FinOps 人才是非常渴求的，孟凡杰感叹道，“有点像 Kubernetes 早期那几年了。”
FinOps 是大趋势，而且正处于快速发展的早期阶段，这也意味着很大的机会。比如很多企业开始实行多云战略，但云厂商提供的 FinOps 产品更多是面向自己的基础架构的，更广泛的跨云支持还没有起步，这给了中立的第三方很大机会。
对于企业来说，早期的实践和转变总会带来阵痛，实践者需要做好这样的心理准备。而 FinOps 未来如何帮助企业把云“用好”，还需要全行业的不懈努力和探索。
这将是一场灾难？37年历史的PostgreSQL数据库将进行重大架构变更
GitHub Copilot：做出一个划时代的产品，只需要 6 个人
⏰面对指数级的业务增长，滴滴出行的业务架构与工程架构经历了怎样的优化与调整？6 月 27 日 19:30，InfoQ 视频号邀请了滴滴出行专家工程师吴俊、滴滴出行高级专家工程师魏静武两位老师，分享滴滴网约车业务在不同时期遇到的挑战，以及技术团队为应对这些挑战，在业务架构和工程架构上的思考与实践。如果你也想了解滴滴出行在如此快速的发展过程中，如何解决上述问题，欢迎点击【阅读原文】或扫码预约直播！
👆 添加小助手，领取 AIGC 资料包 👆
微信扫码关注该文公众号作者