Harness 从入门到精通

一句话总结：Harness 是一个 AI 原生的端到端软件交付平台（Software Delivery Platform），覆盖从代码提交后的构建、测试、部署、验证、安全、成本管理到运维的全生命周期，将生成式 AI 深度融入 DevOps 每一个环节。

目录

• 第一部分：入门篇
  • 1.1 什么是 Harness
  • 1.2 为什么需要 Harness —— 传统 DevOps 的痛点
  • 1.3 Harness 的核心设计理念
  • 1.4 快速上手：永久免费版注册
• 第二部分：架构篇
  • 2.1 控制平面 + 执行平面
  • 2.2 Delegate 代理机制详解
  • 2.3 Pipeline as Code 与声明式 YAML
  • 2.4 连接器、模板与知识图谱
• 第三部分：模块篇
  • 3.1 CI —— 持续集成
  • 3.2 CD —— 持续交付与 GitOps
  • 3.3 CCM —— 云成本管理
  • 3.4 FF —— 功能标志
  • 3.5 CE —— 混沌工程
  • 3.6 STO —— 安全测试编排
  • 3.7 SSCA —— 软件供应链安全
  • 3.8 SRM —— 服务可靠性管理
  • 3.9 IDP —— 内部开发者门户
  • 3.10 IaCM —— 基础设施即代码管理
• 第四部分：AI 篇
  • 4.1 Harness AIDE —— 贯穿全流程的 AI 助手
  • 4.2 持续验证与自动回滚
  • 4.3 知识图谱与预测式交付
• 第五部分：实战篇
  • 5.1 金丝雀部署与自动回滚
  • 5.2 开发环境自动休眠与唤醒
  • 5.3 金融科技灰度发布优化（案例）
  • 5.4 跨国电商多云部署（案例）
• 第六部分：进阶篇
  • 6.1 与主流工具对比
  • 6.2 部署模式与生产级实践
  • 6.3 安全加固与合规治理
  • 6.4 多阶段流水线高级设计
• 第七部分：精通篇
  • 7.1 适用与不适用团队
  • 7.2 落地策略与迁移路线图
  • 7.3 常见陷阱与最佳实践
  • 7.4 2026 年展望与 AI 速度悖论
• 附录：参考资源

第一部分：入门篇

1.1 什么是 Harness

Harness由 Jyoti Bansal（AppDynamics 创始人）于 2017 年创立，总部位于美国旧金山。它的定位是“AI for Everything After Code”——聚焦代码编写完成之后的每一个环节。

Harness 不是一个简单的 CI/CD 工具，而是一个一体化的智能软件交付平台，将以下能力整合在统一控制面之下：

• 持续集成（CI）与持续交付（CD）
• GitOps 声明式部署
• 功能标志与渐进发布
• 安全测试编排
• 混沌工程
• 云成本管理（FinOps）
• 服务可靠性管理（SLO / Error Budget）
• 基础设施即代码治理
• 内部开发者门户

截至 2026 年，Harness 在 GitHub 上已获得超过 34,000 颗星，被 Workday、美联航、晨星等大型企业采用。

1.2 为什么需要 Harness —— 传统 DevOps 的痛点

传统 DevOps 工具链通常由多个工具拼装而成（Jenkins + ArgoCD + Grafana + Vault + …），这带来了以下痛点：

Harness 的核心价值，就是把这些缝合层平台化，减少团队维护"胶水"和"脚本"的负担。

1.3 Harness 的核心设计理念

Harness 围绕三大设计逻辑构建：

（1）声明式与 GitOps 优先

• 所有构建与部署管道使用声明式 YAML定义
• 同时支持图形化拖拽配置和在 IDE 中直接修改 YAML
• 配置文件与代码库强绑定，天然实现Pipeline as Code

（2）持续验证与自动回滚（Continuous Verification）

• 部署后自动对接 Prometheus、Datadog、Splunk、Jaeger 等监控和日志系统
• 利用内置机器学习算法对指标和异常日志进行分析
• 发现异常时，秒级触发自动回滚，无需人工干预

（3）生成式 AI 助手（Harness AIDE）

• 构建故障自动诊断（分析日志堆栈，定位错误并给出修复建议）
• Pipeline YAML 自动生成（用自然语言描述需求，AI 输出规范 YAML）
• 安全漏洞自动修复（扫描出漏洞后自动生成修复 Diff）

1.4 快速上手：永久免费版注册

Harness 提供永久免费基础版，包含 CI/CD 和 CCM 等核心模块的免费额度：

1. 访问 https://harness.io/ 点击“Sign Up for Free”
2. 使用 GitHub / GitLab / Bitbucket 账号注册
3. 自动创建默认项目和组织
4. 按照新手引导创建第一条 Pipeline

