2026阿里云国际版DevOps（云效Apsara DevOps）实战教程：从代码托管到流水线部署全链路、四类资源USD价目与免费额度测算、VPC构建集群排障十个坑

Meta Description: 阿里云国际版DevOps（Apsara DevOps/云效）：Codeup+Flow+Packages三件套开通、Git存储$1/GiB与构建$0.005/核心分钟真实价目、免费额度能撑多久、企业协作模式$0.4/人/天怎么算、地域版没有默认构建集群的VPC构建集群配置与日志排障、三个场景成本测算与十个高频坑。

关键词：阿里云国际版DevOps、Apsara DevOps、云效、Codeup、Flow流水线、Packages制品仓库、阿里云国际版教程、CI/CD、VPC构建集群、核心分钟计费、企业协作模式

一句话结论：DevOps 是国际站上少数「开通不要钱、用起来按三张账单分开收」的产品——研发资源有免费额度兜底，真正决定月账单的是另外两项：流水线的核心分钟（按秒级累积、无上限）和用户许可（按天累积、$0.4/人/天）。一个 20 人的团队，许可费往往比存储费贵十倍；一个 CI 高频的团队，构建费又能反超许可费。本文把官方价目表和计费口径逐条拆开，给出可以直接照抄的选型与省钱结论。

一、DevOps 解决的是「提交到上线」之间的那段烂路

代码写完到服务跑起来，中间有一串必须有人做的事：拉代码、装依赖、编译、跑测试、打镜像、推仓库、改配置、重启服务、验证。团队小的时候这些事靠「某个人记得」，团队一大就变成三种事故：构建环境不一致（他机器上能跑）、发布过程不可追溯（谁在什么时候把什么版本发上去了）、回滚靠猜（出问题只能重新构建一次）。

阿里云国际站的 DevOps（文档里叫 Apsara DevOps，中文语境下就是「云效」的地域版）就是把这段路产品化。它不是一个工具，而是三个模块拼成的一条链：

三者之间靠「服务连接」打通：流水线通过服务连接去拉 Codeup 的代码、推 ACR 的镜像、连 ECS 主机或 ACK 集群。

一个必须提前知道的边界：国际站的 DevOps 只提供 Codeup、Flow、Packages 三个模块。项目协作（Projex）、测试管理（Testhub）、应用交付（AppStack）、效能洞察（Insight）这些在国内站能看到的模块，国际站不在支持列表里——官方在 CLI 文档里明确写了「国际站仅支持 Codeup、Flow、Packages」。所以如果你需要「需求-缺陷-迭代」的项目管理，得另找工具（Jira、飞书项目等），别指望 DevOps 一站包完。

二、开通前的两个硬约束，选错了要重建组织

很多人是先把组织建起来、代码传上去，才发现地域选错或者构建跑不起来。这两个约束必须在创建组织之前就确认。

2.1 组织只能建在中国大陆四个地域

地域版（Region-based）组织在创建时要求选一个 Region，官方列出的可选范围只有四个：

• 华东 2（上海）
• 华南 1（深圳）
• 华东 1（杭州）
• 华北 2（北京）

没有海外地域可选。 这对国际站用户是最容易踩空的一点：你的账号是国际站账号、账单是美元、支付用国际信用卡，但组织本身落在中国大陆。由此带来三个现实影响：

1. 访问链路：站点域名（公网域名或 VPC 域名）在中国大陆，海外团队点击、拉代码、看日志都会走国际链路，延迟和稳定性要提前实测，别等上线才发现 git clone 慢到影响开发。
2. 合规：代码、构建日志、制品都存放在中国大陆地域，涉及数据出境/跨境研发的团队要先过合规评审。
3. 配套资源要在同一地域：构建集群要关联你的 VPC，ACR、ACK、ECS 也最好在同一地域，否则跨地域访问要么走公网、要么配 CEN，成本和复杂度都上去了。

如果团队根本不在中国大陆、也压不动这条链路，那 DevOps 地域版就不是合适的选择，这属于「产品能力没错、但地理不匹配」，不要在配置上花时间硬扛。

2.2 地域版没有默认构建集群

这是国际站（地域版）和国内站中央版最大的行为差异，也是最常见的「第一条流水线必失败」原因。

官方原文的意思很直接：与中央版站点不同，地域版站点不提供默认构建集群，你必须先初始化一个 VPC 构建集群并关联 VPC，流水线才能跑构建。

也就是说，流程不是「建流水线 → 点运行」，而是：

