基础概念

什么是 FinOps，为什么企业需要 FinOps？

FinOps（Financial Operations）是一种云财务管理实践，旨在帮助企业优化其云计算支出，同时提高业务敏捷性和创新能力。随着云服务的普及，企业在云上的支出日益增长，而 FinOps 通过跨部门协作（如财务、技术和业务团队）来管理和优化这些支出。

FinOps 的核心目标包括：

可见性：提供对云支出的透明度，让不同团队了解自己的使用情况和成本。
优化：通过技术、财务和流程上的改进来减少不必要的支出，提高成本效益。
协作：财务团队和技术团队共同制定和实施成本管理策略。

FinOps 的关键原则：

团队所有权：每个团队对自己的云使用和成本负责。
速度与成本平衡：在控制成本的同时，不牺牲业务的速度和创新。
持续改进：随着云环境和需求的变化，持续优化和调整支出。

FinOps结合了技术和财务的最佳实践，使组织能够更好地预测、控制和优化其云资源的使用。

如何自动化的落地 FinOps?

有原则并不能保证 FinOps 的落地。FinOps 是一个持续性的工作，特别是基于我司用云范式的复杂度，没有工具只靠各个云的管控平台，已无法保障。

FinOps 实战经验

1.云服务器成本

1.1 使用 Spot 实例节省 50～90% 成本

对于开发测试非稳定性要求的需求，建议使用 Spot 实例节省云服务器成本。

其中，GCP 的 spot 实例可以只停止不删除，特别推荐使用。（AWS 的 spot 实例当被平台回收时，实例绑定的系统盘也会一并被回收，如果盘上有数据，将无法找回）

GCP spot 实例成本是 standard 的 1/3。

1.2 长驻需求的云服务器使用预留实例

预留实例选用的技巧：

相关变量：1. 是否预付费；2. 是否可变；3. 周期（Term）；4. 范围（Scope）

说明：

是否预付费： 选预付费就是提前把钱支付掉；如果选用不预付费的方式结算，月底和供应商拉账单月结；预付费的价格会更低；
是否可变：可变是指在预定周期内，可以变化实例类型。不可变的叫标准模式（Standard）。
周期（Term）：预定的时长，一般有 1 年和 3 年；3 年便宜很多。
范围（Scope）: Region 和 Zone，Zone 的一般更便宜。
如果确定性强的需求，可以选用：预付费 + 不可变 +3 年，这样成本是最低的。

1.3 在相互不干扰的情况下，尽可能合用资源
1.4 使用定时任务，配置 VM，晚上不用时自动关机，早上使用时自动开机，节省费用

使用定时任务，也可以设置周末定时停机。

1.5 暂时不用的实例，打成机器镜像

当实例暂时不用的时间超过 1 周或者当实例的块存储的费用比较高时，相比于仅停机，打成机器镜像然后删除实例，可以节省块存储费用。需要的时候，用机器镜像恢复就可以了。

1.6 节省停机模式

阿里云的停机方式有两种，普通停机模式，成本还是一样在扣减的，建议当云服务器暂时不用时，选用节省停机模式。

节省停机模式介绍:

节省停机模式下，计算资源（vCPU 和内存）、固定公网 IP 和带宽不再收费。
仍旧收费的资源有：系统盘、数据盘、弹性公网 IP 和带宽（固定带宽模式）、收费镜像。

1.7 可用区也会影响成本

选可用区的小技巧：三短一长选长的，三长一短选短的；两长两短选择 B，长短不齐就选 BC。有一种“民间偏方”叫做选 C。

这个小技巧，特别对于使用 spot 的实例的时候效果明显。在 2 年的 AWS，GCP 等云的 Spot 实例回收概率分析后，A 可用区的回收概率远远高于 B,C 和之后的其他可用区。

因此，想要省钱，可用区的选择也是有讲究的哦。

1.8 Spot 实例的回收消息里的宝藏

