阿里云发布企业云原生IT成本治理方案：五大能力加速企业 FinOps 进程

## 云原生技术与降本增效

2020 年，新冠疫情横扫全球，大量的企业停工、工厂停产、供应链中断，给全球的经济带来巨大的冲击。有 65%的企业开始考虑通过上云的方式提升企业 IT 信息化的能力来应对未来可能出现的其他系统性风险。而云原生技术作为时下最先进的上云方式，成为了大多数企业进行 IT 信息化转型的最佳选择。

知名顾问机构 Capgemini 在 2020 年的“Cloud Native Comes of Age”调研结果显示，仅有 15%的企业已经将新应用程序建立在云原生环境，但接下来的三年这个比例将提升到 52%。报告中，在云原生环境中部署超过 20% 应用的企业被定义为领先者，他们是如何看待云原生技术呢？

87%的受访企业表示，云原生提高了效率并降低了成本。84%的受访企业表示，云原生推动了更好的客户体验。80%的受访企业表示，新产品和服务的推行等待时间显着降低。


而在2021年CNCF《FinOps Kubernetes Report》的调研报告显示，迁移至 Kubernetes 平台后，68%的受访者表示所在企业计算资源成本有所增加，36%的受访者表示成本飙升超过 20%。即便是作为大多数领先者企业共识的降本增效特性，在很多企业进行云原生转型的过程中依旧障碍重重，甚至付出了更多的成本，为什么已经采用了云原生技术，却还是离理想那么遥远？

## 从一个真实的案例讲起

Raymond 是一家互联网电商的 IT 平台负责人，在过去 2 年的时间里，带领团队将公司所有的业务进行了云原生化改造。Raymond 选择云原生技术作为平台架构方式的初衷是非常朴素的，因为以微服务、容器、DevOps 为代表的云原生技术，可以将不同类型的应用进行统一的交付和运维，降低管理成本；可以通过流水线实现自动化的构建和交付，提升研发速度；可以通过容器技术实现应用之间的资源共享与弹性，降低资源的浪费；可以通过不同类型应用间的混部与抢占，进一步压榨集群资源的利用率。

| 业务平台    | 业务描述                                                                     |

| ------- | ------------------------------------------------------------------------ |

| 电商主站    | 周期性业务，工作日白天为低谷，工作日晚上与节假日为高峰，大促场景下存在激峰流量。                                 |

| 大数据平台   | 包含数据湖的即席查询与报表/ETL作业，即席查询主要以Presto为主，作业主要数据研发通过工作流提交；ETL作业主要以Spark离线作业为主。 |

| 微商家平台   | 多租户SaaS化业务，每个租户独立配额和用量。                                                  |

| 直播平台    | 周期性业务，工作日白天为低谷，工作日晚上与节假日为高峰，存在不可预期的峰值流量。                                 |

| 转码/训练平台 | 临时任务，碎片型作业，运行时间较短。                                                       |

Raymond 的团队负责公司五大平台的稳定运行，根据业务的特性、运维的便捷性、安全的等级、成本的考量，Raymond 将业务拆分了三个集群：

-   **集群 A-主站/转码集群**

主站的业务稳定性要求较高，整个集群的规划以静态节点池为主，配合定时伸缩的能力在业务高峰到来之前提前扩容。白天容量较低的时候，通过混部转码业务分时复用集群的空间，从而实现资源效率的提升。


-   **集群 B-直播/大数据集**

将直播业务和大数据业务放在一个集群中的原因是，无论是数据湖的即席查询、直播业务还是大数据的 ETL 作业，在单位时间内对计算资源的消耗都是非常大的，但是业务的容量大小存在比较大的随机性，高弹性的场景更适合两者的业务。


-   **集群 C-微商家集群**

将微商家业务独立放在一个集群内，主要是出于安全性的考虑，隔离租户数据与业务数据。此外，独立的集群也可以更好地进行成本核算。

