►►►FinOps实践背景
作为一家全球化的产业互联网公司,其机房分布于全球6大区域,11个主要机房,国内资源主要在张北,海外主要在新加坡。同时弹外公有云环境还在支持多个生态公司,给该企业的FinOps带来了较高的复杂度。在核心基础设施方面,该互联网企业主要还是依赖阿里云和集团的产品为主,该互联网企业自建了一部分。
经过前两年的FinOps探索,该互联网企业发现大量的技术资源利用率仍然偏低,公司整个层面还没有统一的资源使用率规范;ADB、Hbase/Lindorm、Blink/Flink、Hologress、OpenSearch等类OLAP的技术资源成本一年高达***万,不合理使用造成的浪费严重,且这几年连续保持快速增长;对资源的不合理使用仍然主要靠人工来分析和判断,缺乏资源利用率异常预警机制。在常规的成本统计分析和费率比跟踪的基础上,从新财年开始考虑业务综合成本TCO。
►►►FinOps实施策略
在产业互联网新架构的指引下,该互联网企业提出了基于“六板斧”的FinOps策略:一、定目标,二、做度量,三、升架构,四、搞弹性,五、治数据,六、建机制。对于以上6个策略,下面分别展开阐述该互联网企业的具体做法。
一、定目标
参考FinOps的KPI设置,该互联网企业主要从云可见性、云优化和云治理这几个方面来设定目标: 以年度总预算控制目标为核心,通过各CTO-D团队和关键横向云资源的预算使用率、降本目标达成率、资源使用率为抓手,来组织全年的FinOps工作,实现技术、业务和财务的协同。
二、做度量
云可见性和云优化的主要载体是该互联网企业云资源管控平台,在技术成本分析和云资源治理方面沉淀了“云资源预算”、“经营分析”、“云资源降本”三大域能力,进一步细化为以下5个核心能力:
1、打通云资源成本全生命周期:将云资源预算、云成本账单、云成本归属&盘点三大阶段串联起来,形成全链路成本闭环。明确了成本项的颗粒度(实例、账号、应用)、归属谁(对应哪个技术团队、哪个业务单元)以及成本是否合理的问题,并在此基础上提供技术资源降本、经营成本分析等能力。
2、成本组织化显现能力:将来自集团HCRM、淘系、CRO、集团企业智能、数据部等技术成本统一按归属主体归属到最末端团队,从而让每一级团队都具备了成本分析、统计和跟踪能力。
3. 跟随组织变化的成本归属能力:解决因人员组织架构变化,导致成本归属无法映射到最新组织和业务架构树的问题,实现了财年末按组织和业务视角汇总技术成本,进而为年度技术预算提供数据支撑。
4. 基于日账单的滚动预测:基于近7天日账单的数据分析能力,支持按照技术产品或按照团队等多个维度,拟合预测本月的云资源成本趋势,让FinOps更有目的性和紧迫感。
5. 常态化治理能力(建设中):在整合阿里集团HCRM治理能力的基础之上,形成云资源成本分析、异常预警、资源使用率检测和降本任务驱动的常态化降本治理解决方案。
三、升架构
从成本视角出发,定义了成本友好型架构几大原则,推动该互联网企业成本友好型架构升级。
1、按需申请、弹性使用
申请的时候,按照最小需要的原则进行申请,随着业务的发展、访问量的增加逐步扩容。定义了该互联网企业的资源成本友好型一张表,来落地该互联网企业从资源合理性度量、资源问题透出到治理优化措施落地的大闭环,作为该互联网企业资源利用率提升的基础。目前资源共计6大分类、M个产品、N个元资源治理策略,由FinOps小组和业务线技术团队共同确保落地,进一步提升资源利用率,降低成本。如针对容器资源,设置CPU资源合理基准40%,再结合容器的收费规定(小时收费、规格用量手计费),来制定整体的降本策略,如通过HPA、VPA降低整体资源的用量、使用时长,提高CPU资源使用率来匹配靠近基准值。
2、基于温度的数据分层存储设计
按热温冷冻定义不同数据温度的存储方案,分层评估和设计存储方案,选择合适该温度的存储介质,配置合理的TTL生命周期,减少数据冗余存储,从而降低整体的数据存储成本。
3、 减少数据冗余,降低膨胀系数
数据膨胀系数的定义:各领域核心链路覆盖的单据模型,包含运行态、运营态(AP/TP,不包含离线ODPS),当存在50%及以上字段冗余(业务主体感单据)时,判定为存在数据冗余,每存多存在一份数据冗余,膨胀系数+1。
4、成本&稳定性Balance原则
很多人认为云资源管控和稳定性有冲突,这其实是一个偏见。通过云资源的合理管控,驱动业务进行不合理架构治理(比如:数据存储治理优化,性能优化),建立对资源的合理认知,在一定程度上,对稳定性有帮助。同时云资源的治理也是深度审视自身业务的一个过程,是清除历史债务的一个过程,让业务可持续,让成本和稳定性建立一个良性循环。
5、其他架构注意事项
除了以上4大原则之外,在日常的架构设计中,还需要注意避免过度微服务化、多套技术栈、技术资源复用和降低链路复杂度等,综合多个因素共同推进成本友好型架构落地。
四、搞弹性
目前各云厂商都提供了容器弹性扩缩容机制。该互联网企业弹内容器资源提供了VPA(Vertical Pod Autoscaler 垂直扩缩容)和HPA(Horizontal Pod Autoscaler 水平扩缩容)两种机制。
因该互联网企业具备长链路特性,不会多域同时触发高流量,借用HPA也能轻松的实现该互联网企业自身的分时复用,一批资源能够错峰支持0点链路和末端链路。目前分:潮汐弹性、负载弹性 两类弹性场景:
1.潮汐弹性 -- 通过设置 crontab规则,按需弹性,提前扩容到需要的容器数,峰值保留时间结束后调度系统根据应用分组当前CPU水位逐步缩容至合理范围。如日常实操类业务每天作业峰值时间固定,可以通过周期性扩容实现提前扩容,到点缩容节约成本。
2.负载弹性 -- 基于CPU使用率来进行容量扩/缩,可应对突发流量或业务FGC场景。
从容器弹性试点作为起点,后续逐步扩展到数据库弹性,再逐步走向全面弹性的云资源管控。
五、治数据
随着该互联网企业在产业互联网领域的逐步深耕,IoT数据量急剧增加,已经成为数据密集型的产业互联网企业。在这样的背景下,该互联网企业的技术架构也需要重塑,我们称之为“产业互联网新架构”。
如何大幅降低技术成本,提高研发效率成为一个新的挑战。这个挑战,对于在线大数据处理领域尤为突出。如今OLAP相关的产品非常多,如ADB、OTS、ClickHouse、OpenSearch、HBase、Blink和Hologress等。面对这么多的产品该如何组合和使用,对不少团队来讲都是一个不小的门槛。与该互联网企业各个业务线交流了使用在线大数据上的情况,发现都面临如下的痛点:
1、模型冗余成本高:由于领域模型不收敛和方案选型不佳,导致数据冗余,资源成本高企。
2、推动降本成本大:早期基于大宽表明细直接做汇聚计算带来的研发效率提高也导致了后期的资源成本高企,但应用分层架构的改造人力成本非常高昂,也严重打击了降本的积极性。
3、重复存储浪费大:Hbase类存储往往是成本大头,其中大宽表中有大量重复出现的值,key多为英文字符串,存储也是重复的,采用字典化存储能大量节省存储成本和计算成本,但是业务复杂度会大量上升,需要做存储和查询时的字典映射。
4、查询治理困难多:ADB类资源查询的SQL会有很多,有很多SQL写得不好会导致集群资源被大量消耗,如何快速发现并熔断,保证集群安全,后期如何提出改进建议,以任务方式推动上层业务改造,也是现在的痛点。
为此,该互联网企业成立了“新型在线大数据”团队,希望打造一款产品,实现一种“渐进式”的架构演进能力,提升研发效率,持续降低成本。
六、建机制
1、专项治理机制
为了进一步提升云资源的利用率,形成了以横向技术专家(懂技术)+ 纵向业务开发(懂场景)相结合的方式,形成若干个专项小组,针对不同的技术产品形成不同的治理专项。在专项的治理过程中,横向小组负责制定降本策略和下发降本任务,各纵向团队负责域内评审和落实。在此基础上,横向小组重点评审头部实例的架构选型、及资源使用率是否合理,把降本和架构治理紧密结合,达到了深度降本的效果。
2、全面组织保障
FinOps的推动离不开有效的组织保障机制,为此,该互联网企业组建了FY23财年FinOps小组。在横向领域,按照技术产品分类,设置横向降本接口人,也包括财务的接口人;在纵向业务域,按照该互联网企业CTO-D团队,每个团队设置1-2名降本接口人,负责本团队的降本工作,各团队内部还可以进一步设立二级的FinOps小组。横纵结合,形成了CAINIAO FinOps总的组织阵型。这个组织可以灵活设置,在该互联网企业目前是通过项目制的机制来运作,除了对云资源进行降本提效,也对各业务线的单均成本负责,同时还肩负着在各团队宣导FinOps理念的责任。
3、TCO成本模型
除了纵向看成本的增长趋势,还需从业务的视角来看技术成本是否合理。TCO(Total Cost of Ownership)是一个综合的视角,站在产品发展和演进的全生命周期来看成本。合理的架构演进,要达到技术成本随着业务增长保持单位成本持续下降的目标。
该互联网企业作为一家产业互联网公司,支撑的业务多种多样,既有C端的驿站和裹裹等业务,也有供应链B端的场景,同时还有地网等资产(地产)管理业务。所以TCO模型的设计,需要考虑不同的业务场景特点,抓住核心的业务指标。经过梳理反复讨论,设计了该互联网企业各业务单元的TCO成本模型。
以该互联网企业驿站为例:驿站的单均成本 = 驿站的综合成本/驿站的总单量。每个月统计一次。实际过程中,还可以基于是否包含人力成本区分出两个模型指标。
►►►阶段性成效
1. 单月成本显著下降,守住全年总预算的目标可以达成;16个纵向技术团队均守住了预算目标,整体治理效果比原计划的目标超出23%;云资源成本和收入的费率比逐月下降。
2. 落实了OLAP相关(ADB、Hbase/Lindorm、Blink/Flink、Hologress、OpenSearch)、SLS日志、OSS存储、ODPS离线大数据和数据库XDB等5个治理专项,主要云资源产品的预算管控目标全部达成。
3. 产出了成本友好型架构下的云资源利用率规范一张表,核心资源的利用率大幅提升,达成目标。
4. 成本友好型架构的理念深入一线开发,该互联网企业大脑的常态化治理能力得到进一步增强,任务驱动的治理能力和异常预警发挥作用。
5.FinOps文化得到进一步推广和落实,FinOps小组和云资源治理机制趋于完善,TCO成本模型初步成型并得到大家的认可。
本文采摘于网络,不代表本站立场,转载联系作者并注明出处:https://finops.itqm.com/46.html