自从大量的 IT 设施从 IDC 搬到了云上，FinOps 就成了一个炙手可热的词。它的意思一目了然：给 IT 部门里原来负责服务器运维的 Ops 们上点财务手段，Fin+Ops=FinOps。
那这个看上去如此高大上的词，实际是怎么落地的呢？一般包括下面的几个阶段：Inform, Optimize, Operate。
可以看到这是一个很有意思的行事准则，类似于时刻提醒你，咱们得节约用电，离开屋子要关灯，能用低瓦数的不要用高瓦数，能不用电就不用电……对不对呢？很对。有没有用呢？一点用也没有。道理都懂，但是具体问题得具体分析呀，你会为了省电去手洗衣服吗？用牺牲可用性，性能，体验或者资源冗余度（保障的是极端情况下的容灾能力）的方式来降低成本，我忍不住要问：这能叫优化吗？
有没有发现，上面这三步全是假大空的口号，毫无具体的执行细则和可量化的判断依据。一言以蔽之，就是你要持续地观察自己的账单，及时关闭不用的资源，不要用自己用不上的资源。是不是和咱们勤俭的爹妈告诉你的生活之道一样？按照这个准则去执行，你甚至无法衡量自己的 FinOps 的效果如何，你的 FinOps 行为可以打多少分，这简直就是勤俭箴言的云计算版，这要是有用，我相信我们每个人都能成为理想里的自己了。
如果 FinOps 是正确而无用的“箴言”，那我们如何拯救自己的账单呢？
其实答案根本就不远。在过去超过半个世纪的计算机科学发展史里，无数前辈投身于如何避免资源泄露的研究，而这些研究成果没有一个是如 FinOps 一样，仅仅给出爹味十足但毫无用处的“箴言”，而是提供了若干可靠的技术手段。比如， 操作系统会保证当一个进程退出的时候会自动回收其所有资源，垃圾回收技术会自动回收内存等。
云计算通过 API 允许大量使用者同时共享整个云的各种资源，完全类似于在一台巨型超算上的一个操作系统上工作。回想一下各位在单机上编程的经历，有谁是手动按照一个准则去不断申请和释放单机上的各种资源么？显然这些工作都是由程序通过操作系统提供的 API 自主完成的，要么主动释放不用的资源，要么由操作系统来回收资源。那为什么在云这个新的操作系统上就变了呢？
因为现有的程序大都是从 IDC 上“搬运”到云上的，所以我们理所当然地觉得好像应该由 Ops engineer 这个角色去管理云上的虚拟服务器资源。这种惯性支配了云计算的前 10 多年的时间，这也是为什么即使目前最主流的 IaC 技术 terraform，还是由人借助 git 来进行 gitops。如果你认为云是虚拟服务器集群，那你可能会觉得 lgtm。但是如果你把云作为一台巨型超算来理解，你就会意识到即使先进如 terraform，也仍是一种静态资源分配技术。打个比方，就好像你所有的 malloc 和 free 都必须通过由 git 管理的 yaml 配置文件来调用。
虽然基于 k8s 可以进行算力的水平伸缩，但是云上还存在大量的非算力以外的核心组件。根据不同的 workload 和资源的实时价格进行灵活分配，才更像在操作系统上应有的模样。
和一切不切合实际的口号一样，FinOps 迟早会被业界祛魅。而我们的 ClapDB 则是一个真正关心你的账单的数据仓库产品，它与传统数仓最大的不同就是基于前文提到的云优先架构设计，不需要用户进行 FinOps，而是从架构层面实现了真正的“财务管理”，将 finance 与 architecture 结合， 从设计上节约云计算资源，按需分配，用完即弃。
欢迎你来到 FinArch 时代，欢迎你来到云计算新时代。