作为非常资深的云原生领域专家，Raymond 的技术选型、集群的拆分、优化的策略都是无可挑剔的，业务云原生化的第一个月，稳定又高效，一切似乎都在向着预想中的结果前进着。


“上个月的费用增加了 70%？”，在拿到最新的账单后 Raymond 喃喃自语百思不得其解，到底是哪里出现了问题？

## 企业云原生 IT 成本治理的难点

从前，Raymond 的团队采用的比较传统、成熟的静态企业 IT 成本治理模型。这种模型的周期通常为月度或者季度，通过资源规划、成本估算、成本预算、成本控制四个阶段的实施，进行 IT 资产的采购，实现企业IT成本治理的目标。


这种模型的优势是每一次 IT 成本治理所得出的成本预算是固定的，从 IT 资产管理的角度来讲是非常友好的。但是弊端也比较明显，当业务存在容量的频繁变化的时候，可能会使成本估算阶段出现较大的偏差，造成大量的浪费。

云原生技术中常用来降本增效的方式，例如：智能调度、弹性伸缩、混部、分时抢占等本质上来讲是将资源的独享变成共享，将资源的静态供给变成动态，任何新技术的采用，势必会对已有系统的架构进行改造与优化，而云原生技术架构的引入的动态性改造常常会打破企业中传统的 IT 成本管理体系，造成 IT 成本管理的失控。当 IT 成本管理失控的时候，各种优化的策略也就成为了无根之木。


当 Raymond 尝试通过账单来找寻出现问题的蛛丝马迹的时候，他得到的是一张上百页的月度账单详情，从账单明细中来回溯导致异常费用产生的应用、部门是几乎不可能的事情。而 Raymond 遇到的难题，几乎是每一个云原生架构的负责人都必须跨过的难题。

那么，是什么导致了企业云原生 IT 成本治理的困难呢？

-   **业务单元与计费单元生命周期的差异**

在传统的企业 IT 成本治理模型中，业务单元和计费单元是存在一定的匹配关系的，例如：一个门户网站，包含两台 ECS，一个接入层网关 SLB，一个数据库 RDS。它的业务单元和计费单元是一对一的，账单即是成本。


但是，在云原生的场景下，当应用部署在 Kubernetes 等容器集群时，所有的资源是池化的，业务的最小计量单元是一个 Pod，而 Pod 的生命周期与实际产生账单的节点的生命周期是不匹配的。大多数场景下，应用的重新部署，业务的 Pod 就会重新调度到其他的节点之上，这导致了业务单元和计费单元在逻辑、空间、时间三个维度上，都可能无法做到一对一的匹配关系。

这就导致了企业的业务部门想要去衡量、规划、估算一个业务的预算的时候，难以得出具体的结果。

-   **动态资源交付与静态容量规划的矛盾**

传统的企业 IT 治理模型中，规划/预算与资源交付的关系是静态的。业务部门可以按照月度、季度、年度的周期提交预算，再由 IT 部门进行统一的采购、分配。为了解决静态容量规划模型中资源浪费的问题，容器采用了例如：弹性伸缩等技术与解决方案。通过动态资源交付的方式，进行容量成本的控制。

但是，动态资源交付模型在实际的生产中，可能会引入其他的成本陷阱。比较典型的是传统静态规划模型大多会采用包年包月的计费方式，而动态资源交付模型，会混合包年包月与按量付费等多种模型。甚至某些场景下，还会引入 Saving Plan、预留实例券、竞价实例等特殊的付费策略。相比而言，包年包月的计费单价是按量付费等模型的 30-50%左右。当动态交付的资源占比不合理的时候，可能会造成 IT 成本的大量浪费。

此外，传统静态容量规划模型的预算和采购是在一个阶段实施的，这样 IT 成本治理无需关注成本的趋势变化。但是当大量的动态资源交付模型实施后，企业的 IT 管理员需要不仅仅关注总的费用变化，还需要关注成本的趋势，甚至某些场景下需要对费用进行预测，以保障集群的费用不会出现非预期的大规模超出预算的现象。