创建 VPC 构建集群 → 关联 VPC / vSwitch / 安全组 → 选接入点 → 建流水线并指定该集群 → 跑空命令验证连通性 → 再接 ACR/ACK

跳过第 1 步直接建流水线，运行时会卡在「申请运行环境」（Request Runtime Environment）阶段报错——而这个报错看起来像权限问题，实际是「没有构建集群可用」。

2.3 还有一个账号层面的限制

DevOps 不支持虚拟运营商（虚商）账号直接开通或下单，企业成员账号如果是虚商账号或子账号，也无法完成订单。官方给的解法是：邀请一个已完成实名认证的普通阿里云主账号加入组织，把组织所有者权限转给它，由它来下单。如果你的账号是从代理商渠道拿的，先确认它是不是虚商账号，否则会在激活那一步卡住。

三、计费模型：一张账单拆成三类，各自独立

DevOps 地域版的账单分三类，互不抵扣、各自计量：

研发资源的四项计量定义很严谨，值得逐条看清，因为它决定了你怎么省：

注意两个不对称：Git 和 LFS 的回收站不计费，但制品回收站是计费的；构建资源只统计「用托管构建集群」的任务，用自有机器跑的不在这个口径里（后文第十节会用到这一点）。

3.1 真实 USD 单价

月单价按天折算的公式是官方给的：日单价 = 月单价 × 12 ÷ 365。所以 1 GiB 的 Git 存储日单价是 1 × 12 ÷ 365 ≈ 0.0328767 USD。

还有一个容易忽略的计费节奏：存储类资源每天上报一次、按天结算，所以每个月的实际费用会随天数轻微波动——同样 1 GiB 超量，1 月（31 天）比 2 月（28 天）贵一点点。做预算时按「月单价 × 超量 GiB」估算够用，不要去纠结那几美分。

3.2 核心分钟怎么算

官方公式：

核心·分钟 = 构建时长（分钟）× 构建环境 CPU 核数

例子：一个任务在 4 核机器上跑 10 分钟，消耗 10 × 4 = 40 核心分钟。

一个重要的免费细节：人工等待阶段（审批、确认）不消耗核心分钟、也不收运行费。只有在真正用托管构建集群做构建/编译时才开始计。这意味着——如果你的流水线里塞了「等待审批 2 小时」的卡点，不要担心它烧钱；反过来，也不要以为「流水线整体跑了 2 小时」就等于计费 2 小时，计费只看实际构建段。

3.3 组织多了额度不叠加

官方明确：同一个阿里云账号下建多个 DevOps 组织，研发资源额度是共享的，系统会把所有组织的用量汇总后再计费。但用户许可是按组织分别计量、分别出账。

这两条规则的组合结果是：多组织不会帮你「白嫖」多份 20 GiB 和 3,000 核心分钟；但如果你有 3 个企业协作模式组织，每个组织都会因为它自己的活跃人数单独收许可费——包括每个组织创建时就自动产生的那 1 个管理员。

四、免费额度到底能撑多久：四项逐项算

很多人看到「免费」就以为不花钱，实际上这四项额度的「体感」差异极大。

4.1 Git 存储 20 GiB：小团队够用，二进制一进来就爆

纯文本代码非常省：一个中等规模的后端项目全量历史通常在 100~500 MB。20 GiB 大约能装 40~200 个这样的仓库。

但只要仓库里混进二进制——设计稿、测试数据、模型文件、安装包、.jar、视频素材——体积会以数量级跳。一次不小心把 2 GB 的素材提交进去，历史里就永久留着它，git gc 也压不掉。

20 GiB 的现实容量：30 人以内、纯代码 + 少量小资源的团队，通常能撑住；一旦涉及大文件，一个月就能吃满。

4.2 LFS 20 GiB：单价便宜 5 倍，但要主动用

LFS（大文件存储）的单价是 Git 的 1/5（$0.2 vs $1）。这 5 倍价差是全文最直接的一个省钱杠杆：同样 50 GiB 大文件，放 Git 里是 50 × $1 = $50/月，放 LFS 是 50 × $0.2 = $10/月，差价 $40/月。

代价是 LFS 需要客户端支持（git lfs install + .gitattributes 声明规则），团队要统一配置。这是唯一一个「不做任何架构改动、只改流程就能省 80%」的动作，值得在项目一开始就定好规则。

4.3 制品存储 10 GiB：最容易在半年后爆的一项

