相信近期從事基礎設施工作的各位，對 IT 成本治理，以及 FinOps 體系的概念已經有了一些認知。在 Google 近 5 年的熱度趨勢中，FinOps 的趨勢也在持續上升。
在阿里雲的同學與客戶實際工作協同中，我們發現成本治理是幾乎每位客戶都存在的普適需求，特別是各位技術管理者重要的關注點之一。據 FinOps 基金會 2023 年的報告，有 43%、24%、17% 的公司，是由 CTO、CIO、CFO 直接指派 FinOps 團隊向他彙報，只有 14% 的公司處於還未建立體系化的降本增效的 KPI。
根據 FinOps 基金會的報告，建設 FinOps 體系 Top 的痛點非常複雜，包括技術方面問題、如何驅動工程師進行優化、如何減少浪費的資源、如何在容器場景做成本報告分析；同時也存在管理等問題，比如如何讓團隊組織適應 FinOps 體系等等。
我們希望阿里雲在提供產品功能的同時，也能正確真正地幫助我們的客戶落地自己的 FinOps 體系，真正讓客戶降本增效。
在 2023 年雲棲大會現場，我們有幸邀請到某頭部科技型量化投資公司的雲基礎設施負責人，爲我們提供基於阿里雲容器服務成本套件 ACK FinOps 落地的雲原生場景成本治理案例，幫助大家瞭解在容器場景下的企業成本治理現狀、挑戰，以及如何結合 ACK 成本套件產品功能構建雲原生用戶自己的 FinOps 體系。
容器場景成本治理挑戰與實踐
本次分享的企業是中國領先的以人工智能和機器學習爲基礎的科技型量化投資公司，使用了大量的 AI、大數據作業來輔助量化交易決策，需要大量彈性的算力的同時，也需要更好的實現成本的控制，通過 Kubernetes 將 AI、大數據、工作流等作業放在一個集羣中分時、彈性運行。
以該企業爲例，業務系統大致分爲幾類應用部署形態：
1. 穩定的系統應用
2. 不特定時間的按需任務
3. 測試開發環境的應用
這幾類應用都會消耗基礎計算資源，併產生成本。
目前該企業部分業務在使用阿里雲容器服務 ACK 集羣做容器化部署，通過 Kubernetes 進行量化交易的數據執行與決策，及阿里雲 ACK FinOps 套件實現成本的洞察與分攤，經過治理後實現了近 30% 資源水位的提升。
在企業成本治理的實踐過程中，該企業主要遇到規劃難、分賬難、管理難、優化難這 4 方面的挑戰。
- 規劃難
在進行成本治理方面工作時，首先遇到的挑戰是按需任務、測試開發環境的容量規劃問題。開發、測試應用在容器化部署架構下，實現快速迭代的同時，難以較準確地給出分配的資源量。過度分配資源會導致資源浪費，資源超售過度則會導致穩定性問題。
- 分賬難
該企業的雲基礎設施每天爲很多的上層應用提供服務，多個容器應用共享一個 K8s 集羣。一個計算節點上可能運行多個 Pod，而且 Pod 可以彈性伸縮，在節點間動態遷移。多個業務應用混部在同一個池化的 K8s 集羣中，難以把整個集羣的賬單分攤到應用和人。應用層與資源層計量計費在空間、時間等多個維度都無法做到一一對應，成本治理的複雜性業因此而來。
- 管理難
另外，由於各個應用的使用場景存在很大差別，每當找出閒置浪費的資源後，往往難以“爽快地”馬上縮容下線資源，如何在優化資源成本浪費的同時保障業務的穩定性，一直是一個難以回答的問題。
- 優化難
容器化後是擁有各種豐富的成本優化手段，但“這樣調低 request 資源分配水位後，是否影響業務？”，“現有的 HPA 彈性伸縮策略，是否能在業務真正需求資源時正確工作”，甚至於“我現在要下線的網絡、存儲資源是不是真的沒人使用？”
雲原生技術中例如彈性、混部、Serverless、超賣等技術都有各自適合的典型場景。如果使用不當，比如彈性配置錯誤，可能帶來意想不到的資源浪費甚至穩定性問題。
如何解決分賬難題
首先要面對分賬難問題，理清花費在哪兒是最重要的工作。
站在 Infra 團隊的視角，一直以來和上層業務、應用層的部門同事的協作工作方式都是：
當新業務需要上線、或老業務需要擴容時，業務部門會申請告訴我們他們“期望”使用多少的容量，爲了保證業務穩定性，資源需求往往拍腦袋定義，且業務團隊都希望申請冗餘遠遠超過實際預期的資源量。
長此以往，集羣的水位就會出現大量閒置。
由於業務是容器化混合部署的應用在同一集羣中，應用的水位分佈也往往呈現長尾效應，穩定的大規模應用往往經過重點優化已經有較高的資源利用率，但大量小規模應用使用大量閒置資源。
傳統部署模型下的資源成本統計方式，是按業務使用的節點維度分析成本，但是在 K8s 場景下，業務使用的資源統一從資源池中調度，業務對資源浪費也隱藏在整個集羣、節點的水位中難以發現。
要算清這本糊塗賬，一定要把成本歸因到具體某個業務應用，甚至是具體到某個人，才能推動真正地降本。怎麼把成本歸因到具體業務，首先需要精細化的監控數據，來看清業務對資源的使用情況。
阿里雲 ACK 團隊可以爲企業提供詳細的成本、資源觀測數據，包括：
1. 每天每筆雲上資源的真實花銷成本賬單
2. 每個容器部署的資源使用量、使用水位
部門、業務、個人這些業務層層級關係，該企業通過按集羣的 namespace、不同工作負載、任務通過打特定 label 的方式，最終與具體 K8s 集羣中的花費資源成本的 Pod 進行映射。最終通過結合阿里雲 ACK 成本洞察數據的方式，可構建多個不同視角的成本資源監控大盤，包括：
1. 每天每筆不同雲資源賬單維度的監控大盤
2. 歸因到業務應用/個人的監控大盤
由此，便於分析發現應用維度的浪費，如形成 Top 浪費的應用報表，進行數據驅動地成本優化推進。
面對成本管理難題
Infra 團隊在推動降本增效時往往是無力的，更多需要推動跨團隊的協作。
站在一個業務應用的上線過程來看協同關係，Infra 團隊往往職責是接受上層業務層同事的需求，以及保證提供資源，這裏的需求關係是從業務層到 Infra 層是至頂向下的。然而 Infra 團隊與成本資源花銷的距離是最近的，感知是最深切的，所以往往需要由 Infra 團隊來推動成本治理，構建 FinOps 體系的建設。這裏的路徑在跨部門的協同關係上反而是至下而上反方向的。
Infra 團隊就算找到對應的業務團隊，推動他們縮容、下架掉閒置的雲資源，往往由於沒有數據驅動或對降本增效清晰的認識而難以開展工作，最終會導致極其低效的降本增效，白白浪費 Infra 團隊工程師們寶貴的時間。
我們不妨換個思路拆解一下解決方案。首先需要明確，所有人都需要對降本增效負責，且需要劃分清晰的責任範圍。以該企業爲例，業務協同主要分爲三大類角色：
- 業務應用團隊：負責業務應用的具體研發
- 業務平臺團隊：負責爲業務應用提供通用業務能力
- Infra 團隊：爲以上團隊提供基礎設施
順着成本治理的至下而上的路徑，該企業劃分了成本治理清晰的權責範圍，以及通過構建不同視角的成本監控大盤構建統一的數據驅動成本洞察體系。
首先對成本資源感知距離最近的 Infra 團隊：
拿數據說話，驅動業務團隊優化。
通過集羣的 overview 整體視角的監控大盤，從集羣、各項雲資源、節點等視角，界定確定性的浪費資源，以及通過對各集羣資源使用的 breakdown 分析，找到成本問題的癥結所在。
對於業務平臺團隊，從業務預算、Quota 層面驅動業務成本優化。
每個業務也需要從財務層面做成本治理，這裏業務平臺團隊通過成本洞察的數據，結合財務的預算，形成統一的報表、監控。如預算超標，需要透傳分配 Infra 團隊根據 breakdown 數據，進行成本分析。
業務應用團隊，需要選擇科學可靠的成本優化手段。
作爲應用的研發，使用業務平臺、Infra 平臺，他們是對業務、代碼最瞭解的專家，也是需要平衡資源浪費與應用穩定性的最終負責人。在 FinOps 體系中，ACK 成本套件爲他們提供應用視角的監控大盤，清晰觀測自己應用資源、成本水位的同時，判斷收斂後的資源水位是否合理，以及對自身業務變化規律來制定科學的彈性策略以滿足動態資源的需求。
如何規劃資源 & 成本
有了以上的分賬、跨團隊協作的解決方案後，我們來看規劃難的問題。新業務上線需要規範流程，制定合理的容量規劃。而新業務、跑批任務等，經過上線前壓測，通過經驗值或成本套件資源畫像等只能推薦出科學的資源規格配置。
針對這個問題，在上線過程可以使用 ACK AHPA 等智能彈性策略來做到動態業務趨勢的智能資源調整。
每個業務都不應該無限申請成本。把成本、資源歸因到個人，同時也需要根據業務量、資源趨勢制定財務預算，以及成本 Quota 計劃。合理地進行成本控制。
部門、業務、個人的成本預算，應按應用使用比例分攤到集羣中的應用部署、Pod。該企業的做法主要是通過 namespace、給容器副本打業務 label 的方式進行映射。最終預算與歸因到對應業務後的實際成本花費進行比對。
成本控制方面也是通過 API 集成 ACK 成本洞察的成本數據後，細粒度到業務應用、個人來配置的成本超預算報警。
尋找穩定和成本間的平衡
最後，在真正進行資源優化過程中。平衡穩定性和成本浪費是非常重要的。
首先對於浪費發現，存在兩部分浪費：
- 首先需要發現確定性的浪費。完全沒有使用的網絡 SLB、EIP 等資源，長期空閒的節點等，這些可以通過 ACK 限制資源檢查找到這些確定性的浪費。
- 第二部分是非常普遍的，應用的資源浪費。雖然平均集羣資源利用率經過優化達到了約 50%。由於是容器化混合部署的應用在同一集羣中，應用的水位分佈也往往呈現長尾效應，穩定的大規模應用往往經過重點優化已經有較高的資源利用率，但大量小規模應用使用大量閒置資源，隱藏在整個集羣中難以發現。這裏可以通過拉取 ACK 成本洞察的 Pod 維度的成本資源數據，歸因浪費到具體應用/個人後，會使這些應用的碎片化浪費逐個暴露出來。
科學合理的 Quota 設置
對 K8s 有經驗的使用者，對 K8s 資源分配量(Request)、資源限制(Limit)兩個值應該會有深刻的理解。科學地配置工作負載的 Request 量可以幫助進行容量規劃控制資源成本，Limit 資源限制則可以實現混部的超賣和保證應用的穩定性。
通過統一 K8s 集羣上應用的 request、limit 設置規範，通過業務量壓測、預估經驗值，結合根據歷史資源使用量的 ACK 資源畫像智能推薦的 request、limit 值，該企業可以做到科學地爲各個應用設置合理 Quota，平衡業務穩定性和成本浪費。
合理地使用彈性策略
HPA 很先進，但激進的 HPA 配置會導致應用不符合預期地擴縮、甚至導致業務穩定性；保守的 HPA 配置可能會導致還是會有大量閒置資源，起不到太多成本節省的效果。
雲原生技術中例如通過業務指標進行 HPA、CronHPA 等都有各自適合的典型場景。在該企業中也有部分業務應用使用 HPA 策略。首先比較確定性的場景如週期性的業務，使用 CronHPA；同時，參考成本、資源監控數據優化閾值，通過HPA的歷史數據，保證資源的流轉效率。
在決定 HPA 的指標的選擇上，該企業會先區分 CPU 密集型的業務還是內存密集型的業務，根據調度的關鍵資源指標作爲 HPA 的決定值。在一些新的業務，沒有能參考的資源指標場景，也在使用 ACK AHPA 智能 HPA 策略，形成動態智能的彈性擴縮。
整個成本治理工作是一個複雜且綜合性的事務。經過近一年多，目前在 IT 成本上節省約 25% 的成本，超過月 10w+ 的成本節省，部分集羣資源利用率從 20% 提升至 50%。
在整個實踐的過程中，該企業也定義了資源流轉效率指標，一個業務應用通過彈性擴縮對新資源的使用率，來反映一個應用對資源的浪費程度，資源流轉效率越大代表越節約。目前經過IT成本治理，資源流轉效率有了 20% 的提升。“我們也希望通過本次分享我們在 IT 成本治理方面的工作經驗，幫助其他互聯網金融客戶等雲上客戶更好地建設 FinOps 體系。”
阿里雲 ACK FinOps套件助力容器成本數字化治理
阿里雲 ACK 團隊希望提供真正能幫助用戶在容器場景構建 FinOps 體系的產品能力。在深入溝通、瞭解企業對於容器成本治理的需求和問題後，我們總結出通用的三大 FinOps 治理流程：成本洞察、成本優化、以及成本控制。
在成本洞察中，ACK FinOp 套件提供多維度視角，幫助用戶把集羣中業務成本歸因到組織和個人。成本洞察能力經過更多客戶場景的打磨，推出更科學的分賬算法，同時目前支持通過 API 讓客戶進行二次開發，以及如極氪汽車等多雲場景我們支持多雲成本適配器，幫助多雲、IDC 機器混合等場景下成本治理保持統一。
在成本優化中，我們提供資源畫像功能，智能推薦應用優化配置，並通過 Koordinator 在離線混部組件進一步提升資源利用率。以及提供 CronHPA、 AHPA 等豐富的自動彈性擴縮容策略。並提供智能資源浪費巡檢。
在成本控制階段，ACK 將提供成本洞察大盤週報功能，直接抄送成本週報至對應業務團隊更能推進團隊進行成本優化，並樹立 FinOps 建設意識，提供費用趨勢預測，幫助剛好地指定業務預算，最終進行成本控制。
看清成本、找出浪費，永遠是成本治理的第一步。ACK 成本洞察功能幫助用戶構建數據驅動的成本觀測能力。
ACK 成本洞察功能提供開箱即用的集羣成本大盤，實時計算出多維視角的集羣應用成本賬單，以及提供不同資源配型，如包年包月、搶佔式節點的橫向比較，以及推薦不同的節省策略。同時，下鑽到應用層的應用視角成本大盤，提供對應用浪費資源程度的 Top 排序，清晰明瞭發現混部隱藏在集羣中的應用浪費問題。
Infra 團隊和上層應用團隊需要按統一的口徑進行成本分賬。雲原生場景架構複雜，不同應用形態也會在混部場景中對調度資源產生影響。ACK FinOps 提供獨有的雲原生容器場景成本分攤與估算模型，通過衡量應用對調度的影響大小，更科學合理地對應用成本進行拆分。
多數用戶的應用可分爲兩種場景，如 JAVA、J2EE 部署的應用，多爲內存密集型場景，如跑批的分佈式計算任務，多爲 CPU 密集型場景，此類場景，CPU 或內存、甚至 GPU，會作爲集羣調度的關鍵資源，決定應用是否能被調度。此場景我們推薦單資源分攤模型，按關鍵資源進行分賬。
如一個典型場景，用戶在 ACK 集羣的 GPU 節點跑 spark 的跑批任務，GPU 資源是當前最影響調度的資源，所以該應用的成本，應該按當前應用運行時間內佔用的 GPU 資源來拆分整個節點的成本。
混部場景的用戶，作爲雲原生的深度用戶，一個集羣中會有內存密集型、CPU 密集型等多種應用混部，此時每種資源都決定調度策略，此時我們推出按資源調度水位計算的權重混合資源分攤模型，此模型計算一個應用應該分攤的成本，是由他所申請資源影響可調度資源的部分決定。
ACK 成本洞察可通過混合資源分攤模型，按每個應用對調度的影響，自動計算出合理的應用分賬成本。
看清了成本浪費後，雲原生容器場景下有複雜的架構體系，如何進行優化往往無從下手。
ACK FinOPs 成本套件梳理出 ACK 成本優化路徑落地的最佳實踐，幫助用戶在同步場景選型不同的成本優化方案。如業務應用經常波動的場景，可以通過感知業務的波動，選擇自動彈性策略、或通過混部場景的動態資源超賣等提高資源利用率。在不感知業務的情況下，可以檢查是否已經是最優的資源配型等。
確定性的浪費是我們首要需要找出來並收斂掉的。
真實生產環境中，Infra 團隊不敢輕易刪除集羣裏的資源，在此 ACK 成本套件推出閒置資源巡檢功能，幫助用戶找出集羣裏確定性的閒置資源。這裏通過找到處於未使用狀態的資源，但在出賬時卻被計入本集羣的成本的資源。
包括無業務應用使用的 雲服務器 ECS、塊存儲、負載均衡 CLB 和彈性公網 IP 的閒置檢查。
根據 FinOps 基金會的 2023 年報告，對雲資源的更大利用率使用，以及如何驅動工程師團隊採取優化措施是現在 FinOps 體系中最令人頭疼的問題。
在容器場景混部、動態的應用環境下，ACK 資源畫像功能可以提供基於應用歷史數據的智能資源配置推薦功能。
千人千面，在容器場景下是一應用一畫像。爲每個應用智能推薦升降配策略。解決應用剛上線、或應用業務波動大，無法正確容量規劃問題。資源畫像的核心技術點在於提供同時平衡過冗餘時的浪費且保證過度超賣的穩定性的推薦算法。我們的推薦算法主要考慮了以下 3 方面：
1. 使用多種資源維度進行統計，並使用類似分位數的統計方法區分應用突發峯值需求和日常資源需求。
2. 使用半衰期華東窗口模型，確保新的數據對算法模型的影響越大，越舊的數據對算法的影響越小。
3. 以及考慮了容器運行時狀態，參考容器的 OOM 等運行狀態，進一步提高推薦值的準確性以及保證穩定性。
用戶爲什麼要雲原生容器化，除了使用統一標準化的配置方式規範地使用雲資源，更大程度也是爲了享受集羣池化的資源帶來的資源利用率提升與系統穩定性的平衡。
HPA 彈性伸縮策略是 Kubernetes 技術生態對這一平衡的重要體現。ACK 容器服務提供豐富的 HPA 彈性策略，針對不同的場景。
- 標準的 HPA，主要解決的業務負載壓力波動比較大時，需要人工根據監控來不斷調整副本數的問題，實現自動擴縮容。
- VPA 垂直擴容 Pod 所在的節點，主要解決資源配額（Pod 的 CPU、內存的 limit/request）評估不準的問題。
- 非常實用的如上文企業面對的週期性波動的應用場景，使用 CronHPA，定時水平擴縮容。基於可預期的時間，提前規劃擴縮容 Pod 數。主要解決在可預期的時間，資源不足的問題。
同時我們也提供一些領域垂直的彈性伸縮解決方案，如業務事件驅動的 Keda、以及 Serverless 場景支持如灰度發佈等場景的 knative 等領域彈性伸縮解決方案。
HPA 的配置確實需要根據應用具體場景，如是否波動，來決定具體選擇哪種 HPA 解決方案，以及關鍵指標應該如何選擇等。很多同學看到這裏就知難而退了，這裏有太多的 HPA 策略，複雜的場景，難以規劃的閾值參數，需要豐富的 K8s 經驗。現在 ACK 推出 AHPA 智能彈性策略功能，解決這個問題，也讓我們窺見了下一個階段 HPA 彈性策略的新形態。
AHPA 通過收集應用 Pod 的歷史數據，通過智能的週期檢查+預測算法，結合 ACK 專業的 K8s 應用部署經驗。
1. 通過資源提前預熱，解決 HPA 彈出滯後性的問題。
2. AHPA 自動配置閾值，智能識別業務指標曲線，無需人工干預，自動彈性規劃。
3. 支持配置彈性降級保護，快速兜底容錯。
1. AHPA 使用資源提前預熱的方法，根據智能算法提前預測將要發生的彈性對資源的需求，實時調整資源容量。正常客戶的 HPA 拉起新的 Pod，需要經歷如資源調度、拉取鏡像、等待容器啓動等耗時過程，AHPA 預熱後解決客戶彈性之後性的問題。
2. 通過歷史數據的智能預測，無需人工干預，自動規劃彈性策略、閾值，解決閾值配錯、不好配的問題；以及 AHPA 與標準 HPA 相比，更合理閾值的配置也解決了彈性的滯後性問題。
3. 對突發的業務流量收縮，支持配置彈性降級保護措施，避免過保守的 HPA 策略不能降本增效，過激進的 HPA 策略面對突發情況時會影響業務穩定性。在提升資源使用率的同時，保障業務的穩定性。
希望通過我們的分享，能夠幫助更多企業瞭解在容器場景下的企業成本治理現狀、挑戰，以及如何結合阿里雲容器服務 ACK 成本套件產品功能，構建企業自己的雲原生 FinOps 體系。
作者：行疾
本文爲阿里雲原創內容，未經允許不得轉載。