-   **企业 IT 成本治理模型与云原生架构的适配**

传统的 IT 成本治理模型在成本控制方面，更多的侧重是在增效这个维度，通过提升机器的利用率，缩减下一次容量规划阶段的成本。而云原生 IT 成本治理的场景，增效和降本是同时进行的，企业可以通过监控、智能推荐等方式调整资源的配额，实现资源利用率的提升；通过弹性伸缩、动态资源交付等方式，实现资源成本的降低。降本增效同时进行的方式，会大大缩短企业 IT 成本治理模型的周期，并且对预算管理配额管理、成本趋势预测、成本趋势报警提出更多的要求。

-   **不恰当的成本优化方案滥用的副作用**

传统的 IT 成本治理模型的优化手段相对而言比较单一，通常是通过资源利用率等指标的指导，实现降本增效的目的。而在云原生的场景下，各种各样的优化手段层出不穷。但是，任何的优化方案都会对现有架构的稳定性带来挑战，例如：

-   使用弹性伸缩时，需要考虑伸缩灵敏度与业务流量洪峰的匹配程度；需要考虑缩容时业务的优雅下线；需要考虑是否会造成成本黑洞（异常原因造成的大量资源浪费，例如：DDOS 时造成的 CDN 资源超量使用）等等。

-   使用大数据弹性供给时，需要考虑集群是否还有闲置资源可以复用；需要考虑临时数据作业的运行时长是否过长，造成资源的计费模型不合理；需要考虑弹性供给时资源的利用率是否符合预期等等。

本质来讲，云原生场景的优化主要集中在调度/资源的动态性上，通过腾挪、分时、抢占、伸缩等手段，实现资源利用率的提升，以及整体集群水位或者总核时成本的降低。大多数的优化都是针对领域场景的，企业在进行云原生 IT 成本优化方案实施之前，需要先衡量和评估架构的变更带来的风险，以及优化方案的预期收益。

上述的四个问题，是每一家企业云原生转型时做 IT 成本管理都绕不过的障碍，制约了企业进行云原生转型的节奏，也困扰了像 Raymond 等一大批云原生技术的领先者。为了解决上述问题，云原生 IT 成本治理方案就应运而生。

## 阿里云企业云原生 IT 成本治理方

阿里云容器服务与 AWS 并列排名第一，是全球容器产品最完善的云服务厂商。早在 2006 年就开始在阿里集团内部推进云原生技术的落地，十六年的云原生实践的经验积累让阿里云对云原生的思考和理解可以更好的赋能给企业，助力企业实现 IT 信息化转型。

近些年，随着企业上云的加速，云财务管理（**FinOps**）的概念被越来越多的企业提及与采纳，云财务管理（**FinOps**）是一种云的运营模式，它将系统、最佳实践和文化结合在一起，以提高组织了解云成本的能力。这是一种为云支出带来财务责任的做法，使团队能够做出明智的业务决策。云财务管理（**FinOps**）增强了 IT、工程、财务、采购和企业之间的协作。它使 IT 能够发展成为专注于利用云技术为业务增值的服务组织。当云原生技术与云财务管理（FinOps）概念交织在一起，就孕育出了云原生IT成本治理（Cloud Native FinOps）的理念，它是云财务管理（FinOps）概念在云原生场景下的一种演进与进化。

阿里云容器服务推出了企业云原生 IT 成本治理方案，助力企业在云原生云上的场景下，提供企业 IT 成本管理、企业 IT 成本可视化、企业 IT 成本优化等功能。阿里云企业云原生 IT 成本治理方案拥有五大核心功能：


**核心功能一：独有的云原生容器场景成本分摊与估算模型**