10 GiB 听着不少，但制品是「只增不减」的：每次构建产出一个 jar/镜像层/前端包，默认全留着。一个日构建 10 次的中型项目，每个制品 50 MB，一天 500 MB，20 天就是 10 GiB。

而且制品回收站是计费的，所以「删了」不等于「不花钱」，要等回收站清空才真正释放。官方对这项的口径很明确：制品存储包含仓库回收站里的制品。

结论：制品必须配保留策略（保留最近 N 个版本 / 保留 N 天），否则这项的账单会在第 3 个月开始指数上升。

4.4 构建 3,000 核心分钟/月：先算「一个月能跑几次」

额度每月 1 日重置为 3,000 核心分钟。换算成构建次数，取决于你的构建规格：

这张表说明一件事：16 核以上的重型构建，免费额度几乎等于没有。如果你的镜像构建要 16 核跑 20 分钟（320 核心分钟），一个月只够跑 9 次——也就是每周两次。

所以「免费额度够不够」这个问题，正确的问法是：我每天跑几次、每次几核、跑多久。日构建 5 次 × 4 核 × 10 分钟 = 每天 200 核心分钟 = 每月 6,000，超出免费额度 3,000，多付 3,000 × $0.005 = $15/月。这个量级其实很温和，真正危险的是高频 + 高核（见第六节场景 C）。

五、用户许可：$0.4/人/天 的六个细节

企业协作模式的许可费是 USD 0.4 / 人 / 天，无人数上限。Personal 模式不收许可费，但最多 5 个账号、每个地域 1 个组织。

看起来简单的单价，实际有六个必须知道的细节，每一个都会让你的估算偏差 20% 以上：

细节一：创建组织当天就开始计费，不需要有人登录。 企业协作模式组织一建立，你在创建时提供的管理员账号和密码会被系统自动创建并加入组织，该账号从组织创建那一刻起就是「使用中」状态。所以组织一建好就至少按 1 个用户许可计费，$0.4/天。当天的费用出现在第二天的账单上。

细节二：只统计「使用中」状态的成员。 「未登录」「已禁用」「已删除」的成员不计费。听起来很宽松，但见细节三。

细节三：按当天峰值计。 每日用量按当天任意时点的活跃用户峰值计算。所以如果你在下午 5 点禁用一个成员，当天仍然按峰值收费，降下来的费用从第二天才生效。想省钱，「月中批量清理成员」的效果要延后一天才体现，别指望当天省。

细节四：多组织分别计量。 同一主账号下的多个组织，用户许可按各自组织的活跃人数分别测量、分别出账——不像研发资源额度那样共享。

细节五：费用记在主账号上。 组织所有者永远是阿里云主账号，不管组织是主账号建的还是 RAM 子账号建的，许可费都记在那个主账号的账单上。

细节六：Personal 模式的功能缺口不是「少一点」，是「少很多」。 两个模式的差异表值得完整看一遍：

这张表里最关键的一行是 VPC 访问。第 2.2 节说过地域版必须用 VPC 构建集群，而要按「VPC 域名」接入（也就是让构建机和站点之间不走公网），官方要求组织必须是地域版 + 企业协作模式。也就是说：

只要你想要「构建全程不出 VPC」这个安全形态，就绕不开企业协作模式，也就绕不开 $0.4/人/天的许可费。

Personal 模式只能用「公网域名」接入点，构建集群所在的 VPC 必须有 NAT 网关能出公网，并且要把 DevOps 的出口 IP 加进安全组白名单（注：中央版组织无法加具体 IP 白名单，地域版公网域名接入点可以配出向 IP 白名单）。

六、三个真实场景的月度成本测算

以下测算都用官方单价，按 30 天/月，仅算 DevOps 自身费用，不含 ECS/ACR/ACK/NAT 等配套资源。

场景 A：5 人初创团队，Personal 模式

这个场景的结论很乐观：5 人团队在免费额度内基本不花钱，唯一超的是 Git 存储。把 10 GiB 超量里的大文件迁到 LFS，月费用能从 $10 掉到 $2 左右。

场景 B：20 人研发团队，企业协作模式

两个反直觉的结论：

1. 许可费是最大单项（45%），比存储 + 构建加起来还多。20 人团队一年许可费 = 20 × 0.4 × 365 = $2,920，这笔钱和用量完全无关，只和人头有关。
2. Git 存储是第二大项，而且它是「历史累积型」——仓库建得越早、二进制提交越多，这项只会越来越贵，不会自己下降。200 GiB 里如果有一半是历史大文件，迁 LFS 能省下 100 × ($1 − $0.2) = $80/月 = $960/年。