官方文档：https://developer.harness.io/

第二部分：架构篇

2.1 控制平面 + 执行平面

Harness 采用经典的控制平面与执行平面分离架构：

┌──────────────────────────────────────────────────┐ │ Harness Manager（控制平面） │ │ - Pipeline 编排、策略、模板、仪表板 │ │ - 可视化编辑器 + YAML 编辑器 │ │ - Git 同步与版本管理 │ │ - SaaS 或自托管部署 │ └──────────────┬───────────────────────────────────┘ │ 仅出站 HTTPS 通信 ▼ ┌──────────────────────────────────────────────────┐ │ Harness Delegate（执行平面） │ │ - 轻量级代理，运行在客户 VPC/集群内 │ │ - 执行构建、部署、验证等实际操作 │ │ - 无需开放入站端口（Pull 模式轮询任务） │ │ - 支持 Kubernetes / 虚拟机 / 容器部署 │ └──────────────┬───────────────────────────────────┘ │ ▼ ┌──────────────────────────────────────────────────┐ │ 目标环境（K8s / VM / 云资源等） │ └──────────────────────────────────────────────────┘

2.2 Delegate 代理机制详解

Delegate 是 Harness 架构中最关键的执行组件，也是落地时"绕不过去的一环"。

核心特性：

• 轻量级：一个 JAR 文件或 Docker 镜像，资源占用极低
• Pull 模式：Delegate 主动向 Harness Manager 轮询任务，无需开放入站端口，天然符合企业安全策略
• 集群化部署：可部署多个 Delegate 实现高可用，支持自动扩缩容
• 隔离性：每个环境（Dev/Staging/Prod）可部署独立 Delegate，实现权限隔离
• 连接器管理：通过 Connector 安全接入各类外部系统（Git 仓库、Docker Registry、K8s 集群、云服务商等），凭据加密存储

Delegate 工作流程：

1. Delegate 启动 → 注册到 Harness Manager 2. Manager 分配任务 → Delegate 拉取任务 3. Delegate 执行（构建/部署/验证） → 实时上报状态和日志 4. 任务完成 → Delegate 等待下一个任务

2.3 Pipeline as Code 与声明式 YAML

Harness 的 Pipeline 采用声明式 YAML 定义，支持 Git 版本控制。一个典型 Pipeline 包含三层结构：

• Pipeline：顶层编排单元
• Stage：逻辑阶段（CI / CD / Approval / Custom）
• Step：具体执行步骤（Run / BuildAndPush / Deploy 等内置步骤）

Hello World 示例——一个 Go 项目的 CI 流水线：

pipeline:name:Go Build and Pushidentifier:Go_Build_and_PushprojectIdentifier:defaultorgIdentifier:defaultstages:-stage:name:Build and Testidentifier:build_and_testtype:CIspec:cloneCodefile:true# 自动克隆代码platform:os:Linuxarch:Amd64runtime:type:Cloudspec:{}execution:steps:-step:type:Run# 内置运行步骤name:Run Unit Testsidentifier:run_testsspec:connectorRef:docker_hub_connectorimage:golang:1.22command:|go test -v ./...-step:type:BuildAndPushDockerRegistry# 内置 Docker 构建推送name:Build and Pushidentifier:build_and_pushspec:connectorRef:docker_hub_connectorrepo:myorg/demo-apptags:-<+pipeline.sequenceId># 内置变量

高级特性：

• Stage 并行与条件执行：通过 DAG 依赖定义复杂的编排逻辑
• Input Set（输入集）：将变量提取为可复用的参数集
• Overlay（覆盖）：不同环境继承基础 Pipeline 并覆盖特定配置
• 内置表达式：<+pipeline.name>、<+artifact.tag>等内置变量简化配置

2.4 连接器、模板与知识图谱

第三部分：模块篇

Harness 平台目前包含十大核心模块，采用模块化设计，可按需启用。

3.1 CI —— 持续集成

3.2 CD —— 持续交付与 GitOps

3.3 CCM —— 云成本管理（FinOps）

Auto-Stopping 示例：开发/测试环境检测到下班后 30 分钟无请求 → 自动关停 K8s Pod 或虚拟机 → 第二天开发者发起请求 → 代理网关秒级唤醒并拉起容器。

3.4 FF —— 功能标志（Feature Flags）

• 无需重新部署即可在生产环境安全释放新功能
• 支持百分比灰度测试（1% → 10% → 50% → 100%）
• 即时熔断——出现问题一键关闭功能
• 支持 A/B 测试，自定义目标规则

3.5 CE —— 混沌工程（Chaos Engineering）

