背景

作者所在的公司是一家专注于养老陪伴机器人研发的公司，业务初期为满足多云部署的需要，核心功能基于云原生架构设计，选用k8s屏蔽公有云之间的差异。随着业务的增长，系统需要应对弹性和开发接耦的需要，系统逐步向服务化方向演进，由于前期部署是基于k8s，服务治理部分也就依然采用k8s作为微服务基础设施。

所谓无devops不微服务，团队初期就采用了建木作为持续集成工具，用于代码的编译，测试，构建、镜像构建等流程，由于建木工具提供了DSL以及图形化拖拽的形式，极大了节约了部署成本。由于项目保密原因，构建流程可参考下图

小插曲，这里肯定同学有疑问，为啥不用jenkins?
1. 建木是国产自主研发的持续集成工具（信创环境下，这点很重要）。
2. 建木采用图形化拖拽的方式构建流水线，相比jenkins更具象，简单易懂。
3. 建木所属社区是第三方中立社区（木兰开源社区），无闭源风险。

采用云原生的架构方式虽然极大了满足了系统的弹性需求，但随着业务的增长，k8s的节点数不断的增加，每个月消耗的费用也逐渐递增，带来的问题是资源的利用率并不平均，尤其是在多云环境下。比如有的节点利用率高，有的利用率低，但是花的钱还是一样多。作者每个月的时候都会去各个云平台核对账单，根据资源的财务汇总情况，分析每个资源利用率，如果某个节点的利用率一直很低那么会适当降配，同时也会看一下有没有额外的其他新增支出，比如一些快照费用或者是没用的磁盘有没有释放，定期不用的ECS快照可以定期删除。

当时我考虑有没有自动化的方式解决这个问题，用工具分析多个云平台的成本用量，然后采用一些机器学习的方式帮我去做优化建议，当一个需求成为全行业痛点的时候，一定会出现一个概念去解决这个痛点，这个概念就是FinOps。

FinOps出场

FinOps 由“Finance”和“DevOps”组成， FinOPS也被称为“云财务管理”、“云财务工程”、“云成本管理”

FinOps 是一种不断发展的云财务管理学科和文化实践，通过帮助工程、财务、技术和业务团队在数据驱动的支出决策上进行协作，使组织能够获得最大的业务价值。

FinOps有一个权威组织FinOps 基金会，FinOps 基金会是Linux 基金会发起的项目，致力于通过最佳实践、教育和标准来推动实践云财务管理学科。

FinOps和DevOps一样, 规定了原则、组织角色，评估模型等，是一系列的方法论的集合。

说白了，FinOps的目的就是使用云的时候尽量帮你省钱。

FinOps 原则

• 团队协作，加强财务与产研团队的协作
• 基于业务的商业价值进行决策，基于单位经济模型或投入产出比进行商业决策，更好平衡成本、质量和效率
• 每个人对云的使用量负责
• FinOps报告及时让每个人可以访问，
• 统一FinOps团队
• 利用云的可变成本模型，拥抱及时的预测、计划和容量采购

什么时候使用FinOps

很多人认为只有企业云费用总额很大的时候才去实践FinOps，当然这种体量的公司基本都是中大型公司级别，我认为只要上云的公司都需要做成本优化，毕竟为公司省一块钱比赚一块钱容易的多，只不过根据不同公司的体量投入的FinOps资源不同，比如对于中小型公司可以使用云厂商提供的优化工具甚至根据简单的报表定期优化即可，对于大型体量的公司，可以投入专门的FinOPS团队来做。

各大云厂商的成本优化工具

云厂商	云原生成本优化工具
AWS	AWS Cost Explorer 、AWS Budgets 、AWS Trusted Advisor 、 AWS Recommendation
Azure	Azure Cost Analysis、Azure Budgets 、Azure Advisor Recommendations
GCP	Billing 、 Pub/Sub 、Compute Engine
阿里云	预算分析、成本管理、成本优化、异常检测

写最后

随着云原生架构的普及，当我们的业务都上云后，紧接着就会面临成本的问题，而FinOps就是解决云原生成本问题的一整套方法论。

FinOps出来后，虽然理念传承自DevOps，但FinOPS关注点在成本优化，而非协作，一个新概念的出现一定是有传承，我们只需要关注新概念的使用范围，不用真的去纠结于概念本身是不是“新概念”。