最近在跟几个做云原生和 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等核心标签。可以使用云厂商的标签策略或 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 这样的工具提供了强大的自动化能力但背后的策略、文化和流程才是决定成败的关键。对于大多数团队而言不妨从建立标签规范、生成第一份分团队成本报告、以及手动执行一次闲置资源清理开始逐步构建起自己的成本优化体系。在这个过程中积累的数据和经验将成为你未来应对更复杂成本挑战的最宝贵资产。