• 主动注入网络延迟、容器崩溃、CPU 飙高等故障
• 验证系统容灾能力和自愈能力
• 混沌实验可直接编排进交付流水线（CI 阶段注入故障 → 验证韧性 → 通过后才进入 CD）
• 与 LitmusChaos 深度集成

3.6 STO —— 安全测试编排（Security Testing Orchestration）

• 无缝集成 SAST、DAST、SCA、容器扫描等安全工具
• 自动去重并按照优先级呈现漏洞
• 安全测试结果嵌入 Pipeline 决策（高危漏洞可阻断部署）
• 2026 年新增AI 安全模块——专门检测和保护 AI 原生应用组件

3.7 SSCA —— 软件供应链安全（Software Supply Chain Assurance）

• 自动生成并验证SBOM（软件物料清单）
• 强制执行SLSA安全框架标准
• 制品签名与来源验证
• 合规审计追踪

3.8 SRM —— 服务可靠性管理（Service Reliability Management）

• 持续监控SLO（服务水平目标）与Error Budget（错误预算）
• 将服务健康度与交付管道直接联动
• 错误预算耗尽 → 自动冻结部署 → 强制团队先修复稳定性问题
• 与 Prometheus、Datadog、New Relic 等对接

3.9 IDP —— 内部开发者门户（Internal Developer Portal）

• 基于Backstage构建
• 提供微服务模板脚手架，开发者一键创建新服务
• 统一的服务目录和技术文档
• 支持开发者自服务模式

3.10 IaCM —— 基础设施即代码管理（Infrastructure as Code Management）

• 托管 Terraform / OpenTofu 流水线
• 云资源的自动化安全审计与合规部署
• 成本估算与漂移检测

第四部分：AI 篇

4.1 Harness AIDE —— 贯穿全流程的 AI 助手

AIDE（AI Development Assistant）是 Harness 自研的生成式 AI 助手，贯穿软件交付全流程：

AIDE 诊断示例：

当 CI 构建失败时，点击“Explain with AIDE”：

诊断结果：由于导入的 'github.com/gin-gonic/gin' 版本过旧， 与本地的 Go 1.22 泛型语法不兼容。 解决方案建议：在 go.mod 中升级 gin 框架版本或将 Go 编译版本降至 1.20。 一键修复代码 Diff： - go 1.22 + go 1.20

4.2 持续验证与自动回滚

Harness 的**持续验证（Continuous Verification）**是其核心竞争力之一：

部署新版本 │ ▼ [阶段 1] 10% 灰度 ──→ 自动拉取 Prometheus/Datadog 数据 │ 与历史基线对比 5 分钟 ├── ✅ 无异常 ──→ [阶段 2] 50% 灰度 │ │ │ ├── ✅ 无异常 ──→ [阶段 3] 100% 全量 │ │ │ └── ❌ 异常 ──→ 🚨 自动回滚 │ └── ❌ 异常 ──→ 🚨 自动回滚（秒级切换回旧版本）

验证数据源：Prometheus、Datadog、Splunk、New Relic、Jaeger、ELK 等。

4.3 知识图谱与预测式交付

Harness 自动构建一个软件交付知识图谱，记录每一次构建、部署、发布的关系和结果：

• 当前能力：为 AIDE 提供上下文支持，实现精准诊断
• 演进方向：基于历史交付数据训练预测模型
  • 提前识别代码提交风险
  • 预测部署成功率
  • 自动建议最优发布策略

第五部分：实战篇

5.1 金丝雀部署与自动回滚（完整流程）

1. 开发提交代码 → 触发 CI 构建 + 测试 2. 制品推送至 Registry → 触发 CD Pipeline 3. 阶段一：10% 流量 → 新版本 4. 启动持续验证（5 分钟分析窗口） ├── ✅ 无异常 → 自动扩大至 50% ├── 阶段二：50% 流量 → 新版本 │ ├── ✅ 无异常 → 扩大至 100% │ └── ❌ 异常（如 API 延迟超阈值 200ms）→ 立即回滚 └── ❌ 异常 → 立即回滚 (无需人工审批)

5.2 开发环境自动休眠与唤醒（Auto-Stopping）

工作时段（09:00-18:00）: Dev K8s Cluster: 正常运行，10 个 Namespace，50 个 Pod 下班后 30 分钟: Auto-Stopping 检测到无 HTTP 请求 → 自动关停所有非生产 Pod 云成本瞬间降低 60-70% 次日 09:00: 开发者发起第一次请求 → 代理网关检测到请求 → 秒级唤醒 K8s 资源 → 恢复正常服务

5.3 金融科技灰度发布优化（案例）

5.4 跨国电商多云部署（案例）

第六部分：进阶篇

6.1 与主流工具对比