Spot 实例的回收是一个概率事件，通过分析不同实例类型、不同可用区的回收概率，可以优化调整 Spot 的部署，就可能用 10% 的成本（Spot）来达成需求的同时有很高的稳定性。

2. 公网IP成本

目前几乎所有云的公网IP都已经单独计费，因此，对于可以不用公网访问的情况，不配置公网IP。减少公网 IP 使用的另一个好处是，减少被公网恶意流量攻击的可能。
SLB的成本更是让人咋舌！！！

3. 流量成本

3.1 AWS 在同一个 region 内，不同 az 的 EC2 之间的网络流量，等同于跨 region，也是需要同样的流量成本

真实案例：某公司项目组因为不了解该信息，多 AZ 的 EC2 之间几天跑出了 7 万多的流量成本。

3.2 流量尽量走内部，公网流量很贵

比如：阿里云 ECS 读写 OSS，一个 1TB 的 bucket，如果走公网 endpoint，流量 0.25 元 /GB，读完这个 bucket，250 块就没了（数字举例纯属精确且巧合）。

4. 对象存储成本

4.1 S3: 如何正确删除一个 S3 bucket，当文件数量大到无法手工清理的时候

我们经常会遇到测完 S3 后面要删数据，bucket 删除前会提示先删除里面的数据，当文件数量大到无法手工清理的时候，怎么办？

这么多大文件，需要用 lifecycle 来删除，不要直接 delete，不然删除也会产生较大的流量费用。

s3api put-bucket-lifecycle --bucket %s --lifecycle-configuration '{
"Rules": [
    {
        "ID": "delete-all",
        "Status": "Enabled",
        "Prefix": "",
        "Expiration": {
            "Days": 1
        }
    }
  ]
}'

4.2 阿里云 OSS：用 ZRS 会比 LRS 贵 25%，开发测试没有特殊需求的话，建议用 LRS
4.3 定时清理不再使用的bucket

按量计费的对象存储，随着时间的累计，也是一笔不小的费用。应该定时清理不再使用的 bucket。

不清理出了存储本身的成本，更危险的是：公有云上的黑暗森林法则出现了：只要你的 S3 对象存储桶名暴露，任何人都有能力刷爆你的云账单。

https://medium.com/@maciej.pocwierz/how-an-empty-s3-bucket-can-make-your-aws-bill-explode-934a383cb8b1

5.CDN成本

控制带宽:通过设置带宽上限，来控制带宽用量
限制下行速率:通过配置单请求限速，对用户访问到CDN节点的所有请求进行下行速率限速，以此来压制加速域名的全网带宽峰值
参考链接:https://help.aliyun.com/zh/cdn/use-cases/best-practices-for-preventing-traffic-theft

6. 块存储成本

6.1 停止的实例，可以把块存储转成快照节省成本
6.2 阿里云块存储的选用：performance_level PL1 要比 PL0 贵一倍

阿里云 ACK 默认的 essd 的 SC 会选用 PL1，一般非性能测试需求的开发测试，PL0 的性能已经足够用了。阿里云 ACK 可以新配置一个 essd 的 SC，加上 performanceLevel: PL0 的参数。

7. GPU 成本

待更新

8. 快照成本

8.1 快照存档

当快照需要长期保存（>90 days），将快照进行归档可以节省 75% 的成本，参考： https://docs.aws.amazon.com/ebs/latest/userguide/snapshot-archive.html

9. 日志成本

9.1 关闭不需要的日志生成

比如 eks, gke 等云托管的 k8s 都会默认生成日志；云上的日志系统，无论是 AWS 的 cloudwatch，还是 GCP 的 logs storage，日志一开，费用就刷刷去了。比如某公司项目 gke 因为大量刷 error log 产生了 10 个 T 的日志，消耗了 6,877.65 美金。

9.2 缩短日志存储周期

