如何体系化地做FinOps：关于做成本优化专项的思考(第二次更新)

概述：FinOps概念在国外大火，各家云厂商官网上也都推出FinOps的一些方法论，但笔者读来都感觉太散，云厂商们推出的方案都聚焦到一个点上，最终落脚点都是在推自家产品，而对FinOps缺乏体系化的总结（了解笔者的你懂得，我做事就是喜欢抽象化、体系化、逻辑化）。本文尝试对市面上的一些方法论做出可落地、有逻辑可循的总结，当我们在公司内部想要发起一个FinOps专项，我希望我的方法论总结能给读者带来一些输入。但本身这个概念很大，笔者也只能边看边学，后续会做一些持续更新，希望能给读者带来更多地思考。

结合《FinOps成本优化》和各家云厂商的方法论（云厂商的方案建议去阅读AWS Well Architect，AWS作为全球最大云厂商，在FinOps领域走的是比较前面的），我认为FinOps的治理可以抽象总结为一个公式、三个阶段、六个抓手：

• 一个公式：云支出 = 用量 * 费率
• 三个阶段：可视化 可优化 可规划
• who where what when how why

接下来逐个介绍，但这三个点之间是有相互关系的，后面的内容也会穿插着讲。

1. 一个公式

云支出 = 用量 * 费率

1.1 云支出

云支出最终体现是一张账单，但是我们要对账单做细化，细化的结果是我们要看到哪个account id、在哪个region、用了哪个服务、用了多少时间、用了多少钱。云支出是可视化的基础，在可视化阶段第一步我们需要先把云支出细化。

1.2 用量

用量是指具体的服务所使用的时间。这里要注意我们关注的具体的服务，而不是资源（计算、存储、网络），差别在于云厂商对每个服务都是明确定价的，而服务之间可能会有资源上的交集，比如用ec2和rds，都会用到存储。

关于用量我们要关注怎么用？这个变量可以根据每个产品具体展开，例如：

usage-ec2 = ec2-instance + ec2-datatransfer +EBS + IP

其中instance包含不同的实例类型和资源大小，不同实例类型价格也不一样；EBS不同的选型价格也不一样，性能也不一样，比如gp2、gp3（自带3000 iops）。

那么当我们要做成本优化时，关于用量这个变量，能做的有两个方向：产品选型、架构优化、资源优化。

产品选型需要根据业务场景，并做一些基线测试，然后通过长期监控观测，得出最佳产品。

架构优化方向可以考虑数据的传输方式、根据业务SLA优化双活/standby机制/灾备等方案。例如，应用之间不必要的跨AZ调用是否会增加多余的流量？我们在设计双活的时候，可以流量优先走到同AZ，AZ不可用时再走到另一个AZ；standby闲置时是否需要保留和active一直的资源？假设实例的CPU跑到70%足以应付日常流量，那么standy保留40%的CPU就足够了，不放心可以再配置上auto-scaling紧急扩容。

资源优化是从技术角度上，第一是看应用的资源合不合理，可以从os层和应用层出发，比如通过优化cpu、内存利用率；优化JVM内存比例、垃圾回收机制。这里涉及到系统调优，比如CPU姻亲绑定、内存大页设置等等；也有一些开源的方案，比如k8s里的驱逐、亲和、容忍，这些都是调节资源的方案。这个里面就有很多内容可以讲了，遂不再本文赘述，后续我在另外章节中会介绍。

1.3 费率

费率的定义是每小时对某产品使用的费用，单位是￥/ hour。注意一定是每小时，不是每月、也不是每年。小时是绝大部分云厂商/云产品最小的使用时间，尽管有些云厂商有包年包月、saving plans等购买方案，我们还是需要转换为每小时。转换为每小时也是可视化的一部分，同时统一的费率单位也是跟业务方讲清楚价值的体现。

费率跟购买方式有关，购买方式我了解到的基本包含如下：按需（on-demand）、包月（华为就有包月的购买方式）、包年（AWS叫RI，预留实例，也分一年期和三年期）、商务折扣（各有各的叫法，AWS叫EDP。商务侧会对一些大客户在目前购买方式上再打个折扣）、承诺用量（通过承诺用量去换取更多的折扣，比如承诺每年用一千万，那么可以拿到更多的折扣）。

