大概从 2023 年开始我身边越来越多的运维同事开始把简历上的头衔从“DevOps 工程师”改成“平台工程师”。这不只是换名字。背后真正驱动这一轮变化的是像 Harness 这样的软件交付平台正在把原来靠人来推动的生产环境发布流程变成一套自带“智能大脑”的平台能力。很多人甚至用比较夸张的说法Harness 正在用平台工程谋杀传统 DevOps。我没那么极端但我确实在真实的生产环境里用它做过几次从零接管今天把这些观察和操作经验一次性说清楚。这篇文章适合谁正在为 CI/CD 工具选型发愁的架构师、天天被发布事故折腾的 DevOps 工程师、想把团队从“人肉运维”里解放出来的技术管理者。我会从 Harness 的底层逻辑讲起然后在第三、第四节给出可落地的操作步骤和踩坑记录。如果你也遇到过“发布前如临大敌发布后提心吊胆”的情况那这篇内容应该对你有用。1. 先搞清楚Harness 是什么凭什么接管生产环境1.1 如果只是一条流水线那它和 Jenkins 没区别很多朋友第一次打开 Harness 的控制台会有一个错觉这不就是个 CI/CD 工具吗有流水线、有步骤、有任务和 Jenkins 有什么区别这是最大的误区。Harness 的产品定位从来不是“让用户编排一堆命令”而是“把软件交付这个场景做成一个可感知、可治理、能自动决策的产品”。它给出的不是脚本框架而是服务、环境、基础设施、验证策略、回滚策略、治理规则这些领域对象。你用这些对象来建模一次发布而不是用 shell 去驱动一堆工具。这句话怎么理解我举个自己的例子。以前用 Jenkins 做一个 Java 服务的发布要在流水线里写 kubectl set image、写健康检查 curl、写等待时间再写如果失败就回滚的脚本。结果大概率是脚本越写越长分支判断越加越多最后根本没人敢改。用 Harness 的时候我不太需要去“写”这些逻辑只需要明确告诉平台我的服务叫什么、镜像在哪里、目标集群是哪一个、金丝雀先切多少流量、验证指标是什么、超时多长。剩下的判断和调度由平台完成。这本质上是一种声明式建模而不是命令堆砌。1.2 “智能大脑”到底有哪些组成Harness 说自己有 AI 能力不是营销话术。我从实际使用的角度把它拆成几个可感知的模块持续部署CD、持续验证CV、功能开关、云成本管理、SLO 管理和安全测试编排。其中和我关系最密切的是持续部署与持续验证的配合。部署阶段不只负责把 Pod 拉起来还会在发布后自动收集日志、指标、链路追踪和之前一段时间做基线对比。另一个容易被忽略的模块是治理层。Harness 支持在流水线中加审批节点也支持用策略即代码的方式把“生产环境不允许使用 latest 标签”“部署必须带监控告警规则”这类规则固化下来。这样无论谁去操作生产环境都必须走同一套安全边界。平台不是靠某一个炫酷功能取胜而是靠一整套“执行加决策加治理”的组合拳。1.3 它和“平台工程”的关系平台工程的核心主张是把基础设施和交付流程做成一个内部产品提供给研发团队使用。Harness 就是这个产品的交付层。它把最佳的部署实践封装成模板把发布入口统一成一个自助服务同时保留足够的可配置性给平台团队。于是你可以让一个初级开发在自助门户上点一个按钮把新版本部署到非生产环境而生产环境仍然由平台团队用审批和策略把关。这正好和“平台工程”要解决的问题对上了不是让每个人都变成 DevOps 专家而是让每个人都能安全、高效地完成发布。我以前总觉得“平台工程”是个概念词但真把 Harness 跑起来之后我发现它确实把很多经验性的东西产品化了比如金丝雀应该放多少流量、验证窗口应该观察多久、回滚触发条件是什么。这些东西沉淀在平台里比沉淀在某个资深工程师的脑子里可靠得多。2. 为什么说它在“谋杀”传统 DevOps2.1 传统 DevOps 的困境传统 DevOps 运动的伟大之处是把开发和运维之间的墙推倒了。但实践几年后大家发现一个新的问题为了做到“谁开发谁运维”每个团队都复制了一整套工具链从脚本、镜像到监控、告警重复造轮子风格还不统一。对一个上百人的研发组织来说这不是解放而是负担。DevOps 工程师每天都在解决重复的管道问题真正有价值的工作——容量规划、故障演练、架构评审——反而没时间做。Harness 这类平台出现后很多原本属于 DevOps 工程师的重复劳动被平台标准化了流水线模板由平台定义权限由平台统一治理回滚由平台自动执行。这时候你只讲一句“DevOps 会死”我能理解但实际上更准确的说法是传统 DevOps 这种“工具链保姆”角色在瓦解平台工程这个新角色在顶上。2.2 平台的“智能”和“自动化”分几个层次我习惯把 Harness 的能力分成四个层次来看执行自动化把 kubectl、helm、terraform 这些命令抽成内置步骤省去大量 shell 脚本。验证自动化发布后自动做健康检查、指标对比、日志分析而不是靠人盯着 grafana。决策自动化根据验证结果决定继续放量、暂停还是回滚这一步开始接近“智能大脑”。治理自动化把审批、策略、权限和成本约束挂到发布流程上让安全边界可重复。Harness 比较完整地覆盖了四层。尤其是第三层也就是“根据验证结果自动决策”这是它和传统 CI/CD 的分水岭。Jenkins 能执行脚本但不能在发布失败后根据监控数据自己判断要不要回滚。Harness 可以做到如果金丝雀发布后错误率超过阈值自动回滚并把原因和图表一起打包到告警里。这个能力一旦用起来发布流程的“人肉值班”属性就会明显降低。2.3 与传统 CI/CD 工具链的对照维度传统 Jenkins/GitLab CI 手工组合Harness 平台部署策略自己写脚本或插件内置滚动、蓝绿、金丝雀等多种策略健康验证手工加 sleep 和 curl基于指标、日志、追踪的持续验证回滚脚本里硬编码联动验证结果自动回滚权限治理依赖各插件的 RBAC内置 RBAC、审批、策略即代码环境管理写在变量文件里环境、服务、基础设施对象化建模成本视角基本没有云成本管理模块可对比发布前后成本变化这张表不是说 Jenkins 没有价值。在轻量场景、技术栈单一的地方Jenkins 仍然够用。但如果你的团队要支持几十条业务线面对多集群、多云、合规要求平台型产品在长期复杂度控制上的优势会越来越明显。这就像你可以用记事本写文档但当一个团队需要协同、审阅、版本管理的时候你终究需要一个更完整的系统。2.4 “谋杀”背后的真实信号标题里的“谋杀”当然是个夸张说法。真实信号并不是 DevOps 岗位消失而是“DevOps 的准入门槛和工作重心变了”。过去一个新人转行 DevOps第一件事可能是学会用 Jenkins 搭一条流水线会拉代码、会 build、会 scp 到服务器上。现在这些事平台都能做而且做得更稳。于是企业招聘时不再只看“会不会配 CI/CD”更看“能不能设计一套安全的交付路径”“能不能把发布风险量化”“能不能定义平台策略”。能吸收这个变化的人岗位价值会提升停留在“会点脚本、会点 kubectl”的人才会觉得被替代。平台没有杀死你它只是在逼你换一个姿势工作。3. 实操从零接管一个生产环境的完整过程3.1 明确要接管的范围和团队目标我建议不要一上来就追求“全模块”。先选一条相对标准的微服务流水线一个 GitLab 代码仓库、一个 Docker 镜像仓库、一个 Kubernetes 集群上的 test 环境。把这条路走通再扩展到生产。目标定成开发 Push 代码后自动构建镜像然后通过 Harness 部署到测试环境测试通过后人工审批进入生产生产先经过金丝雀验证验证失败自动回滚。这里有一个关键的取舍先画流程再上平台。不要还没想清楚发布审批链就急着去点控制台。我用半天时间画了一张“发布流程图”标清楚谁触发、谁审批、在哪个环节验证、失败怎么处理。后面配置 Harness 时基本就是把这个流程翻译到平台对象里速度非常快。3.2 安装 DelegateHarness 与生产环境的连接器Harness Delegate 是安装在你的集群里的一个常驻组件它负责执行平台下发的部署、验证、日志采集等任务。之所以这么设计是为了不让外部控制器直接暴露你的集群端口。Delegate 主动向外建立连接你只需要在网络策略里放行它到 Harness 的 API 端点和镜像仓库、Git 仓库等必要地址。如果目标集群已经用 Helm推荐用官方 Chart 来部署。下面这个命令只保留最核心的参数实际部署时请把版本号、namespace、资源配置一起考虑进去helm repo add harness https://harness.github.io/helm-charts helm install my-delegate harness/harness-delegate \ --namespace harness-delegate \ --create-namespace \ --set delegateNamemy-delegate \ --set accountIdYOUR_ACCOUNT_ID \ --set delegateTokenYOUR_DELEGATE_TOKEN \ --set managerEndpointYOUR_MANAGER_ENDPOINT装完以后在 Harness 的 Delegates 页面看到状态是 Connected就可以继续了。这一步如果失败八成都出在网络连通性、token 和证书这三个问题上。可以看 Delegate Pod 的日志也可以直接进到 Pod 里用 curl 测一下到 managerEndpoint 是否通得过去别在界面上反复重装。3.3 配置连接器、服务与环境接下来要配置 Connector也就是把外部系统接入平台。常见的有 Git 连接器、Docker Registry 连接器和 Kubernetes 连接器。配置时选择对应的地址、认证方式和 Delegate 作为执行入口。然后创建 ServiceService 里不写具体的部署脚本只维护“用什么镜像、怎么拉取、端口是什么”这类元数据。Environment 则描述“部署到什么位置”比如某集群的 namespace或者某云账号的 VM。这里我想强调一个理念Service、Environment、Infrastructure Definition 是分开的。同一个 Service 可以部署到 Dev、Test、Prod 三个环境环境变量通过 Override 机制覆盖。这种建模方式虽然比在 Jenkinsfile 里写变量要复杂一点但多环境规模化以后会非常省心。比如你在测试环境用 1 个副本生产环境用 8 个副本这些差异可以在环境层级管理而不需要复制两套流水线。3.4 设计流水线金丝雀发布加自动回滚流水线里生产阶段可以选择滚动更新、蓝绿部署或金丝雀发布。我的默认选择是金丝雀流量先切到 10%验证没问题再切到 50%最后切到 100%。这个比例可以根据服务的重要程度调整。重要服务甚至可以做 5% 到 25% 到 100% 的三段放量给验证留出更多时间内部低风险服务可以直接滚动更新减少发布耗时。具体配置步骤大致是添加生产部署阶段选择 Service 和 Environment。部署策略选 Canary设置流量比例10% 到 50% 到 100%。在每个放量步骤之后添加 Verify 步骤选择监控数据源和验证指标。例如用 Prometheus 数据源指标选 HTTP 错误率和 P95 延迟。设置验证失败时的动作自动回滚。设置超时时间比如每个验证步骤最多等待 10 分钟。配置完成后一次发布看起来就像平台先发布 10% 的 Pod等待 5 分钟采集数据如果错误率没有异常继续发布 50%如果异常提示拦截并自动回滚到上一个稳定版本。值班工程师要做的事从“看着控制台等结果”变成“收到通知后确认一下平台做了什么”。3.5 验证、观察和迭代上线第一周我建议打开每个阶段的发布日志把自动回滚的告警和人工判断做对比。很多时候平台触发的回滚会比人更早因为它能秒级读取指标。但也会出现误报比如某个非关键服务因为访问量极低流量波动异常这时候需要调整验证阈值或者评估窗口。等调整稳定后再逐步加入变更门禁、审批流、成本展示这些治理能力。注意不要第一周就加太多审批节点否则团队会抱怨发布变慢反而失去推进平台工程的动力。先把“自动化”和“安全回滚”这两件事做好让所有人尝到甜头后面加治理阻力会小很多。4. 常见问题与排错实录4.1 Delegate 一直显示 Not Connected这是我在生产环境遇到最多的一个问题。最常见的三种原因第一managerEndpoint 填的地址不对或者端口没放行第二Delegate 版本和 Harness 控制台版本不匹配导致心跳请求失败第三token 粘贴时多了空格、换行或者 token 已经过期。排查顺序建议先看 Pod 日志再检查网络直连到 managerEndpoint 是否通然后重新创建一个 token 更新配置。不要直接在 UI 上反复重装浪费时间比自己看日志多得多。另外如果你用了比较新的 Helm Chart注意 Node 版本和镜像仓库的拉取权限有些环境因为拉不到镜像Pod 一直 ImagePullBackOff看起来也像连接失败。4.2 自动回滚频繁误报低流量的服务是重灾区。假设一个服务一天只有几千个请求P95 延迟在大多数时候是几十毫秒偶尔因为 GC 抖动跳到几秒。如果你在 Verify 步骤里设置了固定的 300ms 阈值就会频繁误报。解决思路是不要只设绝对阈值要利用基线对比。Harness 的持续验证模块会根据发布前一段时间的数据建立动态基线再看当前窗口是否偏离。另外有些团队把验证失败一律设置为自动回滚结果半夜误报把灰度发布回滚了第二天重新发布又赶上了流量高峰。我的建议是非核心服务可以先“暂停放量并发出告警”由值班人判断核心服务再自动回滚。不要为了自动化而自动化回滚动作本身也有成本和风险。4.3 连接器权限和 Secret 管理用连接器去操作集群或代码仓库时很多服务账号权限给得太宽。比如用一个几乎有 cluster-admin 的 token 跑所有发布一旦 Delegate 被攻破或者配置出错影响面会很大。建议为每个环境创建专用 ServiceAccount按 namespace 做精细授权同时把所有密钥放进 Harness Secrets Manager 或者对接云 KMS流水线里引用 secret 变量而不是明文。还要注意环境变量优先级。Harness 里可以设置 Service 变量、Environment 变量和 Pipeline 变量如果理解成层级覆盖就很容易出现测试环境没问题、生产环境默认值不对的问题。我的习惯是 Environment 变量只放环境相关的差异项比如副本数、域名、告警阈值全局公共配置放 Service 变量。这样排错时思路清楚不会出现“变量到底被哪里覆盖了”的悬案。4.4 发布明明成功监控却看到错误率升高这种情况往往不是 Harness 的问题而是验证选错了指标或者选错了数据源。例如你选了一个只覆盖旧实例的 Prometheus 查询新实例的指标没有进入验证范围又或者日志收集有延迟验证窗口刚好卡在数据空缺期导致误判。我的经验是验证指标要和你的业务强相关。如果是一个 API 网关服务看 P95 延迟和 5xx 错误率如果是一个异步任务消费服务看消费延迟和重试次数。不要一个模板吃遍所有服务。把验证步骤做成可复用的模板的时候也一定要根据服务类型区分模板而不是所有人共用一个。5. 对 DevOps 工程师和团队的影响5.1 “谋杀”不准确准确的是职责上移平台工程没有杀死 DevOps。恰恰相反它把 DevOps 从“修复流水线”的泥潭里拉出来抬升到“设计交付平台”的位置。传统 DevOps 工程师身上那些琐碎工作——安装执行器、维护脚本、监控构建节点——正在被平台自动化。留下的、更高的那部分工作定义发布策略、设计安全边界、度量交付效率反而变得更加重要。所以如果你问我“Harness 是不是在谋杀传统 DevOps”我的回答是它谋杀的是“工具链保姆”和“脚本维护员”而不是“DevOps 文化”。恰好是平台给了 DevOps 一个真正向上游走的机会。那些天天说自己活太累、没时间想架构问题的同行或许可以先想想自己愿不愿意把重复劳动交出去。5.2 运维工程师怎么转型平台工程师如果你现在还在做主机的日常配置、手工执行发布命令建议尽早往三个方向靠第一把基础设施当代码来管理第二把可观测性当成产品来建设第三把流程沉淀成模板和策略。掌握 Harness 这类平台后你要关注的不是某个命令怎么写而是“服务发布的安全阈值是多少”“回滚的成功率是多少”“多环境配置怎么隔离”。具体可以做的事情先从自己负责的项目开始把一条手工发布过程用平台重写一遍把之前的 Jenkins 脚本拆解成部署阶段、验证阶段、回滚阶段尝试用策略即代码固化一条“生产环境禁止直接改 latest 标签”规则再去扩展 Harness 的其他模块例如功能开关、成本报告。做完这些你简历上写的不再是“会用 Jenkins”而是“设计并落地了软件交付平台”。5.3 小团队落地 Harness 的稳妥路线如果团队只有两三个人没必要一口气铺开全模块。我的建议路线阶段一只做 CD先把部署从手动变成平台自动配合手工审批阶段二加入持续验证和自动回滚把线上发布风险降下来阶段三再做治理和成本例如把多个团队的权限收紧、统一模板、通过报表观察成本变化。过程中最重要的是不要直接把所有环境切过去。先选一个非核心服务试运行跑两到三个迭代确认验证阈值和回滚策略稳定后再扩展到核心服务。平台工程落地从来不是上个系统就完成而是一条持续调整的曲线。特别是自动回滚策略必须在真实流量下反复打磨才能做到既灵敏又不误报。5.4 自动化不该抹掉人的判断力最后提醒一句平台越智能越要把人的判断力留在关键决策上。自动回滚、自动扩缩容、自动修复都很好但这些自动化规则都应该是人可以理解和修改的。如果一个团队把上层能力完全外包给平台自己对系统运行机制一无所知那一旦平台本身的模型或策略出了问题连排查方向都没有。我见过一个团队上了 Harness 之后非常依赖自动回滚慢慢连错误率变化的业务含义都说不清楚。后来有一次平台误判把正常发布回滚了整个团队手忙脚乱。这件事给我的触动很大自动化是杠杆不是替代。它放大你的能力同时也放大你对规则理解的深度。我在很多场合说过一句话Harness 最能改变我工作方式的不是自动化部署而是自动回滚。以前每次生产发布总有一个人在电脑前盯着监控我理解那种紧张。现在平台能在十几秒内发现异常并主动回滚值班人只需要复核平台的决策。第一次看到这个场景的时候我其实有点失落好像岗位的价值被替代了。但后来我意识到真正被替代的是那些可以重复、可以标准化、不该由人承担的动作。人类工程师的价值在于设计这个决策规则、定义安全的边界并保证平台不断变好。这也许才是平台工程带给 DevOps 最好的礼物让我们终于可以做点更有难度的事。最后再分享一个实际操作的小习惯无论平台多智能发布后我都会自己看一眼最近一条告警和回滚记录不是不信任平台而是为了持续校准阈值和策略。智能大脑也需要一个有经验的饲养员这个角色我觉得比传统 DevOps 更有意思。