场景 C：30 人团队，CI 重度（每日 150 次构建）

这个场景把成本结构彻底翻转了：构建费占 50%，许可费只占 20%。日 150 次构建（每次 8 核 5 分钟 = 40 核心分钟）意味着每天烧 6,000 核心分钟，免费额度 3,000 只够半天。

这就是第十节「成本优化」要重点处理的对象：构建是唯一一个「按行为付费、随团队效率线性增长」的项——团队越勤奋、提交越频繁、构建越细，账单越高。存储至少还有上限，构建没有。

6.4 三个场景放一起看

这张表是全文最重要的结论：不同规模的团队，省钱的重点完全不同。20 人团队去优化构建是徒劳（构建只占 19%），30 人 CI 团队去优化存储也不解决问题（存储占 30% 且难压缩）。先看自己在哪个象限，再决定动哪里。

七、从零跑通：组织、成员、代码库、服务连接、第一条流水线

7.1 激活服务并创建组织

1. 用阿里云账号（或拥有 AliyunRDCFullAccess 权限的 RAM 用户）登录 DevOps 控制台 devops.console.alibabacloud.com/organizations/standard。
2. 首次使用点击激活 Alibaba Cloud DevOps，按提示创建服务关联角色，再点立即激活。激活会创建一个按量付费订单，之后按实际用量出账。
3. 在页面顶部选择地域（只能选上海/深圳/杭州/北京），点创建组织。
4. 填四项关键参数：

• 组织名：可后续修改。
• 组织标识：决定访问域名和成员账号 ID 后缀，创建后不可改——这一项要想清楚再填。
• 协作模式：Personal 或企业协作。
• 管理员账号密码：初始 root 账号密码，可后续修改。

1. 创建完成后进组织详情页，这里能看到站点地址和出口 IP 地址（后面配安全组要用），也能进入成员管理和网络配置。

一个省事的登录方式：进组织后点「访问实例」，登录页上点阿里云图标可直接免密登录；管理员账号密码方式也行。

7.2 加成员：三条路，选一条

7.3 配角色：小心 Member 不是只读

组织角色是在 DevOps 内部配的，不是在 RAM 里配。预置角色有三类：全局管理员、模块管理员（代码管理员、项目协作管理员等）、成员（Member）。

这里有个坑：官方明确说预置的 Member 角色拥有创建数据（如代码仓库、项目）的权限。如果你的规范是「普通成员不能随便建仓库」，必须自建一个角色、只勾需要的权限点，不能直接发 Member。一个用户可以绑多个角色，最终权限是各角色权限点的并集。

7.4 代码库：新建或导入

1. 进代码管理 → 左侧代码库 → 直接新建，或点导入仓库迁移已有仓库（支持从其他代码平台迁移与同步）。
2. 建完后在成员设置里加开发者和管理员。组织里的普通成员可以被设为某个具体仓库的管理员。
3. 本地 Git 认证两种方式：

• HTTPS：账号密码从「个人设置」取。用账号密码登录的用户，Git 密码就是登录密码；用 RAM 用户或第三方身份源登录的用户，必须创建个人访问令牌（PAT）当密码用。
• SSH：配置 SSH 公钥。

1. Clone 地址在仓库详情的「克隆/下载」按钮里。

7.5 服务连接：把「连什么」和「怎么连」分开配

服务连接（Service Connection）是流水线里被引用的一层抽象，典型要建四类：代码仓库（Codeup / GitLab）、容器镜像（ACR）、云服务器（ECS）、Kubernetes 集群（ACK）。建好之后，编排流水线时直接引用服务连接，不用在每个步骤里重复填密钥。

这一步的价值在于「密钥只有一处」：换环境、轮换密钥、迁移集群，只改服务连接，不用动流水线定义。

7.6 部署目标：主机组 或 K8s 集群

按实际部署方式选：主机部署就建主机组（把 ECS 纳管进来），容器部署就接 Kubernetes 集群（ACK）。这两者决定了第八节里 ACR/ACK 连通性验证怎么做。

7.7 建第一条流水线

用流水线模板向导创建，跑通第一次构建与部署。但地域版请先做第八节的构建集群，否则模板建完也跑不起来。

八、VPC 构建集群：三种接入点、三步验证、一张日志对照表

这一节是整个产品最容易卡住的地方，也是「文档看了三遍还是跑不通」的重灾区。之所以难，是因为它同时涉及组织类型 × 协作模式 × 接入点 × 安全组 × NAT 五个变量。