为了解决容器场景下业务单元与计费单元生命周期不一致的问题，容器服务提出了独有的计费与计量相结合的成本估算模型，并加入费用策略（付费类型、节省计划、代金券、用户折扣、竞价波动）、分摊因子（CPU、内存、GPU 卡、GPU 显存等）、资源形态（ECS\ECI\HPC）等因素的考量，实现针对Pod维度的成本估算以及集群占比的成本分摊。通过账单分析将集群在一个阶段内的所有资源成本进行聚合，再配合 Pod 维度的成本分摊能力实现了完整的云原生容器场景成本分摊与估算模型。


**核心功能二：多维度的成本洞察、趋势预测、根因下钻**


支持集群、命名空间、节点池、应用（label 通配符匹配）四个维度的成本洞察，集群维度侧重在云资源的分布、资源成本的趋势变化、集群水位与浪费的比率以及集群成本费用的趋势与预测，可以协助IT管理员准确判断成本消费的趋势，防止超过预算的场景；命名空间侧重在费用的分摊，支持短周期的费用预估以及长周期的成本分摊，支持调度水位、资源用量、成本趋势的相关性分析，协助部门管理员进行成本估算，下钻分析成本浪费，提升部门资源利用率；节点池维度侧重在资源成本规划与治理，通过实例类型、单位核时、调度水位、利用率水位的相关性分析，协助 IT 资产管理员优化资源组合和付费策略。应用（label 通配符匹配）维度侧重在领域场景成本优化，例如：大数据、AI、离线作业、在线应用等各种上层应用场景，都可以通过应用维度的成本洞察进行实时费用预估以及任务级别的成本核算。

通过四个维度的成本洞察，可以让全场景的成本优化功能与解决方案都有数据可以支撑，有理有据的进行降本增效。

**核心功能三：全场景的成本优化能力、解决方案的覆盖**

****

针对于不同企业的实际业务场景，阿里云容器服务提供了全场景的资源画像建立、成本优化能力与解决方案（具体见文末）：

-   弹性伸缩

-   混部

-   智能资源画像

-   云原生大数据/AI

-   云原生工作流

此外，企业针对成本的优化策略，大部分是需要业务场景支撑的，很多场景下还会存在定制化和二次开发。因此，阿里云容器服务的企业云原生 IT 成本治理方案提供的成本洞察能力与上层优化方案完全解耦的，可以通过四个维度的成本洞察能力，覆盖全场景的成本优化手段的衡量与评估。

**核心功能四：多集群/多云/混合云全类型云成本管理能力**

多云是目前企业上云的新趋势，不同的云厂商的计费模型存在比较大的差异，例如：国内云服务商常见的包年包月付费方式、国际云服务商常见的信用卡预扣/后付、部分云服务商支持的节省计划以及预留实例等等。这些都对多云云管平面的成本分析能力提供了更多的挑战。阿里云容器服务的企业云原生 IT 成本治理方案通过提供统一的云服务厂商的账单与询价接入与默认实现，支持主流的云服务厂商、IDC 自建机房的费用数据的接入。并通过一致的云原生容器场景成本分摊与估算模型进行成本管理。配合企业级云原生分布式云容器平台 ACK One（Alibaba Cloud Distributed Cloud Container Platform）实现多云云管、资管统一的控制平面。

**核心功能五：企业云原生IT成本治理的专家服务**

企业云原生 IT 成本治理不仅仅是一个产品能力或者解决方案，更是一种云原生时代的企业IT管理、组织流程、文化的演进。阿里云容器服务团队联合阿里云天基团队，通过阿里云云资管家提供完整的 FinOps 理念覆盖的产品及专家服务。


阿里云云资管家作为国内通过《面向云资源的财务运营能力通用成熟度模型》评估的云产品，协助企业落地：成本流程治理、成本洞察、成本优化、成本运营等，助力企业建立云原生整体 IT 成本平台，加速企业全面云化后的  IT创新与 IT 决策。

## 回到真实的场景中去

