最近在跟幾個做云原生和 FinOps 的朋友聊天大家普遍頭疼一個問題云賬單越來越看不懂成本像脫韁的野馬想優(yōu)化卻不知從何下手。每次看到賬單明細里那些看不懂的服務(wù)項和突增的費用都感覺像在給云廠商“交學(xué)費”。如果你也有類似的困擾那么今天聊的這家公司及其產(chǎn)品思路或許能給你帶來一些啟發(fā)。Sapiom 這家初創(chuàng)公司近期獲得了 3500 萬美元的 A 輪融資其核心業(yè)務(wù)就是幫助企業(yè)解決云成本失控的難題。他們不是簡單地提供一個監(jiān)控面板而是推出了三款針對性極強的成本優(yōu)化產(chǎn)品分別從資源調(diào)度、閑置資源回收和預(yù)留實例管理這三個最“燒錢”的環(huán)節(jié)切入。對于技術(shù)團隊和運維負責(zé)人來說理解這些產(chǎn)品的設(shè)計理念和背后的技術(shù)邏輯遠比知道融資新聞更有價值。本文將深入拆解 Sapiom 這三款產(chǎn)品的技術(shù)原理、可能的實現(xiàn)方式并探討我們自己在項目中可以借鑒的實踐方案。1. 背景與核心概念云成本優(yōu)化的挑戰(zhàn)與 FinOps在深入產(chǎn)品之前我們必須先理解問題所在。云成本優(yōu)化Cloud Cost Optimization不是一個新話題但隨著企業(yè)上云進程加深和業(yè)務(wù)復(fù)雜度提升它已從“可選動作”變成了“生存必需”。1.1 為什么云成本容易失控資源彈性與便捷性云服務(wù)的核心優(yōu)勢是按需取用、彈性伸縮。但這把雙刃劍也導(dǎo)致了資源的過度配置Over-Provisioning和“僵尸資源”長時間閑置但仍計費的實例、存儲卷、IP地址等的滋生。定價模型復(fù)雜云廠商提供了按需On-Demand、預(yù)留實例Reserved Instances, RIs、Savings Plans、競價實例Spot Instances等多種計費模式。選擇最優(yōu)組合本身就是一個復(fù)雜的優(yōu)化問題。組織與認知壁壘開發(fā)團隊追求快速交付和性能通常對成本不敏感財務(wù)部門能看到賬單總額但不理解技術(shù)細節(jié)運維團隊夾在中間缺乏有效的工具和權(quán)限進行精細化管理。微服務(wù)與動態(tài)環(huán)境在Kubernetes和微服務(wù)架構(gòu)下服務(wù)實例動態(tài)創(chuàng)建和銷毀資源歸屬模糊成本分攤Cost Allocation變得異常困難。1.2 什么是 FinOpsFinOps 是一種文化實踐和運營框架它通過工程、財務(wù)、業(yè)務(wù)和云技術(shù)團隊的協(xié)作實現(xiàn)云財務(wù)管理和成本優(yōu)化。其核心目標(biāo)是在保持速度和創(chuàng)新的同時獲得最大的云投資回報。FinOps 不是一味地削減成本而是讓花的每一分錢都物有所值。Sapiom 的產(chǎn)品可以看作是 FinOps 理念的工程化落地工具它們試圖將成本優(yōu)化從“事后看賬單”的被動模式轉(zhuǎn)變?yōu)椤笆轮锌筛深A(yù)、事前可規(guī)劃”的主動模式。2. 環(huán)境準(zhǔn)備與思路澄清在探討具體方案前我們需要明確本文接下來的內(nèi)容將聚焦于技術(shù)原理分析和自建思路。我們不會部署 Sapiom 的商業(yè)產(chǎn)品而是基于其公開的產(chǎn)品理念構(gòu)建我們自己的理解和技術(shù)實驗環(huán)境。2.1 實驗環(huán)境說明為了模擬成本優(yōu)化場景我們需要一個可以操控的云環(huán)境或本地模擬環(huán)境云賬戶可選用于真實數(shù)據(jù)一個 AWS、Azure 或 GCP 的測試賬戶啟用成本與使用情況報告Cost and Usage Report。本地模擬環(huán)境推薦用于原理學(xué)習(xí)Kubernetes 集群可以使用 Minikube、Kind 或 K3s 在本地快速搭建。監(jiān)控與度量工具Prometheus Grafana用于收集資源使用率指標(biāo)。自定義控制器/腳本我們將用 Python/Go 編寫一些簡單的控制器模擬優(yōu)化策略。核心依賴對 Kubernetes 基礎(chǔ)概念Pod、Deployment、HPA、Metrics Server有基本了解。熟悉一種云廠商的 CLI 工具或 SDK如 AWS CLI, boto3。編程語言Python 或 Go用于編寫自動化腳本。2.2 核心思路從“監(jiān)控”到“優(yōu)化”的閉環(huán)任何有效的成本優(yōu)化工具都遵循一個基本閉環(huán)度量Measure - 分析Analyze - 行動Act - 復(fù)盤Review。Sapiom 的產(chǎn)品無疑內(nèi)置了這樣的閉環(huán)邏輯。我們的實驗也將圍繞這個閉環(huán)展開。3. 產(chǎn)品一拆解智能資源調(diào)度器成本感知調(diào)度第一款產(chǎn)品 likely 是一個成本感知的 Kubernetes 調(diào)度器或工作負載放置優(yōu)化器。它的目標(biāo)是將 Pod 調(diào)度到成本最低的節(jié)點或區(qū)域同時滿足性能要求。3.1 技術(shù)原理剖析傳統(tǒng)的 Kubernetes 調(diào)度器主要考慮資源請求CPU/Memory、節(jié)點親和性、污點和容忍度等。成本感知調(diào)度器在此基礎(chǔ)上引入了節(jié)點成本作為一個重要的調(diào)度權(quán)重。成本數(shù)據(jù)源需要實時或定期獲取不同節(jié)點類型、不同可用區(qū)、甚至不同云廠商的價格信息。這部分數(shù)據(jù)可以通過云廠商的定價 API 或內(nèi)部維護的價格表獲得。調(diào)度策略在調(diào)度時計算候選節(jié)點的“綜合得分”綜合得分 f(資源利用率 成本權(quán)重 性能約束)。成本低的節(jié)點得分更高。與 Spot 實例結(jié)合尤其適用于混合使用按需實例和競價實例的集群。調(diào)度器需要感知 Spot 實例的中斷風(fēng)險并可能采取“打散”策略將無狀態(tài)服務(wù)優(yōu)先調(diào)度到 Spot 實例以節(jié)省成本將有狀態(tài)服務(wù)保留在按需實例上。3.2 自建簡易成本感知調(diào)度器示例我們無法修改 kube-scheduler但可以通過為節(jié)點打上成本標(biāo)簽Label并使用 Pod 的nodeSelector或nodeAffinity來實現(xiàn)簡單的定向調(diào)度。步驟1為節(jié)點標(biāo)記成本標(biāo)簽假設(shè)我們有一個集群其中節(jié)點node-01是昂貴的 GPU 節(jié)點node-02是廉價的通用計算節(jié)點。# 為節(jié)點打上成本標(biāo)簽 kubectl label nodes node-01 node-cost-tierhigh kubectl label nodes node-02 node-cost-tierlow步驟2創(chuàng)建優(yōu)先調(diào)度到低成本節(jié)點的 Deployment# low-cost-deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: nginx-low-cost spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: affinity: nodeAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 # 權(quán)重表示強烈偏好 preference: matchExpressions: - key: node-cost-tier operator: In values: - low # 優(yōu)先選擇 low 成本節(jié)點 requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/arch operator: In values: - amd64 # 必須滿足的硬性條件 containers: - name: nginx image: nginx:latest resources: requests: memory: 128Mi cpu: 100m這個例子很簡單真實的產(chǎn)品會復(fù)雜得多需要動態(tài)獲取價格、計算得分并可能以調(diào)度器插件Scheduler Plugin或調(diào)度器擴展程序Scheduler Extender的方式實現(xiàn)。4. 產(chǎn)品二拆解閑置資源檢測與回收器第二款產(chǎn)品 likely 是一個自動化資源回收工具。它持續(xù)掃描云環(huán)境識別并安全地清理未使用的資源如 unattached EBS 卷、空閑的負載均衡器、未關(guān)聯(lián)的公網(wǎng) IP、空的 S3 桶、長時間閑置的虛擬機等。4.1 技術(shù)實現(xiàn)關(guān)鍵點資源發(fā)現(xiàn)使用云廠商的 SDK 遍歷所有區(qū)域的所有資源。例如使用 AWS 的describe_volumes并過濾Stateavailable的卷。關(guān)聯(lián)性分析判斷資源是否“閑置”是關(guān)鍵。一個 EBS 卷可能沒有被附加到任何 EC2 實例但它可能保存著重要的備份數(shù)據(jù)不能直接刪除。因此需要分析資源標(biāo)簽、創(chuàng)建時間、是否由某個 IaC 模板管理等信息。安全策略標(biāo)記Tagging在刪除前先給資源打上“待回收”標(biāo)簽并保留一段時間如7天。通知Notification通過郵件、Slack 等通知資源創(chuàng)建者或團隊負責(zé)人。審批工作流Approval Workflow對于重要資源可以設(shè)置手動審批環(huán)節(jié)。排除列表Exclusion List保護關(guān)鍵資源如生產(chǎn)數(shù)據(jù)庫的存儲卷。自動化執(zhí)行在滿足安全策略后調(diào)用刪除 API。4.2 Python 示例檢測并標(biāo)記閑置的 AWS EBS 卷# cleanup_ebs.py import boto3 from datetime import datetime, timedelta, timezone def find_and_tag_unattached_volumes(): ec2 boto3.client(ec2, region_nameus-east-1) # 1. 查找所有可用狀態(tài)的卷 response ec2.describe_volumes(Filters[{Name: status, Values: [available]}]) for volume in response[Volumes]: volume_id volume[VolumeId] create_time volume[CreateTime] age_days (datetime.now(timezone.utc) - create_time).days # 2. 應(yīng)用策略創(chuàng)建超過30天且無特定保護標(biāo)簽的卷 if age_days 30: tags volume.get(Tags, []) tag_keys [tag[Key] for tag in tags] # 檢查是否已被標(biāo)記或受保護 if Protection not in tag_keys and CleanupStatus not in tag_keys: print(f標(biāo)記閑置卷: {volume_id} (已創(chuàng)建 {age_days} 天)) # 3. 打上待回收標(biāo)簽 try: ec2.create_tags( Resources[volume_id], Tags[ {Key: CleanupStatus, Value: PendingReview}, {Key: CleanupCandidateDate, Value: datetime.now().isoformat()} ] ) # 4. (可選) 發(fā)送通知到 SNS # sns.publish(...) except Exception as e: print(f標(biāo)記卷 {volume_id} 時出錯: {e}) if __name__ __main__: find_and_tag_unattached_volumes() print(掃描完成。請審查帶有 CleanupStatusPendingReview 標(biāo)簽的資源。)重要警告此腳本僅用于演示標(biāo)記邏輯。在生產(chǎn)環(huán)境中運行任何刪除操作前必須建立完善的備份、審批和回滾機制。5. 產(chǎn)品三拆解預(yù)留實例與 Savings Plans 優(yōu)化管理器第三款產(chǎn)品 likely 專注于預(yù)訂折扣計劃的管理與優(yōu)化。云廠商的預(yù)留實例RI和 Savings PlansSP可以提供大幅折扣最高達70%但購買不當(dāng)會導(dǎo)致“浪費”——即購買的預(yù)留容量未被充分利用。5.1 核心優(yōu)化策略覆蓋率分析Coverage Analysis分析當(dāng)前按需實例的使用情況計算如果購買 RI/SP有多少用量可以被覆蓋從而節(jié)省費用。建議生成Recommendation Engine基于歷史用量和預(yù)測模型建議購買何種類型標(biāo)準(zhǔn)/可轉(zhuǎn)換、多大規(guī)格、多少期限1年/3年的 RI/SP。交換與修改Exchange ModifyAWS 等廠商允許在一定條件下交換或修改已有的 RI。工具可以自動監(jiān)控 RI 的利用率如果發(fā)現(xiàn)某個 RI 利用率持續(xù)低下例如購買的c5.largeRI 但實際運行的是c5.xlarge實例可以建議將其交換為更匹配的型號。分賬與攤銷Amortization Chargeback將 RI/SP 帶來的折扣效益按照各團隊的實際用量進行公平分攤。5.2 實現(xiàn)思路與偽代碼這類工具嚴重依賴云廠商的 Cost Explorer API、RI/SP 購買建議 API 和用量報告。# ri_analyzer.py (概念性偽代碼) import boto3 import pandas as pd def analyze_ri_coverage(): ce boto3.client(ce, region_nameus-east-1) # 1. 獲取按需實例的使用詳情時間范圍、服務(wù)、實例類型等 # 使用 get_cost_and_usage 或 get_reservation_utilization response ce.get_reservation_utilization( TimePeriod{Start: 2024-01-01, End: 2024-01-31}, GranularityMONTHLY, Filter{Dimensions: {Key: SERVICE, Values: [Amazon Elastic Compute Cloud - Compute]}} ) # 2. 解析響應(yīng)計算總使用量、按需成本 total_hours ... # 從 response 計算 on_demand_cost ... # 3. 模擬購買建議 # 調(diào)用 get_reservation_purchase_recommendation recommendation ce.get_reservation_purchase_recommendation( ServiceAmazonEC2, AccountScopePAYER, LookbackPeriodInDaysTHIRTY_DAYS, TermInYearsONE_YEAR, PaymentOptionNO_UPFRONT, ServiceSpecification{EC2Specification: {OfferingClass: STANDARD}} ) # 4. 分析建議預(yù)計月度節(jié)省、覆蓋率、建議購買詳情 for rec in recommendation[Recommendations]: instance_type rec[RecommendationDetails][EC2InstanceDetails][InstanceType] monthly_saving rec[RecommendationDetails][EstimatedMonthlySavingsAmount] coverage rec[RecommendationDetails][UtilizationMetrics][...] print(f建議購買 {instance_type} RI, 預(yù)計月節(jié)省 ${monthly_saving}, 覆蓋率 {coverage}%) # 5. (高級) 對比現(xiàn)有 RI 利用率識別浪費 # 獲取當(dāng)前 RI 列表和其利用率 # 如果某個 RI 利用率 50%標(biāo)記為“優(yōu)化候選”這部分實現(xiàn)非常依賴具體的云廠商 API且邏輯復(fù)雜。商業(yè)產(chǎn)品如 Sapiom 的價值在于將多個云廠商的 API 抽象統(tǒng)一并提供直觀的可視化分析和一鍵操作。6. 常見問題與排查思路自建方案中的坑在嘗試實現(xiàn)上述任何自建優(yōu)化方案時你可能會遇到以下問題問題現(xiàn)象可能原因排查思路與解決方案成本感知調(diào)度導(dǎo)致 Pod 無法調(diào)度1. 所有低成本節(jié)點資源不足。2. 節(jié)點親和性/反親和性規(guī)則沖突。3. 成本標(biāo)簽未正確設(shè)置。1. 檢查目標(biāo)節(jié)點的資源容量和已分配量 (kubectl describe node)。2. 使用kubectl describe pod pod-name查看調(diào)度失敗事件。3. 驗證節(jié)點標(biāo)簽 (kubectl get nodes --show-labels)。4. 設(shè)置合理的weight和requiredDuringScheduling規(guī)則避免過于嚴格。自動化清理腳本誤刪重要資源1. 資源關(guān)聯(lián)性判斷邏輯有誤。2. 排除列表未覆蓋所有關(guān)鍵資源。3. 腳本在錯誤的環(huán)境如生產(chǎn)運行。1.黃金法則先標(biāo)記后刪除中間加入人工審批或長等待期。2. 為關(guān)鍵資源生產(chǎn)數(shù)據(jù)庫、核心服務(wù)添加統(tǒng)一的保護標(biāo)簽如Protectiontrue。3. 腳本必須區(qū)分環(huán)境通過環(huán)境變量或配置文件指定目標(biāo)云賬號和區(qū)域。4. 實現(xiàn)刪除前的“模擬運行”模式只輸出待操作列表而不執(zhí)行。RI/SP 購買建議與實際節(jié)省不符1. 預(yù)測模型基于的歷史數(shù)據(jù)不具代表性如季節(jié)性業(yè)務(wù)。2. 業(yè)務(wù)架構(gòu)發(fā)生重大變化如從 EC2 遷移到容器。3. 未考慮可轉(zhuǎn)換 RI 的靈活性。1. 使用更長的歷史數(shù)據(jù)如12個月進行分析。2. 結(jié)合業(yè)務(wù)規(guī)劃進行預(yù)測而不僅僅是歷史數(shù)據(jù)。3. 優(yōu)先考慮Savings Plans尤其是計算 SP它比標(biāo)準(zhǔn) RI 更靈活適用于 EC2、Fargate、Lambda 等多種計算服務(wù)。4. 從小額、短期承諾開始驗證效果后再擴大。成本數(shù)據(jù)延遲導(dǎo)致決策滯后云廠商的成本和使用報告CUR通常有至少24小時的延遲。1. 對于實時性要求不高的優(yōu)化如 RI 購買、月度報告使用 CUR 數(shù)據(jù)即可。2. 對于近實時調(diào)度可以結(jié)合 CloudWatch 等監(jiān)控服務(wù)的實時用量指標(biāo)進行估算但需注意估算誤差。3. 明確區(qū)分“實時優(yōu)化”和“財務(wù)規(guī)劃”兩種場景采用不同的數(shù)據(jù)源和策略。7. 最佳實踐與工程建議借鑒 Sapiom 這類產(chǎn)品的思路我們在自建或?qū)嵤┰瞥杀緝?yōu)化體系時應(yīng)遵循以下工程最佳實踐7.1 建立成本可見性文化標(biāo)簽Tagging策略標(biāo)準(zhǔn)化這是所有后續(xù)優(yōu)化的基礎(chǔ)。強制要求所有資源都必須有Owner、CostCenter、Environment(prod/dev/staging)、Application等核心標(biāo)簽?？梢允褂迷茝S商的標(biāo)簽策略或 IaC 工具如 Terraform來強制執(zhí)行。定期成本報告與復(fù)盤每周或每月向各團隊發(fā)送其所屬資源的成本報告并組織復(fù)盤會議討論異常增長和優(yōu)化機會。7.2 采用漸進式自動化從“報告”開始再到“建議”最后到“自動化”不要一開始就追求全自動刪除。先提供清晰的閑置資源報告和優(yōu)化建議讓團隊自己處理。建立信任后再逐步實施安全的自動化流程如自動標(biāo)記、通知后自動清理。為自動化操作設(shè)置“安全閥”任何自動化刪除或修改操作都必須有1) 人工審批流程開關(guān)2) 資源級別排除機制3) 操作審計日志和快速回滾能力。7.3 優(yōu)化策略分層快速見效層Quick Wins立即著手處理閑置資源清理、關(guān)閉未使用的開發(fā)環(huán)境、將存儲類型從高性能調(diào)整為低頻訪問。這些操作風(fēng)險低節(jié)省效果立竿見影。架構(gòu)優(yōu)化層Architectural評估是否可以使用 Serverless如 AWS Lambda、托管服務(wù)如 RDS來替代自我管理的 EC2 實例雖然單價可能更高但總體擁有成本TCO可能更低。采購優(yōu)化層Procurement在用量穩(wěn)定可預(yù)測的服務(wù)上系統(tǒng)性地采用 Savings Plans 和預(yù)留實例。這是節(jié)省的大頭但需要精細的數(shù)據(jù)分析和規(guī)劃。7.4 工具鏈集成將成本檢查納入 CI/CD在部署流水線中加入簡單的成本檢查步驟例如檢查 Terraform 計劃是否會創(chuàng)建沒有成本標(biāo)簽的資源或者是否會使用過于昂貴的實例類型。與監(jiān)控告警聯(lián)動當(dāng)某個服務(wù)的成本在短時間內(nèi)異常飆升時應(yīng)像 CPU 使用率飆升一樣觸發(fā)告警以便及時排查是業(yè)務(wù)正常增長還是配置錯誤、遭受攻擊。云成本優(yōu)化是一場持久戰(zhàn)而不是一次性的項目。它需要技術(shù)、財務(wù)和業(yè)務(wù)團隊的持續(xù)協(xié)作。像 Sapiom 這樣的工具提供了強大的自動化能力但背后的策略、文化和流程才是決定成敗的關(guān)鍵。對于大多數(shù)團隊而言不妨從建立標(biāo)簽規(guī)范、生成第一份分團隊成本報告、以及手動執(zhí)行一次閑置資源清理開始逐步構(gòu)建起自己的成本優(yōu)化體系。在這個過程中積累的數(shù)據(jù)和經(jīng)驗將成為你未來應(yīng)對更復(fù)雜成本挑戰(zhàn)的最寶貴資產(chǎn)。