8.1 两种构建集群，只能二选一

两者同一时间只能启用一种。构建机都是弹性的、用完释放，计算资源都由 DevOps 提供——差别只在网络资源归谁。

对国际站地域版来说，因为没有默认构建集群，你实际只有「用户 VPC 构建集群」这一条路可走（需要你自己准备 VPC / vSwitch / 安全组 / NAT）。

8.2 创建构建集群的三个关键配置

进 Flow 的构建集群管理页，新建，类型选 VPC 构建集群：

1. 基础信息：填名字，集群 ID 系统自动生成，复制下来备用。
2. 关联用户 VPC 与安全组：选构建机要部署进的 VPC 和 vSwitch，绑安全组。安全组必须放通构建机到以下目标的出向端口：DevOps 站点、ACR、ACK。如果 ACR/ACK 开了访问控制，把白名单指向这个安全组或该 VPC 的 CIDR。
3. 选接入点：这是最关键的一步，三种场景：

官方的选择建议很明确：安全优先选 VPC 域名（流量不出公网，安全组白名单可以按 IP 收紧），其次才是公网域名。

还有一个容易被忽略的边界：VPC 域名接入只对「地域版组织 + 企业协作模式」开放，中央版组织只支持公网访问。这又回到了第五节的结论——想要私网构建，就必须上企业协作模式。

同时记住一句官方说明：接入点只影响「构建集群 ↔ DevOps 站点」这一段链路。构建机访问 VPC 内的 ACR、ACK 永远走内网，跟接入点选什么无关。

8.3 开通 VPC 域名的操作路径

1. 组织详情页 → 网络配置 标签。
2. 勾选 启用 VPC 访问模式，点 添加 VPC。
3. 选 VPC、关联安全组与 vSwitch（至少关联一个 vSwitch，可以加多个保证可用性）。
4. 确定。之后 VPC 内的所有终端都能访问 DevOps 的 VPC 域名。

8.4 三步验证法（照着做，别跳）

这套验证法的价值在于每一步只验一条链路，失败时能立刻定位是哪一段不通，而不是对着一个「构建失败」盲猜。

第一步：验「构建集群 ↔ 站点」

建一条最小流水线，运行时构建集群选刚建的 VPC 集群，流水线源加一个 Codeup 仓库 + 一个 Packages 制品仓库（Codeup 一般有个 codeup-demo 示例库可直接选；Packages 仓库默认没有制品文件，要先随便上传一个文件，否则源是空的）。加一个「执行命令」步骤，命令可以留空——流水线运行时会自动下载流水线源，下载成功就说明代码克隆链路和制品下载链路都通了。

日志对照表（这张表是省时间的核心）：

第二步：验「构建机 ↔ ACR」

加一个 Docker 登录 ACR 步骤，选 ACR 的服务连接，填镜像仓库地址。这里必须填 ACR 的 VPC 访问地址（VPC 域名），不是公网地址。成功就说明构建机能通过内网访问 ACR，镜像推送链路可用。

第三步：验「构建机 ↔ ACK」

加一个 Kubectl 部署 步骤，选目标 ACK 集群，并填要部署的 YAML 文件在仓库里的相对路径（比如 deployment.yaml）。前置条件是把 YAML 先上传到仓库里。成功就说明构建机能通过内网访问 ACK 的 API Server 并完成发布。

两个常见失败：

三步都通过，才说明「构建 + 发布」整条链路的网络是通的，此时再把真实的构建和部署任务迁到这个构建集群上。

8.5 为什么要这么麻烦：一次配好，长期省事

这套配置的成本是一次性的（一个 VPC、几个安全组规则、一次域名开通），收益是长期的：

• 研发资产（代码、制品、镜像、集群）全部不需要暴露公网，攻击面直接砍掉一大块；
• 链路更短、延迟更低（同地域内网 vs 绕公网）；
• 安全组白名单可以按具体 IP/CIDR 收紧，而不是「对 0.0.0.0/0 放通某个端口」。

反过来说，如果团队规模很小、资产本来就跑在公网端点上，「直接走公网域名 + NAT」是完全可以接受的简化，不必为了架构洁癖先上私网。

九、流水线怎么设计：门禁、灰度、通知三件事

构建集群通了之后，真正决定这套东西「有没有用」的是流水线本身的设计。Flow 提供的原语不多，但组合起来能覆盖绝大多数场景，官方给的能力清单是这样的：

9.1 门禁：把「人工检查」变成「不通过就走不下去」

