CircleCI工作流成本审计

要解决的问题

CircleCI 账单里最隐蔽的浪费，往往不是跑失败的作业，而是长期在 large、xlarge 甚至 gpu 机器上跑着的作业——它们也许只利用了 10% 的 CPU，却按整台机器计费。人工审计每个 workflow 的资源配置既繁琐又容易漏掉分支级别的差异：默认分支可能跑在优化过的配置上，而临时分支还在用默认的大机器。

这个技能针对的就是这类配置漂移导致的超额支出：作业跑在过度配置的资源类别上，实际利用率却很低。

技能如何工作

核心思路分三步，每一步都基于 CircleCI 的公开接口，而不是猜测：

• 拉取 Insights 数据：通过 CircleCI Insights API 获取工作流、作业和机器使用情况的历史遥测数据。
• 匹配定价表：结合 机器类型定价表，把每种机器类型的实际使用量换算成成本，而不是只看"跑了多少次"。
• 识别过度配置：对每个作业的历史 CPU / 内存 利用率做分析，找出利用率长期偏低但机器规格偏高的作业，给出降级建议。

审计结果按 项目、分支、执行器类型 三个维度拆分成本，你能直接看出：

• 哪些分支在烧钱但几乎没人用
• 哪些执行器类型（如 machine vs docker）的成本占比异常
• 哪些作业的资源配置可以从 xlarge 降回 large 甚至 medium 而不显著影响运行时间

适用边界与注意点

• 依赖 CircleCI Insights API 的可用性和数据保留策略，历史遥测数据的深度有限，太早的运行记录可能查不到。
• 降级建议基于历史 CPU / 内存利用率，不含对构建时长影响的完整模拟；建议先在非核心分支上验证。
• 成本换算依赖内置的 机器类型定价表，价格变动后需要更新该表，否则审计结果会与实际账单有偏差。
• 不涉及自托管 runner 的定价分析，也不处理 Kubernetes 自定义执行器的内部计费逻辑。