费率这块不仅仅是商务和财务需要关注的，技术侧需要根据当前的架构、用法、规划，选出最优的购买选项，从而进一步节省费用。

例如，我的某个应用因为监管合规性，要定期做跨region备份，但备份的数据我基本都不会看，那么可以把备份数据存到S3-ice层，甚至可以通过专线传输来节省费用。

2. 三个阶段

2.1 可视化

既然可视化要实现的是哪个account id、在哪个region、用了哪个服务、用了多少时间、用了多少钱，那么主要依赖于成本分摊，实现成本分摊的方式是对资源进行精细化打标。这和六个落地点里的who是一个意思，我们通过打标分离出account、个人、团队、部门、亦或是应用在云上的费用和具体某个云服务的用量。

同时将支出、用量做图形化展示，这点可借助云厂商的工具，比如AWS提供的cost explorer。

2.2 可优化

可优化主要聚焦于我们做成本优化的方案。这和六个落地点中的how是一个意思。根据公式，可通过对两个变量的控制而达到成本优化。具体又可将变量展开，比如上文提到的用量，展到很细，再从架构、选型、资源上进行优化。

2.3 可规划

可规划是基于前两个阶段已经成型，长期通过数据运营，向业务方传递云价值，并在业务初期就对云成本和云资源进行动态规划，通过以上方法不断动态调整，以得到最佳的规划设计。

传统的业务部门（商务和财务），只看到成本。而技术部门（运维和研发）是离资源最近的人。如何打通成本和业务呢？可通过以下公式来：

例如，我们在规划阶段，根据以往的使用情况，展示出ec2使用的小时数、业务十字星指标、成本，那么就能告知业务方：我花了那么多钱，用了这么多资源，创造了这么多价值。更进一步，理论上三条线的增长比例应该是一直的，如果资源或者成本突增，那么背后的原因我们需要找出来。

3. 六个落地点

做云成本优化，本质就是要搞清楚：谁（account、团队、应用）在哪（多云环境）做了什么（服务分解）、怎么做的（云服务如何使用）、何时做的（云服务本质是购买时间而非产品）、为什么这么做（找出用量、费用、业务变化的驱动因素）

who：

根据业务需求，找出云支出和用量的真正使用者，通过标签对云服务打标，分离出account、个人、团队、部门、亦或是应用在云上的费用和具体某个云服务的用量。绘制长期趋势供分析。【可视化】【可规划】

where：

大部分企业采用多云政策，阿里云、腾讯云、华为云上多云部署，因云厂商之间服务费用不一样、产品类型不一样，账单需要拆分来看。【可视化】

what：

云服务拆解，大类可分为计算、存储、网络流量、数据传输。分析服务费用占比，确定优化方向。【可视化】【可优化】

when：

上云究竟买的是什么？不是云服务本身，而是对云服务使用的时间，这点很重要。所以我们的计费逻辑应该从时间出发，规划方案也用从时间上考虑，选出低风险和高回报的规划方案。【可优化】

• 高回报：费率差最高的购买选项。比如按需是10￥/h, 包月是8￥/h, 包年是5￥/h, 包三年是3￥/h, 承诺用量折上折。那么包三年+承诺用量就是最高回报。
• 低风险：在购买选项中，购买成本差最高的两个选项*12，表示几个月的时间可以追回成本。

why：

费用/用量增减或者异常的驱动因素【可视化】【可规划】

费用/用量增加或者减少，应该和业务指标挂钩，以业务十字星指标趋势，和云费用/用量走势结合来看，去证明云是创造价值而非成本中心。

同时云上费用的异常波动，找到其背后的原因，提前规避。

how：

优化方案，按照公式来，云支付 = 用量 * 费率。那么目标只有两类方案：减用量和减费率。

砍用量：寻找低价、成本优化的云产品，或者云架构替代。

减用量：架构、产品、os、中间件、应用上采取优化措施。

减费率：选择最优购买选项。