质量门禁的价值不是「多一道检查」，而是把检查从人的记忆里挪到流程里。Flow 里有两类：

• 自动校验：代码扫描、安全扫描、单元/自动化测试。规则是「不达标就阻断」，不需要人参与。
• 人工审批：需要人点确认的卡点。重点：人工等待阶段不消耗核心分钟、不收运行费（见 3.2），所以该加审批的地方放心加，不会因为「等了两小时」而多花钱。

一个务实的门禁组合（按拦截收益排序）：

1. 构建必须成功（最基础，失败即止）；
2. 单元测试通过率（挡住低级回归）；
3. 代码扫描无高危项（挡住硬编码密钥、SQL 拼接这类问题）；
4. 生产发布人工审批（挡住「手滑发生产」）。

前三条自动、第四条人工，是最小可用的门禁集。绝大多数团队的返工都源于「跳过了第 2、3 条直接上第 4 条」——审批人根本看不出测试有没有跑过。

9.2 发布策略：灰度比回滚便宜

官方支持灰度发布与分批滚动升级。这条能力的成本意义常被忽略：灰度是「用小流量换低风险」，它的成本是复杂度，不是钱；而全量发布的成本是「出事时的回滚时间 + 用户投诉」。

对成本敏感的阶段（比如场景 A、B 这种小团队），建议的取舍是：

• 有状态服务（数据库、缓存）→ 谨慎灰度，先做备份演练（可配合 混合云备份 HBR）；
• 无状态服务（API、前端）→ 直接分批滚动，把「一次全量」拆成「2~3 批」就够；
• 关键路径（支付、登录）→ 灰度 + 人工观察窗口，值得为它多花时间。

9.3 通知：不要让「构建失败」靠人刷页面发现

Flow 支持钉钉、邮件、站内消息推送构建结果和审批通知。这项配置的成本是 10 分钟，收益是「失败 30 秒内有人知道」。

配置原则：只推「需要人行动」的事件——构建失败、审批待处理、生产发布完成。把「每次都推成功消息」打开的结果是所有人一周内就把通知静音，等于没配。

9.4 分支策略：和门禁配套才有效

Codeup 提供分支策略、代码检测、合并评审、代码加密、定时备份。这些能力单独看都很普通，组合起来才能防住最常见的事故：未经评审的代码直接进主干。

最小可用配置：

• 主干（main/master）禁止直接推送，只能通过合并请求进入；
• 合并请求要求 至少 1 人评审通过 + 流水线通过（把 9.1 的门禁挂到合并请求上）；
• 发布分支打 tag，tag 与制品版本一一对应（这样出问题能精确回滚到某个制品，而不是「重新构建一次碰运气」）。

9.5 阶段划分：按「失败代价」切，不按「团队分工」切

一个常见的错误设计是把流水线按团队切成「前端流水线 / 后端流水线 / 运维流水线」，结果是没人对「整体能不能上线」负责。

更好的切法是按失败代价递增分阶段：

构建（秒级失败，无副作用）
  → 单元测试（分钟级失败，无副作用）
  → 代码扫描（分钟级失败，无副作用）
  → 打镜像并推 ACR（有副作用：产生制品，开始计制品存储）
  → 部署到测试环境（有副作用：占用资源）
  → 人工审批（不消耗核心分钟）
  → 生产灰度 → 全量（最高代价）

越靠前的阶段越便宜、越该多放检查；越靠后的阶段越贵、越该少而准。这条原则同时省钱和降风险：把检查前移，等于用「免费的核心分钟以内的时间」换掉「有副作用的生产事故」。

十、成本优化：五个真正有效的动作

按效果排序，从最省到最不省：

10.1 重型构建迁到自有主机组 / ACK Runner

官方对构建资源的计量口径是「所有使用托管构建集群的任务的构建核心分钟」。也就是说，把构建任务放到自有主机组或 ACK 上的 Runner 执行，就不在这个计费口径内——费用从「按核心分钟」变成「你自己的机器成本」。

对场景 C 这种日烧 6,000 核心分钟的团队，这几乎是唯一能砍掉一半账单的动作。但要注意三件事：

1. 自有机器要自己运维（打补丁、清磁盘、装工具链），隐性成本真实存在；
2. 弹性没了——高峰期要么排队、要么按峰值常备机器；
3. 是否仍产生其他费用，以实际账单为准，别只看一个计费项就下结论。

判断标准：构建核心分钟月费用 > 一台常驻构建机的月成本时，才值得迁。具体机器价格用 ECS 价格计算器按你的地域和规格实算（可参考 ECS 实例选型指南）。

