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