日志的每 GB 存储费用远高于对象存储。因此尽可能减短 Retention period，以 GCP log storage 为例，最短可以配置成 1 天。

10. 容器服务成本

10.1 阿里云容器服务，可以选用ack资源包，每个包节省45.8元(每月按30天算) 费用参考链接:https://help.aliyun.com/zh/ack/ack-managed-and-ack-dedicated/product-overview/cluster-management-fee

11. 商务谈判

及时跟进各大共有的商务，有打折的产品+大客户折扣，完全可以享受折上折优惠

12. 自建机房

上云的终点：下云尽管私有云的机器部署要比公有云更为繁琐，但拥有自己的数据中心和私有云是一项长期的投资决策，可以降低每年的云服务费用。

FinOps最佳实践篇-管理篇

接下来将从两个方面介绍在降本增效过程中成功的方法论,以及落地的实践的方案。

首先从管理看实施FinOps可行的有效的管理方式 管理上主要是把FinOps的管理理念让使用云计算的公司领导层以及周边团队认可,因为云计算本身发生的巨大变化，只有管理才能够把成本管理好，这是它的核心挑战,在服务客户时，发现两个组织协作模式比较有效，第一种是中央集中的管理模式,这种游戏公司用的比较多,他的核心是业务团队，只负责开发业务。中央IT团队是负责运维安全、FinOps相关的所有都在中央IT团队，这个团队对应的权责是非常大的，他负责所有的产品成型之后的所有运营运维。这种适合业务稳定型的企业，包括产品比较单一的，比如适合游戏行业，另外是追求财务的流程标准化和规范化的企业，就是对财务合规、财务标准比较追求极致的企业。目前阿里巴巴集团是用中心辐射管理模式，它的核心就是FinOps的中心管理团队，它主要的职责是制定政策，做相关的优化工具，以及推动有效的方法。这个团队研究出来方法之后发现可优化的点，根据这些工具和方法做任务分发，任务分发到业务团队,中心团队是不做具体的治理任务的，更多的治理任务是下发给业务团队，有业务团队的运维和FinOps相关领域的角色执行落地,中心运营团队主要是运营的职责比较大，这个团队的压力也会比较大，因为需要他有很强的协调能力以及价值宣导能力证明FinOps今天做的好与不好，以及每个业务团队红黑榜机制都要run起来。这是模式的一个好的地方和不好的地方，它适用的企业主要就是复杂组织结构的，因为有很多企业的组织结构比较复杂，并且多元化的企业比较适合中心辐射管理模式，因为针对多元化产品的企业,通过中央集中管理模式对中央IT团队的要求是极高的，所以它比较适合中央辐射管理模式，另外就是创新与标准化并重的企业。建议都是用中心辐射管理模式，因为它毕竟比较灵活并且不会抑制创新，这是常见的FinOps组织的协作模式。实施FinOps的过程里面，正常的运营逻辑和实施方式，包括三部曲，首先建降成本，第二建体系，第三讲价值，
首先要让大家看到管理是有效的，通过常年的积累，有很多资源是闲置或计费方式，是可以优化的，按照二八原则，很快就可以找到很多优化的资源，把它换算成年化价值跟领导汇报，汇报完之后告诉领导。如果不优化,结果是每年会有很多浪费，它是一年一年滚动且会增加的。今天由于做这件事情，比如十年将减少多少浪费，这是降成本，看到效果后，接下来是建平台，要用一个平台把降成本的方式全部沉淀到平台，平台建上后，它就可以自动分发治理，有了平台之后再讲价值，这就是有事实依据和未来，实施FinOps的三部曲首先降成本，成本、质量、速度完整的正三角是不可能的，但是这是做成本管理追求的极致，因为所有的业务在不同的发展阶段，它的要求是不同的。比如说在刚开始起步的阶段，是追求的质量和速度，要先抢占市场，这时候成本是可以忽略不计的，可以不计成本抢占市场,等业务稳定，市场占有之后，所有的成本才会被逐步的拉出来，慢慢的形成一个正规的三角形,所以做成本优化的时候不要一下就想把三者平衡掉，因为难度是极高的，所以建议要顺应业务的发展。降成本首先建议先降运营成本，因为运营成本对业务是没有任何影响的，主要是通过比如测试环境，把它所有的测试环境的资源把标记出来，标记出来之后，可能有一些测试环境是非常高配的就可以先降配，这种也不影响资源。另外优化购买方式，比如原来可能按量付费用的比较多，本来按量付费就比较贵。可以用一些节省计划,比如包年包月把按量付费替换掉，它本质上的资源是不受任何的影响的，对于业务也不会产生影响。释放闲置资源，生产环境利用率提高，这些都是运营上的降本的方式和方法，这些初见成效之后就可以推动技术降本。比如工作负载的调度降本，包括要用一些容器化产品重构代码，重构运维平台，这就是一些技术降本的手段，这是在降成本的一些方式和方法，针对建平台，在服务客户的过程发现有的客户可能就一个团队，忽然做成本优化，做完之后效果就很明显，开始要整个公司降成本，可能在短期战役的收效非常高。收效之后，这个战役战报就结束了。可能一年之后，因为人员在流动，所有的系统业务都在发展，发现成本又上去了，这就是因为没有平台沉淀降成本的方式和方法导致的问题，所以要建平台，主要是数据驱动的平台，不一定要把平台写的很复杂，另外所有的过程都是先止血后治理，因为所有的业务在治理的时候难度都比止血很大,因为业务在跑，要治理是很难的，但是止血是容易的，所以在流程上建议方式是先止血后治理，治理的时候一定要责任划分，因为只有责任划分到具体的人，这个人才会推动这件事情继续往前，这个是在流程治理上，另外就是可以组织经常性的分享。分享治理方法到同公司的其他团队一些启发，这些启发就可以形成逐渐的把分FinOps的文化推广起来，从原来是FinOps中心化的团队推动着业务团队。促使团队有自我的意识把成本管理好，这是FinOps价值宣导里面希望做到的核心，这是建平台。另外建平台有两种模式，第一种就是建看板，它是在服务客户里面是比较常见的一种方式，因为一般情况下建看板就够，云计算厂商基本上提供比较多的工具，把数据吐给大家，大家基于数据建一定的看板，建完看板，只要能够发现问题，这些看板的自动循环就可以做起来，还有一些超大型的企业，他们是建平台的，因为阿里巴巴内部也是建平台的，原因就是平台原来就是有一套运维管理系统，这套运维管理系统上云之后，所有的都要和这套运维管理系统要兼容协同，协同的时候它需要本身有一个平台把数据接回去，有一部分工作量是必须要付出的，否则原有的运维流程都要改变，建平台一定要考虑投入产出比的问题，要看是否有比较大的团队，因为阿里巴巴集团大概是有大几百人的团队做整体的运维管理体系，云计算相关的成本管理平台大概都有几十人，所以评估ROI是否合理,以上就是从管理方面在实际服务客户的过程中的方式和方法。