10.2 大文件全部走 LFS

$1 vs $0.2，5 倍价差。规则很简单：能用 LFS 的绝不进 Git。在 .gitattributes 里把 .psd、.zip、.jar、.mp4、.onnx、.bin 这类扩展名全部指向 LFS，团队统一 git lfs install。

历史里已经提交的大文件，需要 git filter-repo 之类的工具重写历史（有风险，务必先全量备份、并通知所有成员重新 clone）。

10.3 给制品配保留策略

制品是「只增不减」的典型，而且回收站也计费。动作：按环境分仓库（生产制品长期保留、测试制品保留 7~14 天）、限制单仓库保留版本数、定期清回收站。

10.4 控制构建的「核数 × 次数 × 时长」

三个乘数里最容易降的是次数：

• 合并请求触发构建时，加路径过滤（只改文档就别构建）；
• 同一分支的连续提交合并构建（取消中间态）；
• 把「全量构建」拆成「增量构建 + 定时全量」；
• 把依赖（Maven / npm / PyPI）走 Packages 私库 + 本地缓存目录，避免每次构建都从公网重新拉一遍依赖——把 10 分钟的构建压到 3 分钟，等于省 70% 核心分钟。

缩短构建时长是性价比最高的优化：不需要改架构、不需要迁机器，改的是构建脚本和依赖来源，一次配置长期生效。而且它同时改善开发体验（等构建的时间少 70%）。

10.5 选对「什么时候上企业协作模式」

$0.4/人/天 = $12/人/月。这个价格买的是 SSO、VPC 访问、仓库备份、IP 白名单、ActionTrail 审计。判断逻辑：

• 需要私网构建 / 审计合规 → 必须上，没得选（这是功能门槛，不是成本决策）；
• 只是团队人数超过 5 个 → 可以先算一下：10 人 = $120/月。如果只是为了「多人协作」，而代码资产不敏感、也不需要审计，那这 $120/月买的是「合规叙事」而不是「能力刚需」——这时候更该问的是「我们真的需要企业级流程吗」，而不是「怎么把这 $120 省掉」。

十一、CLI 与自动化：PAT 而不是 AccessKey

DevOps 的 CLI 有个和其他阿里云产品完全不同的地方：它不用 AccessKey，也不用 aliyun configure 的 profile。官方原话是 Yunxiao 不使用 profile（AccessKey 对）存凭据，而是用云效控制台创建的个人访问令牌（PAT），通过环境变量或命令行参数传入。

11.1 装插件

云效的 OpenAPI 不是主 CLI 内置的能力，要先装一个独立插件：

aliyun plugin install --names aliyun-cli-devops

装完立刻验证，确认子命令 devops 已经挂上：

aliyun devops version
aliyun devops --help

11.2 配凭据（推荐环境变量）

export ALIBABA_CLOUD_YUNXIAO_ACCESS_TOKEN=<your-personal-access-token>
export ALIBABA_CLOUD_YUNXIAO_API_BASE_URL=<your-api-base-url>

不想用环境变量，也可以每次传参：

aliyun devops flow-get-flow-tag-group --id 0 \
  --api-base-url=<your-api-base-url> \
  --yunxiao-access-token=<your-personal-access-token>

11.3 五个常用命令

列出代码库并分页（--per-page 上限按文档给的值用，不要写 1000）：

aliyun devops codeup-list-repositories --page 1 --per-page 20

只取需要的字段。--cli-query 是 JMESPath，脚本里非常有用，能让输出直接变成可 jq 的结构：

aliyun devops codeup-list-repositories --cli-query 'result[].{name:name,id:id}'

列流水线：

aliyun devops flow-list-pipelines --page 1 --per-page 20

查流水线标签组详情（--id 0 是默认标签组，第一次探接口时最好用它确认连通性）：

aliyun devops flow-get-flow-tag-group --id 0

11.4 PAT 的四条安全规则

官方在文档里给了很明确的警告，值得照抄：

1. 按最小权限申请，并设合理有效期，不要建永久令牌；
2. 令牌只在创建时显示一次，之后无法再次查看，必须当场保存；
3. 不要把令牌明文写在命令行里，优先用环境变量（明文会进 shell 历史）；
4. 一旦泄露，立刻删除。

另外 PAT 不只能调 API，也能用于 HTTP 方式的 Git 操作——这就是 7.4 节里「RAM 用户登录时 Git 密码要用 PAT」的原因。

