我对 FinOps 的思考
转载原文链接：我对FinOps落地的思考
一、背景
1.1 为什么出发
如何做降本增效是管理基础设施的团队要关心的课题之一，也是对团队有挑战的事情，更是我们为公司、为业务创造价值的要事。如今业内各大云商、互联网头部厂商都在努力的做这个事情，但是如何做好，确实我们一直在思考、一直在努力的路上。为什么我们要做成本优化，其本质原因是整体资源必然存在着浪费，有一定的压缩空间。为了让基础设施稳定运行，我们一般都会在业务上线的时候留足够的冗余资源，以免有业务突发或者故障发生的时候能够有资源可以替换。无可厚非，我们预留的资源空间越大，那么基础设施能够在面对危机情况下越稳定，做运维的同学也越放心。在费用和技术、人力面前，大家都选择了简单的前者，久而久之，资源就存在严重的浪费。
1.2 第一性原理
我觉得降本这个事情的第一性原理是：最大化地挑战基础设施的稳定性，也就是说在保证业务稳定的大前提下，让基础设施的资源使用最大化。一边是业务稳定，一边是压缩基础设施资源，这本身就是一个矛盾体，也是做好这个事情最大的挑战。稳定，我们投入更多的资源就行了，那么就会存在浪费，然后我们要减少资源，这样就在这无休止的增加、减少、再增加无限循环下去。如何选择、成为了基础设施团队头疼的问题。比如各个企业在做容灾系统的选型上，就是一个在稳定性和成本之间的抉择，毕竟不同的容灾方案对应的成本还是有很大差距的，所处的阶段不同，考虑也会不同。
1.3 临界点
那我们如何去平衡稳定和成本之间的关系呢，首先要去找这个临界点，也就是我说的要把资源使用最大化。过了这个临界点，业务就不稳定了，稍微低于这个临界点，资源使用最大化了，那这个点就是我们想要的结果。问题来了，如何找到这个临界点，这个是非常难的。跟你的业务形态有关，跟你团队整体能力有关，跟你使用的技术栈有关，另外在线和离线的资源不一样，离线和中间件的资源不一样，中间件和存储的资源不一样。各种复杂的因素都掺杂在一起，让我们对这个事情感到无助。
1.4 要常态化
为什么要常态化
在成本治理的初期，我们一直在思考如何降本，一直在做，一直在探索，每个阶段做完之后，可能停留一个季度不做有些地方使用又开始明显不合理了，那么就这样反复在治理，可能资源从一开始创建就缺乏合理性。我们一直在 Plan、DO，是不是缺少 Check、Action，也是值得我们去反思的。
这是一个本身就很复杂的工程，是由本身软件系统越来越复杂决定的。如果你想得到一个好的效果，这种治理本身就是一个长期要做的事情。
现状：
反复立项：投入人力反复盘点，治理完之后，过一段时间一些资源又回到老样子。
业务配合：需要业务方投入不少的时间配合，填写信息，改造应用，迁移等等。
资源类型多：在线资源、离线资源、中间件资源、数据库资源、网络存储资源等，管理难度大。
苦力活：运维人员基本手动治理，很多数据、报表要一点点统计、汇总、分析。
解决问题机制：一直都是出现问题、解决问题，不能够前置治理，让资源从一开始创建就具有合理性。
满意度：整体只能达到 70 分，很多资源仍然有压缩的空间，因为技术原因，还可能导致服务不稳定。
我们美好的期望：
资源从创建那一刻就是合理的，使用率无限接近临界点。
自动化发现使用不合理的地方，发现一例治理一例，把成本浪费减到最小化，人员投入成本也最小化。
无需业务花时间配合，或者只需要花很少的时间。
各团队能够实时地查看自己所使用资源的情况、费用，做到心中有数。
二、何谓 FinOps
这一章节我主要是对官方的一些内容做了下简单总结，目的为了让大家更进一步的理解 FinOps 的思想、理念，大家如果对 FinOps 体系本身比较了解可以选择跳过。
2.1 FinOps 简介
FinOps 基金会成立于 2020 年 8 月，先来看一下 FinOps 基金会对 FinOps 的定义：
FinOps is an evolving cloud financial management discipline and cultural practice that enables organizations to get maximum business value by helping engineering, finance, technology and business teams to collaborate on data-driven spending decisions.FinOps is a portmanteau of “Finance” and “DevOps” stressing the communications and collaboration business and engineering teams.
FinOps 是一个不断发展的云财务管理学科和文化实践，通过帮助工程、财务、技术和业务团队在数据驱动的支出决策上进行协作，使组织获得最大的业务价值。FinOps 是“Finance”和“DevOps”的合成词，强调业务和工程团队的沟通和协作。
FinOps 是将 DevOps、财务和业务整合在一起的变革，其目标在于优化一个组织在云计算上的支出的财务规范和技术解决方案，即根据支出的历史记录和来自预期负载的信息，FinOps 可以在需要时预分配资源或估算成本。FinOps 可以称为“财务运营” ，或者更直白地称为“成本优化”，是将财务问责制引入云的 IT 支持，进行调整以优化质量和支出。
云的支出规则其实很简单，付你所需。但是问题在于首先要清楚你需要什么？一支优秀的 FinOps 团队首先就是要通过多云平台全面了解云资源的成本分布以实现成本控制，将钱花在真正需要的地方并重新分配资源。通过实时数据和统计信息，FinOps 团队可以估算未来需求，并根据在云资源成本上的支出做出及时的决策，进而预分配资源或进行折扣商定。只有通过财务、业务、IT、运营支撑的整合与合作，才能确保预算更加准确，实现成本优化，避免资金浪费。所以说，FinOps 是一个文化上的转变，需要建立新流程和新组织来达到成本管理的目标。
为了节约成本，企业必须首先识别浪费，发现未使用或未充分利用的资源、利用最低价格区域和实例类型、关闭不需要运行 24x7 的资源、利用折扣选项。依托 FinOps 思维洞察云上每一分开销，对上云成本进行智能预测与优化，帮助企业节约上云成本。
2.2 如何开始 FinOps
第一阶段：组织、规划
获取领导、各团队的理解和支持。
确定目标、方向、组建团队，确定用于衡量 FinOps 功能的 kpi，以及衡量业务部门和应用团队的参与度和绩效的方法。
第二阶段：宣传、推广
与已确定的受影响团队进行 FinOps 对话，如财务、技术团队、产品团队，介绍 FinOps，为什么要做这个事情，带来的业务价值是什么，推动成本优化意识。
制定 FinOps 模型。
第三阶段：为 FinOps 落地做准备
定义标签、元数据和治理范围。
定义各资源使用标准和告警阈值。
制定长期治理标准、规范。
2.3 组织人员
FinOps Practitioner
FinOps 从业者通过近乎实时的基于数据的决策，为业务、IT 和财务团队搭建桥梁，帮助优化云使用和增加业务价值。他们重视建立 FinOps 文化，并通过 FinOps 的原则和自身的能力来支持合作的团队。
Executives
执行人员，如副总裁/基础设施主管、CTO 或 CIO，专注于推动责任划分和构建透明度，确保团队高效执行，不超出预算。
Business/Product Owner
这些参与者通常是业务和产品负责人团队成员。
Engineering and Operations
工程师和运维团队成员，如首席软件工程师、首席系统工程师、云架构师、服务交付经理、工程经理或平台工程总监，专注于为组织构建和支持服务。成本作为指标引入，其方式与跟踪和监视其他性能指标相同。这些团队的成员通过调整云资源的大小(调整云资源的大小以更好地匹配工作负载需求的过程)、分配容器成本、发现未使用的存储和计算，以及确定是否会出现支出异常等来考虑资源的高效设计和使用。
Finance/Procurement
财务和采购团队成员，包括技术采购经理、财务规划和分析师经理以及财务业务顾问，使用 FinOps 团队提供的报告进行会计和预测。他们与 FinOps 实践者密切合作，了解历史账单数据，以便建立越来越准确的成本模型。他们利用 FinOps 团队的预测和专业知识与云服务提供商进行费率谈判。当提出在组织内采用 FinOps 时，需要在执行团队中向不同的角色进行简要介绍，以获得批准、认可和参与实施 FinOps 并实现其目标。
2.4 团队的责任和期望(RACI / DACI 建模)
RACI (Responsible, Accountable, Consulted, Informed) and DACI (Driver, Approver, Contributor, Informed)设定期望并管理不同团队和角色的责任是建立长期 FinOps 实践和文化的关键。使用 RACI(负责、问责、咨询、知情)和 DACI(驱动、批准、贡献者、知情)模型的组合，我们可以将核心 FinOps 原则关联到团队，并更好地表明他们的参与水平。下面做个参考：
2.5 FinOps 原则
团队需要协同作业
每个人应该为他们的云开支负责
由一个中心团队驱动 FinOps
实时、可访问的成本报告
业务价值驱动决策
灵活利用云上成本模型
2.6 FinOps 迭代
总共分为三个阶段：洞察、优化和运营。任何公司在任何时候都可能处于多个阶段，这取决于所处的业务单元、应用或团队。
Inform
成本洞察，这是 FinOps 之旅的第一阶段，赋予组织和团队可视性、分配、基准、预算和预测能力。云计算的按需分配和弹性特性，以及定制的价格和折扣，使其对智能决策的准确和及时可见性非常必要。基于标签、帐户或业务映射的云开销精确分配可以实现准确的退款和显示。业务和财务也希望确保他们在控制预算的同时提高 ROI，并准确预测支出。
Optimize
成本优化，基于成本可视化和成本分配手段，有了可视化的数据作为度量依据，团队能够围绕其业务目标及业务场景制定对应的成本优化目标。云提供商提供了多种优化手段。为了鼓励提前预订计划和增加承诺，云提供商为承诺提供折扣，这通常涉及复杂的预订计算(预留实例(RI) /承诺使用折扣)。此外，团队和组织可以通过调整和自动化关闭任何浪费资源的使用来优化环境。
Operator
成本运营，团队开始持续地评估业务目标和它们针对这些目标跟踪的度量，从流程、组织、文化等方面建设成本运营体系，其中包括围绕业务、财务和运维构建的云成本中心，根据目标持续调整优化。
2.7 FinOps 成熟度模型
爬行阶段：
支出应该能分配至少 50%
基于资源的承诺折扣目标覆盖率约为 60%
预测支出与实际支出的准确度差异为 20%
行走阶段：
支出应该能分配至少 80%
基于资源的承诺折扣目标覆盖率约为 70%
预测支出与实际支出的准确性差异为 15%
跑步阶段：
90%以上的支出可以分配
基于资源的承诺折扣目标覆盖率约为 80%
预测支出与实际支出的准确性差异为 12%
三、如何开始
为了做成本优化，都已经有专门的基金会去指导大家怎么更好的落地，并且陆陆续续也有一些开源项目，起码说明了三点：
这个事情不简单，可以说是一件比较复杂的事情
是一件需要长期做的事情，并且值得投入
大家开始重视这个事情所以为了让大家能够更好的去做这个事情，我还是想让大家能够深刻去理解这个事情的挑战，当然前提是你很想把这个事情持续做好，能够达到一个比较不错的目标，而不是停留在差不多或者只是一次性的工程。
挑战一，基础设施复杂性
我们可以把资源分成两个大类，一个是基础设施，一个是业务系统，基础设施是服务于业务系统的。业务系统的复杂性带动了基础设施的复杂性。我之前写过一篇文章专门讲基础设施的，这里的基础设施包括我们现在使用的中间件资源、数据库资源、云资源等。根据熵增定律，一个复杂系统在没有外力的作用下，它会变得越来越混乱，直到无序。而这个软件系统和生产这个软件的组织，就是一个复杂系统。软件架构从最早的单体应用到 SOA 化，再到现在的微服务化，其整体复杂度越来越高。那支撑这么复杂软件系统的基础设施呢，现在我们需要开发更多的软件来管理现在这种庞大的基础设施，也就是需要使用另一种复杂系统来管理当前软件的复杂度。我们从本质去聊这个事情，业务系统对基础设施的最根本诉求是什么，1，快 2，稳 3，省
快
开发快，提升整体研发效率，这块基础设施团队要做的工作就很多，比如提供专门的中间件支撑，提供脚手架，自动化的生成框架都是为了提升效率
上线快，我们做 CI/CD，就是为了把代码打包成制品，然后快速的部署到线上
质量好，不仅仅追求快，还要满足用户需求，生产出高质量、有价值的产品
稳
故障次数少，故障时间短，这个本身就是稳定性里面的目标，这里不做详细介绍。
复盘质量高，我们希望每一次的复盘都能够起到后续避免类似稳定性的问题。
省
用最少的资源产生最大的业务价值
挑战二，深入了解每个云产品的特性、收费模式
我们接触云产品这么久，到现在没有一位运维敢说自己很了解每个云产品的收费模式。每个云商、每个产品都有各种各样的特点，这个也是为什么会这么复杂的因素。最关键的是我们作为使用者，并不能去改变、统一这个事情，只能去适应，这个是云商带来的本质复杂度。
多个云商之间差异较大。
多个产品，每个产品的计算逻辑都不一样。
单个产品，还分预付费、后付费，预付费里面还包括月付、年付等不同种类，计算逻辑复杂。
还有退款、预留实例券、优惠券等等情况需要计算
挑战三，深入了解公司业务，量身定做最合适的方案
想把成本优化做精、做细，能够给业务提供较好、能接受的成本优化方案，那我们不仅仅要懂运维、懂开发、还要懂业务，可以试着问自己几个问题，看能否回答得清楚。
应用 QPS 不高，CPU 使用率也不高，为啥服务需要这么高配置？
对于需要很多节点的服务，架构上是否合理？
技术方案如何选型，才能更好的利用资源？
不同业务阶段，当成本和效率发生冲突，如何选择？
挑战四，公司成本优化文化的落地
我们想做好这件事情，离不开领导、同事们的支持和帮助，需要让大家都能理解成本优化的重要性，以投入文化变革所需的时间和资源。
四、演进、落地
为了让大家对 FinOps 落地有个更直观的感受，可以先看下下面这张图，我们从成本洞察、成本优化、成本运营这三个大的方向出发，这也符合 FinOps 的原则。当然本篇文章，我不可能把以下每个节点都讲的那么清晰，我会更多的是讲一些我的思考带给大家。这里的每个节点如果要讲，绝对可以单独拿出来写一篇文章。
4.1 成本洞察
无法度量，就无法被管理，成本洞察是做成本治理的开始，我认为也是最重要的一环。试想你连你公司成本花在哪个地方都不清楚，你从哪里开始治理，降多少合适，别人如何支持你，大家怎么理解做这个项目的意义，一味的压缩资源导致故障了怎么办？
账单接入
洞察的第一步就是账单接入，这里我们以公有云举例，现在基本大部分企业都有使用公有云，如果你这边还有传统的 IDC 机房，大概理念也是差不多的，只是需要自己去把成本给核算进去，没有云这么方便，有专门的 api 接口供你获取。每个月公有云都会出账单，记录该月产生付款的时间和金额，如果你需要看每日的变化情况也有日账单。产品又分为预付费和后付费，还有年度付费的情况。这个也是做成本洞察比较挑战的点，上面有提到过。试想，我们既然要分析各资源使用情况，一般情况下会以时间为维度去看变化情况。比如去看 11 月比 10 月的情况，对于预付费的产品，购买日期在 10 月 15 日，可以使用到 11 月 15 日，但是费用确记录在 10 月的账单，你如何去衡量。账单记录的是现金流，更多的是财务视角，如果作为基础设施的降本人员，我们更希望看到的是每月实际使用的情况，这样我们才能更好的判断这个月是不是有异常使用情况。我们可以引入成本的概念，来表示一定时间范围内的实际开销，所以我们关注的重心应该由账单分析转移到成本分析，多关注每月实际成本。比如上面的例子，我们可以把产品的费用除以 30 计算出每天的费用，然后 10 月的计算后归到 10 月，11 月的归到 11 月。
CMDB
做基础设施的同学应该都熟知这个系统，在做成本分摊之前需要进行做的首要事情是基础设施数据的提供。我们自研、打造了 CMDB 系统，涵盖了各种云资源、业务服务管理。以应用为中心，把组织架构部门/业务域、人、应用、资源关系串了起来。这样成本平台就能通过对接 cmdb 获取到所有相关的数据，将成本按照实例级维度分摊到业务域、对应到团队、部门，支持日、月维度成本数据分析和成本预测。开发 cmdb 是个比较复杂的工程，尤其在云原生、微服务时代，资源的变化、人员的变化需要 cmdb 是一个能自动化搜集、实时调整的系统。比如怎么把应用、数据库对应到团队，云的每个资源对应到团队，k8s 的每个 pod ip 随时变化的实时更新，如何让数据准确率达到接近 100%，这些都是挑战。如何建设 cmdb 不是本篇要讲的，这里就不再赘述。
单位业务成本
分析公有云成本的变化原因时，始终绕不开以下两个问题：
成本的增加是业务增长导致的，还是云资源的低效使用导致的？
成本的减少是业务下降导致的，还是技术降本导致的？因此我们不能只站在资源的角度去看成本支出，也要关注业务变化带来的成本问题。单位经济是 FinOps 最重要的概念之一，它将云支出与业务指标（总收入、订单数、UV 数、PV 数等）作比较，从而计算云资源的投入产出比。
FinOps 的终极目标是单位经济支出管理，也就是我们每个 X 的成本是多少，其中 X 可以是 “订单、用户、PV” 等。通过计算单位业务成本，就可以将云支出的变化与整体业务变化联系起来。当云支出增加而单位业务成本不增加时，就说明云支出的增加和业务的增长有关系，增加的云支出就是 “好” 的支出。当单位业务成本增加，就说明我们的成本控制不够好，有很多资源被浪费了。如果单位业务成本减少，则是我们成本优化效果的表现。
总之一句话，花钱是可以的，但浪费不行。这里举个例子，对于公司级和业务级的单位成本指标，可以用核心域名的 PV 数，对应的单位成本是百万 PV 成本，也就是我们每处理一百万个请求需要支出多少费用。某个月的百万 PV 成本 = 该月的公有云总费用 / 核心域名该月的 PV 总数 * 100W。
4.2 成本优化
应用画像
知己知彼方能百战不殆，想要解决云资源使用问题我们先要掌握应用在一定时间周期内使用集群资源的详细情况，那么应用画像就是一个比较有效的办法。可以以服务为中心进行展开，不仅仅看应用使用的资源，还包括相关的一些属性。下面给大家举个例子，仅供参考：
提升 k8s 资源利用率
在 Kubernetes 中可以通过指定 Request/Limit 选择性地为 Pod 设定所需的资源数量。当为 Pod 中的 Container 指定了资源 Request 时， kube-scheduler 就利用该信息决定将 Pod 调度到哪个节点上。当为 Container 指定了资源 Request 和 Limit 时，kubelet 会通过 Cgroup 参数确保运行的容器可以获取到申请的资源并且不会使用超出所设限制的资源。kubelet 还会为容器预留所 Request 数量的资源供其使用，因此，为了提升 Pod 的利用率我们需要配置合理的资源 Request。常见的资源配置问题：
我们可以通过以下的方式去提升整体使用率：
提升装箱率：让资源更充分的分配出去。
动态资源超卖：将节点的空闲资源作为扩展资源赋予节点，然后让重要性较低的应用使用扩展资源。
负载感知调度：感知集群内节点负载情况，将 Pod 优先调度到负载较低的节点，实现节点负载均衡。
负载热点打散重调度：自动对高负载节点上的 Pod 进行重调度，调度到负载较低的节点。可对应用打标，只允许重要性较低的应用被重调度。
业务规格调整减少资源锁定：根据周峰值资源用量调整业务规格使 Request 可以减少到周峰值线。
业务规格调整 + 自动扩缩容兜底流量突发：在规格优化的基础上再通过 HPA 兜底突发流量使 Request 可以减少到日均峰值线。此时 HPA 仅为应对突发流量，绝大多数时间内不发生自动弹性。
业务规格调整 + 自动扩缩容应对日常流量变化：在规格优化的基础上再通过 HPA 应对日常流量变化，使 Request 可以减少到均值。此时 HPA 的目标利用率等于应用的平均利用率。
使用阿里云弹性容器实例 ECI：我们业务有明显的波峰波谷特征，使用 ECI 作为弹性资源池，再结合 HPA ，让 HPA 弹出的 Pod 全部调度到 ECI ，不需要为自动扩缩容预留资源。ECI 省去了底层服务器的运维和管理工作，并且仅需要为容器配置的资源付费（ 按量按秒计费 ），可以节约成本。
在离线混部：通过错峰将离线资源和在线资源进行混部，比如在线资源低峰期时可以进行一些大数据方面的运算，这样可以进一步的充分利用资源。当然这也带来了一系列的挑战，作为基础设施人员我们要更关注容器在混合部署后带来的干扰问题，因为混部会更容易产生资源竞争，应用的响应时间往往会出现长尾现象。
其它方面优化
如果你使用的是公有云，云资源的优化点还有很多：
正确的规格选型，云产品的规格有很多，同样是 4c 8g 的服务器，Intel 的还是 AMD 的价格差距还是不小的，并且每一代的产品价格也不同，要根据自己的业务情况去识别，选择性价比最高的。
存储的优化，比如日志我们可以根据每个应用的要求去选择合适的保留时间，对于数据量大的业务看看是否可以进行冷热分离存储等
合理使用资源包，梳理可以使用资源包的产品，通过使用预付费资源包，降低后付费产品的成本。
有些产品有 serverless 形态，如果高峰期使用时间比较短，为了应对偶尔的高并发可能使用 serverless 比直接包年包月那种更省这些都需要运维在日常使用中去总结、提炼，以便更充分的发挥云的优势，让基础设施在保障稳定性的基础上更具有性价比。
4.3 成本运营
组织建设
对标 FinOps 基金会建议的协同职能组织结构，我们需要建立一个成本运营虚拟组织，推进云成本持续优化，该组织架构主要包括以下部门和职责：
成本运营岗：负责日常云成本的运营管理，监控资源使用情况，发现并解决成本问题，推动各部门提高成本意识和优化资源使用。同时负责制定预算、分析成本数据，并确保云成本的合规性和合理性。
业务技术研发：各业务域都会有一名研发对接人，作为该部门成本负责人，认领成本运营下发的优化、预算等需求，协调部门内部优化落地，对部门成本健康状况负责。
财务部门：从财务视角对云成本进行管理和推动。
SRE：作为云成本技术治理的专家，负责优化资源配置、提升系统性能，降低云计算成本，同时保障业务稳定运行。
IT 商务：负责与多家云服务商进行商务谈判，争取更优惠的价格和服务条款，降低整体采购成本，提高企业在云市场的竞争力。
健康分机制
使用成本健康分可以综合来衡量资源使用的合理程度，让各个团队更清晰的观察到自己所使用的资源情况。资源的监控分除了考虑 CPU、内存使用率这种常规指标外，还需要考虑 QPS、IO 等因素。针对不同的云产品，制定不同的计分项和权重。拿应用实例的健康分举例：成本健康分的满分是 100 ，及格分是 60 。
如果应用同时满足以下条件，则该应用的成本健康分是 100 分。
实例数小于等于 2 。
request_cpu 小于等于 0.5 核 ，request_memory 小于等于 2GiB 。
否则按下表中的规则计算，成本健康分就是各指标的分数之和。
例如应用最近 7 天 CPU 使用率平均值是 12.65% ，TP70 值是 34.37% ，则成本健康分是(0.1265 / 0.2 * 60 * 0.5) + (0.3437 / 0.3 * 60 * 0.5) = 53.34 。再例如应用最近 7 天 CPU 使用率平均值是 21.85% ，TP70 值是 61.32% ，则成本健康分是(0.2185 / 0.2 * 60 * 0.5) + (100 * 0.5) = 82.78 。
自动识别异常
有了健康分体系，我们可以自动化的去识别哪些资源有异常情况，并发出通知进而推动治理。
资源规格不合理，使用率较低。
成本异常突增。
资源闲置，长时间没有流量。我们甚至还能结合历史情况，给出优化建议：
计费模式不合理，比如流量过高的负载均衡更适合按固定规格计费，流量较低的实例更适合按照流量计费。
使用方式不合理，比如日志产品，有些服务可以开启冷热分离存储。
资源性能过剩，例如 SSD 云盘换成高效云盘。
资源使用率比较低，可以缩容或者降配。
五、成本运营分析平台
将整个成本运营体系平台化是我们落地 FinOps 的最终必然选项，我们也一直致力于建设这个平台，通过平台化将洞察、优化、运营形成一个闭环、能够持续治理整个基础设施的资源。尽可能通过平台化做到：
成本治理工作常态化，融入到资源的整个生命周期管理。
成本治理工作前置化，从资源创建开始，创建出最合理的资源。
成本治理工作自动化，自动化发现使用不合理的地方，发现一例治理一例，把成本浪费时间减到最小化，人员投入成本也最小化。
架构蓝图：
通过成本运营平台，我们能够实时的了解各个云资源的成本变化，精细化到每个 k8s pod 每天的资源花费。通过各种报表分析短时间内发现异常，运维同学只需要少量的精力就能够完成成本的治理工作。
六、最后
本篇文章更多的是对 FinOps 落地的一些思考，以及如何通过洞察、优化、运营为企业降低基础设施成本，具体实战细节还是要根据自身业务去看。当然也有一些觉得自己做的还不足的地方，比如成本如何预测，由于变化的因素太多导致预测的还是不准确，就没有单独去做更多的介绍。如果后面有更好的思路，可以单独写一篇针对核心场景的实战篇分享给大家。最后，如果大家对 FinOps 的话题比较感兴趣，欢迎联系我讨论、交流。
could native 2017-12-17 加入
云原生、DevSecOps、SRE方面的爱好者、从业者
评论