面对 Raymond 的困境，要如何通过阿里云容器服务提供的企业云原生 IT 成本治理方案来进行成本优化呢？

**步骤一**：Raymond 先通过集群的成本分析能力，查看集群的成本趋势与成本预算的差异，可以来得出成本异常的初步结论。


| 集群名称          | 是否超出预算 | 超出预算比例 |

| ------------- | ------ | ------ |

| 集群 A-主站/转码集群  | 是      | 5%     |

| 集群 B-直播/大数据集群 | 是      | 140%   |

| 集群 C-微商家集群    | 否      | -9%   |

根据集群的费用情况可以看出，主体的浪费是在集群 B。那么，接下来可以主要针对集群 B 进行下钻分析。

**步骤二**：查看集群的费用构成，确定优化方向与下钻策略。


在这个集群中，可以看到计算资源是费用的主体构成，那么可以将问题下钻问题的方向导向资源利用率以及核时单价成本的角度来进行进一步的分析。

**步骤三**：查看集群的资源利用率情况以及核时单价成本


从集群的调度水位上来看达到了 78%，是一个比较理想的情况，既有一定的空间继续调度又不至于过于浪费。从实际的资源使用率来看，只有 3%的真实用率，说明资源存在已分配但是未充分使用的场景。此外，从节点池的核时单价上来查看，其中一个包含竞价实例的节点池的单价逼近按量付费的单价，这说明选择的竞价实例的规格存在不合理的现象，造成单位核时的价格过高。


**步骤四**：下钻应用维度，定位问题应用


通过命名空间维度可以定位到有部分的命名空间有明显的波峰波谷的容量变化，且容量扩容后，资源的利用率并没有明显的波动和变化，说明定时的伸缩对业务的是没有带来任何收益的。


通过命名空间中提供的资源浪费列表，可以看到出现大量浪费的应用名称。填写应用的 label 情况，可以看当前的应用基本是空跑的情况，但是占据了集群 34.74%的整体消费。


Raymond 经过和研发同学确认，发现是由于定时伸缩配置到了一个还未上线的测试业务上，而且配置伸缩的副本数比较大，造成了资源的大量浪费。此外，集群中的竞价实例组合由于库存的问题造成费用飙高，需要配置新的竞价实例的可用区和规格。至此，Raymond 重新配置了定时伸缩规则，修正了竞价实例的配置组合，困扰他很久的问题解决了。

其实，当我们回过头来看 Raymond 的问题，都是实际生产中可能遇到的小事，而正是这些不起眼的小事有可能造成企业 IT 成本治理的大资损。IT 的系统复杂度越高，就需要运维系统越自动化，同样，云原生降本增效的手段越丰富，就越需要 IT 成本治理的方案更数据化、透明化。降本增效是目的，强调的是结果而不是过程，依托企业云原生 IT 成本治理方案，可以透明化、数字化、自动化地实现企业 IT 成本优化的目标。

## 云原生企业 IT 成本治理未来的展望

可预见在未来，云财务管理（FinOps）的概念会被越来越多的企业提及与采纳，降本增效的能力与方案也会如雨后春笋一般的涌现。但是，从实际的情况上来看，大部分企业的 IT 成本治理的理念还没有跟上架构的演进，这无形中给企业的云原生化转型带来了更大的负担。想要完整驱动、落地云原生 IT 成本优化的策略，一定要让云原生 IT 成本治理的理念、工具、流程先行，只有可观测、可量化、可衡量的优化方案才能真正证明价值。

阿里云企业云原生 IT 成本治理方案助力企业落地企业 IT 成本治理的理念、工具与流程，让企业在云原生化的过程中可以数字化地实现企业 IT 成本管理与优化，成为 FinOps 领域的践行者与领先者。

***相关链接***

[1]《Gartner报告：阿里云成全球容器产品最完善云服务商》

[2]弹性伸缩：

[3]智能资源画像：

[4]云原生大数据/AI：

[5]云原生工作流：