11.5 AI 助手怎么计费

DevOps 的 AI 助手用的是 AI_Credits，底层是 STAROps 的 agent，单价与 STAROps 一致，但在账单里是独立计费项。要点：

• 纯按量付费，目前没有资源包；
• 首次使用送 5,000 credits，有效期 31 天；
• 这个额度不与 STAROps 自己的免费额度或资源包共享，是单独算的；
• 管理员可以在管理后台的 AI 用量 页看消耗。

如果你打算把 AI 助手接进日常流程，先看清它的信用点消耗速率再放开用——它和研发资源是两条完全独立的账单线。

11.6 账单在哪里看

阿里云控制台 → 费用与成本 → 账单详情，选时间范围，筛 DevOps 的费用记录。

有个坑：DevOps 按地域分别出账。如果某些按量项在账单管理里找不到，要回到 DevOps 管理后台切换地域（比如杭州、北京）逐个查——计费资源可能落在某个具体地域上。

十二、十个高频坑（按踩到的概率排序）

第 10 条值得单独展开，因为它是唯一「不可挽回」的一条：

官方特别警告：组织被释放后研发数据无法恢复，包括项目、代码库、流水线、制品库、测试用例库。而且停服是立即的，不是常见的「欠费 7 天宽限期」——如果开了停机延期服务，才会按该服务规则延后。

这意味着 DevOps 不该放在一个「余额靠人盯着」的账号上。 开自动充值、设余额告警，或者干脆把它放在独立的主账号下并保证余额充足。

十三、总结

把这篇压成五句话：

1. DevOps 卖的是「把断点连起来」：Codeup + Flow + Packages 三件套，配合服务连接打通代码、镜像、主机、集群。国际站只有这三块，项目管理得另找工具。
2. 两个前置硬约束决定成败：组织只能落在中国大陆四个地域；地域版没有默认构建集群，必须先建 VPC 构建集群。这两个都是「建完才发现」的错误，必须在动手前确认。
3. 账单是三类分开算的：研发资源（有免费额度）、用户许可（$0.4/人/天，创建即计费）、AI 助手（独立 credits）。研发资源额度按账号共享，用户许可按组织分别计量。
4. 成本结构随规模翻转：5 人团队最大成本是 Git 存储，20 人团队是用户许可（45%），30 人 CI 重度团队是构建核心分钟（50%）。先判断自己在哪个象限，再决定优化什么——在错误的象限做优化，投入全打水漂。
5. 省钱的三个杠杆按性价比排序：大文件迁 LFS（省 80%，只改流程）→ 构建缓存与触发过滤（省 50%+，不改架构）→ 重型构建迁自有 Runner（省一半构建费，但要接手运维）。而企业协作模式的 $0.4/人/天 不是成本决策，是功能决策——要私网和审计就绕不开。

如果你还没把账号和基础资源准备好，先看 阿里云国际版注册教程 和 优惠码与代金券攻略；构建产物要推进的镜像仓库看 ACR 容器镜像服务实战；部署目标集群看 ACK 容器服务实战教程 与 ACK 成本优化；构建机选型参考 ECS 实例选型指南；上线后要监控发布效果看 ARMS 应用监控 和 SLS 日志服务。

• 想把构建产物推到镜像仓库？ACR 容器镜像服务实战教程
• 要部署到 K8s？ACK 容器服务实战教程
• 不想管 K8s、想直接跑应用：SAE Serverless 应用引擎实战
• 构建机和部署机器怎么选：ECS 实例选型指南
• 发布后怎么做可观测：ARMS 应用监控实战
• 还没开通国际版账号？阿里云国际版注册教程（免实名 + 支付宝）
• 想先把预算压下来：优惠码与代金券攻略
• 官方原文：DevOps 计费说明（地域版）、地域版组织快速入门、VPC 构建集群与连通性验证、云效 CLI 安装与初始化

🚀 需要海外云服务器？通过 2.chengzicloud.cloud 购买享专属折扣

⚠️ 免责声明：本文价格、额度与规则来自阿里云国际站官方文档在撰写时的公开内容，单位为美元（USD），不含 ECS、ACR、ACK、NAT 网关、公网流量等配套资源费用，也不含折扣与代金券；阿里云可能随时调整价格、地域覆盖与产品能力，下单前请以控制台与购买页实际显示为准。文中成本测算基于假设的业务规模，仅用于演示选型方法，不构成任何投资或购买建议。

本文由 2.chengzicloud.cloud 提供，点击访问首页了解更多