6.2 部署模式与生产级实践

Harness Manager 部署模式

Delegate 生产级部署建议

# 高可用 Delegate 部署要点delegate:replicas:3# 多副本高可用resources:limits:cpu:"2"memory:"4Gi"scaling:minReplicas:2maxReplicas:10targetCPUUtilizationPercentage:70# CPU > 70% 自动扩容isolation:-name:prod-delegatenamespace:harness-prodenvironments:[production]# 生产环境独立 Delegate-name:dev-delegatenamespace:harness-devenvironments:[dev,staging]# 非生产环境共用

6.3 安全加固与合规治理

6.4 多阶段流水线高级设计

pipeline:name:Advanced Multi-Stage Pipelineidentifier:advanced_pipelinestages:# 阶段 1：CI —— 构建 + 测试 + 安全扫描-stage:name:CItype:CIspec:execution:steps:-step:# 并行执行单元测试（Test Intelligence 自动选择）type:RunTestsenableTestIntelligence:true-step:# 安全扫描（并行）type:Securitymode:orchestration# 编排模式统一管理多种扫描器scanners:[trivy,snyk,sonarqube]-step:# 构建 Docker 镜像type:BuildAndPushDockerRegistry# 阶段 2：混沌工程 —— 预发布环境注入故障-stage:name:Chaos Engineeringtype:Customwhen:pipelineStatus:Successspec:execution:steps:-step:type:ChaosExperimentexperimentName:network-delay-100msduration:5m# 阶段 3：CD —— 金丝雀 + 持续验证-stage:name:Canary Deploytype:CDspec:execution:steps:-step:# 10% 流量type:CanaryDeployinstancePercentage:10-step:# AI 持续验证 5 分钟type:Verifyduration:5mmonitoredServices:[api-gateway,user-service]-step:# 50% 流量type:CanaryDeployinstancePercentage:50-step:# AI 持续验证 5 分钟type:Verifyduration:5m-step:# 100% 全量type:CanaryDeployinstancePercentage:100# 阶段 4：人工审批（可选）-stage:name:Manager Approvaltype:Approvalspec:approvalMessage:"请确认生产环境全量发布"# 阶段 5：发布后监控（SRM 联动）-stage:name:Post-Deploy Monitortype:Customspec:execution:steps:-step:type:MonitoredServicesloCheck:true# 检查 SLO 未违规errorBudgetCheck:true# 错误预算足够

第七部分：精通篇

7.1 适用与不适用团队

7.2 落地策略与迁移路线图

阶段 1：试点（1-2 周） ├── 选择 1-2 个非关键服务 ├── 安装 Delegate ├── 从最简单的 CI Pipeline 开始 └── 验证效果，收集反馈 阶段 2：推广（1-3 个月） ├── 将 CD 流程迁移至 Harness ├── 启用持续验证 ├── 建立 Pipeline 模板库 ├── 接入 CCM 成本管理 └── 培训团队成员 阶段 3：深化（3-6 个月） ├── 启用安全测试编排（STO） ├── 接入混沌工程（CE） ├── 建立策略即代码治理体系 ├── 启用 IDP 开发者门户 └── 全量服务迁移 阶段 4：优化（持续） ├── 利用 AI 助手提升效率 ├── 根据数据优化构建性能 ├── 完善 SLO/Error Budget 体系 └── 探索预测式交付能力

7.3 常见陷阱与最佳实践

7.4 2026 年展望与 AI 速度悖论

AI 速度悖论（AI Velocity Paradox）

Harness 提出的核心洞察：AI 工具（如 Copilot、Cursor）大幅加快了代码编写速度，但交付管道仍然是碎片化的"人工密集型"环节。代码生成速度是以前的 10 倍，但部署、验证、安全扫描还是老样子——这就是"AI 速度悖论"。

Harness 的应对策略：将 AI 延伸到"代码之后"的全部环节，用 AI 代理自动化构建、测试、部署、验证和安全治理，让交付速度匹配上代码生成的速度。

2026 年关键方向

• 预测式交付：基于历史数据训练模型，提前识别代码提交风险
• 多智能体协作：AI Agent 自动生成 Pipeline、修复 Bug、管理 SRE 运行手册
• AI 安全：专门为 AI 原生应用设计的安全测试和防护模块
• 企业级 GitOps 晋级流程：增强的 GitOps 推广治理，统一管理大规模 Argo/Flux 环境

附录：参考资源

最后的话：Harness 代表的是软件工程从"被动脚本编写"走向"主动闭环智能体"的演进方向。它不只是一个工具，而是一种新的交付范式——让团队从维护零散的 DevOps 胶水代码，转向用 AI 驱动的智能平台自动完成软件交付。