FinOps最佳时间篇-技术篇

从实践方式和实践技术上看，现在面临五大问题，针对五大问题讲阿里云提供的工具：

第一是减少浪费和未使用的资源，阿里云上是有很多的工具的，一个是配置审计，另一个是智能水位分析，配置审计的核心是找出闲置的资源进行优化，减少浪费,比如一些未绑定的IPEIP，包括闲置的ECS和未挂载的磁盘，这些都是可以优化的点，只要找到对应的资源拥有者就可以优化。

第二是智能水位分析，它可以发现一些低负载的资源，根据负载的情况，可以找到低负载的资源，从而找到对应的业务团队进行优化，这是关于减少浪费提供的两个工具，官网有很多工具可以做资源减少浪费的发现。

第三个是基于承诺消费获取低折扣，因为阿里云已经提供相当丰富的售卖模式，节省计划的优化订阅，它主要是基于按量付费的场景，因为原有的按量付费。但是如果使用按量付费，它有比较稳定的使用，可能只是白天和晚上会有一些弹性，比如白天整个是要谈到每个小时消费一百，晚上可能谈到每个小时消费十块钱，这时候就可以选择节省计划，每个小时承诺十块钱，拿到比按量付费要低的折扣。针对这个提供智能化、自动化的优化方案，方式优化，建议在成本优化里面，费用与成本管理的成本优化里面提供工具，在这个里面可以直接点击立即优化，就可以看到优化后的效果，如果所有的资源是有按部门的，可能某些部门是需要优化，其他的部门不要优化的情况，也提供个性化的节省计划的测算能力，可以按照个性化的方式测算。针对第三个整体的挑战问题，就是准确的预测支出，上云之后支出变得不可控，阿里云在上云前和用云中，提供多种的预测方式。首先在上云前提供TCO计算器，只要输入IDC相关的配置，就可以自动计算出在IDC期间所有的每年的消费情况，以及上云之后应该对应的配置，这个配置对应的金额情况、消费情况都会表达出来，整个测算方式提供三种。第二个是在用云中成本分析工具，可以帮大家预测未来12个月的消费，比如有些公司要做预算，其实是要做明年12个月的预算，可以通过成本分析工具预测的数据，直接把它下载下来做微调，可能就可以成为明年的预算，这是关于用云中提供的一些工具，另外还提供预算监控的工具以及异常检测,预算监控是企业每年都会做预算，它的预算一般是按月去滚动的，可以把这个预算配到预算管理模块，再配到系统中面。配到系统后，可以配预警值，当每月的预算和实际资源的消耗发生变化时，会有预警给到相关的人员，这个预警和成本分析都是打通的，可以一键成本分析看成本到底是哪个业务部门发生的，另外一个就是异常检测，有一个智能化的算法，可以根据历史消费情况去预测未来的消费区间，当实际的消费和预测的消费期间不匹配的时候，即为异常，这个异常就可以帮助运维同学关注到底在使用过程中有哪些异常，就可以去做相关的治理。

第四个问题就是成本分摊，成本分摊有两个核心的要点，一个就是账单，如何把消费账单分到业务部门,第二个就是如何把消费和资源的使用要匹配起来，也就是运维的成本，阿里云针对独享资源，提供按业务单元拆分，首先就是运维针对资源可以打标，财务人员基于标签可以做财务单元，系统就可以把业务部门的分账分出来。第二个就是共享资源的公摊处理，有一些网络安全基建的费用，它是作为财务单元的公摊。阿里云提供三种方式，一种是自定义，第二种是平均，第三种是按照资独享资源的业务消费比例分摊，把账整个分到部门对应的账单里面，就可以把分账再拆到实际的消耗维度，比如包年包月和资源包就可以拆到实际的资源消耗上，资源消耗之后，这个运维就可以观测整个资源的成本消耗和波动情况，这是关于成本分摊提供的一些能力。

最后是自动化监控和运营，提供两种方式，一种是开箱即用的成本分析，另一种是高阶的自主分析。开箱即用的成本分析是预制在费用以及成本管理功能中的成本分析功能，它主要支持多个类型，一个是分账单的分析以及摊销成本的分析。它支持报告的下载以及分析的结果下载。如果阿里云提供的分析视角可能不注意完成业务的视角分析，可以用Max Computer+Quick BI的高级自助分析工具分析，现在在费用中心的成本分析中可以自助开通，开通后，阿里云会把账单自动投递到Max Computer中，这样就可以借助Quick BI工具，分析出想要的视角，下面的图是给客户做的通过QuickBI的分析视角图。

FinOps产品推荐

云联壹云

「真诚赞赏，手留余香」

FinOps最佳实践