Harness 教程 08：日志查看与故障排查：Execution History、Step Log、Delegate 日志与 Kubernetes 事件定位：国内网络环境落地版

一：教程定位

在前 7 篇教程中，我们已经完成了 Harness 平台环境搭建、CI/CD 流水线、代码触发、测试与制品管理、Kubernetes 部署、变量参数化，以及审批和定时触发。

从第 8 篇开始，我们重点解决一个初学者最容易遇到的问题：流水线失败后，应该从哪里看日志？如何快速判断失败原因？

很多团队刚开始使用 Harness 时，一旦 Pipeline 失败，就会只看到一个红色失败状态，但不知道该看哪一层日志：

是 Git 拉代码失败？ 是 npm install 失败？ 是单元测试失败？ 是 Docker build 失败？ 是 Harbor push 失败？ 是 Kubernetes 部署失败？ 是 Pod 启动失败？ 是 Service 不通？ 还是 Delegate 本身网络不通？

本文将通过一个完整的故障排查流程，帮助初学者建立 Harness CI/CD 的排障思路。

二：适合人群

本文适合：

DevOps 初学者 后端开发人员 前端开发人员 测试工程师 运维工程师 平台工程师 刚开始使用 Harness 排查流水线失败的团队

建议已经具备：

了解 Git 基础 了解 Docker 基础 了解 Kubernetes Deployment / Pod / Service 基础 已经能运行 Harness Pipeline 已经有 GitLab / Harbor / Kubernetes Connector 已经安装 Harness Delegate

三：学习目标

完成本文后，你应该能够：

在 Harness 中查看 Pipeline Execution History 查看 Stage、Step 的执行状态 查看 Step Log 并定位错误行 查看 Pipeline 运行参数和 Input Set 区分 CI 失败、CD 失败、Delegate 失败、Kubernetes 失败 通过日志判断常见错误类型 进入 Delegate Pod 查看 Delegate 日志 查看 Kubernetes Pod 日志和事件 查看 Harbor 镜像推送和拉取问题 查看 GitLab Webhook / Trigger 触发记录 故意制造构建错误并定位失败原因 形成企业可复用的故障排查 checklist

四：国内网络环境下的故障排查架构

在国内环境中，Harness 流水线涉及多个系统：

GitLab / Gitee ↓ Harness Trigger ↓ Harness Pipeline ↓ Harness Delegate ↓ CI 构建 Pod ↓ Harbor ↓ Kubernetes ↓ 应用 Pod / Service / Ingress

每一层都有可能出问题。

对应日志位置如下：

GitLab / Gitee： Webhook 发送记录、代码提交记录、分支记录

Harness： Execution History、Stage Log、Step Log、Trigger Activity

Delegate： Delegate Pod 日志、网络访问日志、连接器执行日志

CI 构建环境： npm install 日志、npm test 日志、docker build 日志、docker push 日志

Harbor： Repository、Artifact、Tag、Robot Account 权限、镜像推送记录

Kubernetes： Deployment 状态、Pod 状态、Pod logs、Events、Service endpoints

应用： /health 接口、业务日志、启动日志

国内网络还要额外关注：

企业代理 防火墙出站 443 Harbor 自签证书 GitLab 自签证书 Kubernetes 节点访问 Harbor CI Pod 访问 npm 镜像源 Delegate 访问 GitLab / Harbor / K8s API

五：Harness 中最重要的 4 类日志

1. Pipeline Execution History

Execution History 是流水线执行历史。

它能回答：

这条流水线什么时候运行的？ 是谁触发的？ 是手动触发、Git 触发还是定时触发？ 使用了哪个 Input Set？ 哪一个 Stage 失败？ 哪一个 Step 失败？ 失败耗时多久？ 是否可以重新运行？

进入路径：

Project → Pipelines → 选择 Pipeline → Executions

或者：

Project → Deployments / CI → Executions

不同 Harness 界面版本入口可能略有差异，但核心是找到 Pipeline 的执行记录。

2. Stage Log

Stage 是流水线阶段，例如：

CI Build Unit Test Security Scan Manual Approval Deploy Dev Deploy Prod

Stage Log 可以帮助你判断：

失败发生在哪个阶段 前置阶段是否成功 是否在审批阶段卡住 是否进入部署阶段 是否被 when 条件跳过

3. Step Log

Step Log 是最关键的日志。

具体错误通常出现在 Step Log 中，例如：

npm ERR! docker build failed denied: requested access to the resource is denied ImagePullBackOff kubectl rollout status timeout curl: connection refused SonarQube Quality Gate failed

排障时不要只看 Pipeline 红色状态，要点进失败 Step，看具体日志。

4. Delegate Log

如果 Step Log 中出现：

Delegate unavailable No eligible delegates found Failed to connect to GitLab Failed to connect to Harbor Failed to connect to Kubernetes Connection timeout SSL certificate problem

就需要查看 Delegate 日志。

常用命令：

kubectl get pods -n harness-delegate-ng kubectl logs -f deployment/firstk8sdel -n harness-delegate-ng

如果你的 Delegate 名称不是firstk8sdel，先查询：

kubectl get deploy -n harness-delegate-ng

六：故障排查的基本顺序

初学者排查 Harness 流水线失败，建议固定按照下面顺序。

第一步：看 Execution History，确认失败的执行记录 第二步：看失败 Stage 第三步：看失败 Step 第四步：看 Step Log 最后一段错误 第五步：判断错误归属：Git / npm / Docker / Harbor / K8s / Delegate 第六步：进入相关系统继续查看日志 第七步：修复配置或代码 第八步：重新运行失败的 Pipeline

不要一开始就进入服务器乱查。

正确方法是：先从 Harness Execution History 定位失败点，再进入对应系统深入排查。

七：准备一个用于排障演示的 Pipeline

本文使用一个 Node.js 示例项目。

仓库结构：

harness-demo-app/ ├── app/ │ ├── package.json │ ├── server.js │ └── server.test.js ├── docker/ │ └── Dockerfile ├── k8s/ │ ├── deployment.yaml │ └── service.yaml └── scripts/ ├── debug-context.sh ├── check-network-cn.sh └── collect-k8s-debug-info.sh

Pipeline 结构：

Pipeline: nodejs-debug-demo Stage 1: CI Build Step 1: Print Debug Context Step 2: Install Dependencies Step 3: Unit Test Step 4: Docker Build And Push Stage 2: Deploy Dev Step 1: K8s Rolling Deploy Step 2: Verify Deployment

八：添加调试上下文 Step

建议每条 Pipeline 的第一个 Step 都打印基础上下文，方便排查。

scripts/debug-context.sh

#!/usr/bin/env bash set -e echo "===== Harness Debug Context =====" echo "Pipeline Name: <+pipeline.name>" echo "Pipeline Identifier: <+pipeline.identifier>" echo "Execution ID: <+pipeline.executionId>" echo "Sequence ID: <+pipeline.sequenceId>" echo "Trigger Type: <+pipeline.triggerType>" echo "Triggered By: <+pipeline.triggeredBy.name>" echo "===== Git Context =====" echo "Branch: <+codebase.branch>" echo "Commit SHA: <+codebase.commitSha>" echo "Repo URL: <+trigger.repoUrl>" echo "Git User: <+trigger.gitUser>" echo "===== Env Context =====" echo "Environment: <+env.name>" echo "Infra Namespace: <+infra.namespace>" echo "===== Pipeline Variables =====" echo "app_name=<+pipeline.variables.app_name>" echo "image_tag=<+pipeline.variables.image_tag>" echo "deploy_env=<+pipeline.variables.deploy_env>" echo "namespace=<+pipeline.variables.namespace>"

在 Harness Run Step 中执行：

chmod +x scripts/debug-context.sh scripts/debug-context.sh

如果某些变量为空，不一定是错误。比如手动运行时，<+trigger.repoUrl>和<+trigger.gitUser>可能为空，因为它们只在 Git Webhook 触发时有值。

九：国内网络检查脚本

scripts/check-network-cn.sh

#!/usr/bin/env bash set -e echo "===== Check Harness SaaS =====" curl -I --connect-timeout 10 https://app.harness.io || true echo "===== Check GitLab =====" curl -k -I --connect-timeout 10 https://gitlab.company.com || true echo "===== Check Harbor =====" curl -k -I --connect-timeout 10 https://harbor.company.com/v2/ || true echo "===== Check npm mirror =====" curl -I --connect-timeout 10 https://registry.npmmirror.com || true echo "===== Check SonarQube =====" curl -k -I --connect-timeout 10 https://sonarqube.company.com || true echo "===== Check Kubernetes =====" kubectl get ns || true

用途：

确认 Delegate 或 CI Pod 是否能访问国内关键依赖 确认是否是网络问题 确认是否需要代理 确认是否是证书问题

在排查网络失败时非常有用。

十：故意制造错误 1：npm install 失败

1. 制造错误

修改app/package.json，加入一个不存在的依赖：

{ "dependencies": { "express": "^4.18.3", "not-exist-package-demo-xxx": "1.0.0" } }

提交：

git add app/package.json git commit -m "test: mock npm install failure" git push origin main

2. 运行 Pipeline

进入 Harness：

Pipeline → Executions → 找到最新执行

进入失败的 Step：

CI Build → Install Dependencies → Logs

3. 典型日志

你可能看到类似：

npm ERR! 404 Not Found npm ERR! not-exist-package-demo-xxx npm ERR! A complete log of this run can be found in...

4. 判断原因

这类错误通常属于：

package.json 依赖写错 npm registry 中没有该包 企业 npm 私服没有同步该包 npm 源配置错误

5. 修复方式

删除错误依赖：

git checkout app/package.json

或者修正依赖版本。

重新提交：

git add app/package.json git commit -m "fix: remove invalid dependency" git push origin main

重新运行 Pipeline。

十一：故意制造错误 2：单元测试失败

1. 制造错误

修改app/server.test.js：

throw new Error("mock unit test failed");

提交：

git add app/server.test.js git commit -m "test: mock unit test failure" git push origin main

2. 查看日志

进入：

Executions → 最新执行 → CI Build → Unit Test → Logs

典型日志：

Error: mock unit test failed at Object.<anonymous> (...)

3. 判断原因

这是典型代码质量问题，不是 Harness 问题。

处理方式：

修复测试代码 修复业务代码 本地运行 npm test 确认通过后重新提交

4. 本地验证

cd app npm install npm test

十二：故意制造错误 3：Dockerfile 基础镜像错误

1. 制造错误

修改docker/Dockerfile：

FROM harbor.company.com/library/node:not-exist

提交：

git add docker/Dockerfile git commit -m "test: mock docker base image failure" git push origin main

2. 查看 Harness 日志

进入：

CI Build → Build And Push Image → Logs

典型日志：

failed to solve failed to resolve source metadata not found pull access denied

3. 判断原因

常见原因：

基础镜像不存在 镜像 Tag 写错 Harbor 项目路径错误 CI 构建环境不能访问 Harbor Harbor 自签证书不被信任

4. 排查命令

在可以访问 Harbor 的机器上执行：

docker pull harbor.company.com/library/node:20-alpine

在 K8s 节点或构建 Pod 中确认：

curl -k -I https://harbor.company.com/v2/

5. 修复方式

改回正确镜像：

FROM harbor.company.com/library/node:20-alpine

重新提交运行。

十三：故意制造错误 4：Harbor 推送失败

1. 制造方式

将 Harness Harbor Connector 中的 Robot Token 改错，或者让 Robot Account 没有 Push 权限。

重新运行 Pipeline。

2. 典型日志

在 Build And Push Image Step 中可能看到：

unauthorized: unauthorized to access repository denied: requested access to the resource is denied authentication required

3. 判断原因

常见原因：

Harbor Robot Token 错误 Harness Secret Identifier 写错 Robot Account 没有 push 权限 Harbor 项目不存在 镜像仓库路径写错 Harbor 证书问题

4. 排查方式

本地验证：

docker login harbor.company.com docker push harbor.company.com/devops/harness-demo-app:test

检查 Harness：

Project Settings → Connectors → harbor_company → Test Connection

检查 Harbor：

Projects → devops → Robot Accounts → 权限

5. 修复建议

重新生成 Robot Token 更新 Harness Secret 确认 Robot Account 有 Pull 和 Push 权限 确认 Harbor 项目 devops 已存在

十四：故意制造错误 5：Kubernetes 镜像拉取失败

1. 制造错误

在部署时输入一个不存在的镜像 Tag：

image_tag = not-exist-tag

运行 Pipeline。

2. Harness 中看到的现象

K8s Rolling Deploy Step 可能超时或失败。

Verify Deployment Step 中可能显示：

kubectl rollout status deployment/harness-demo-app -n dev --timeout=180s deployment "harness-demo-app" exceeded its progress deadline

3. Kubernetes 中查看

kubectl get pods -n dev

可能看到：

ImagePullBackOff ErrImagePull

查看 Pod 详情：

kubectl describe pod <pod-name> -n dev

典型事件：

Failed to pull image manifest unknown pull access denied unauthorized x509: certificate signed by unknown authority

4. 判断原因

常见原因：

镜像 Tag 不存在 Deployment 引用的镜像地址错误 imagePullSecrets 不存在 Harbor 拉取账号无权限 K8s 节点无法访问 Harbor Harbor 使用自签证书但节点不信任

5. 修复方式

确认 Harbor 中存在该 Tag 确认 deployment.yaml 中 image 地址正确 确认 dev namespace 中有 harbor-pull-secret 确认 K8s 节点能访问 Harbor 确认 containerd / docker 信任 Harbor 证书

命令：

kubectl get secret harbor-pull-secret -n dev kubectl get deploy harness-demo-app -n dev \ -o jsonpath='{.spec.template.spec.containers[0].image}'

十五：故意制造错误 6：readinessProbe 配置错误

1. 制造错误

将 Deployment 中的 readinessProbe 路径改错：

readinessProbe: httpGet: path: /wrong-health port: 3000

运行 Pipeline。

2. 查看 Harness 日志

部署可能卡在 rollout status：

Waiting for deployment "harness-demo-app" rollout to finish

最后超时。

3. 查看 Kubernetes

kubectl get pods -n dev kubectl describe pod <pod-name> -n dev

可能看到：

Readiness probe failed: HTTP probe failed with statuscode: 404

4. 判断原因

应用实际健康检查地址是 /health Kubernetes 配置写成了 /wrong-health Pod 虽然启动了，但没有 Ready Service 不会把流量转发给未 Ready 的 Pod

5. 修复方式

改回：

readinessProbe: httpGet: path: /health port: 3000

重新部署。

十六：收集 Kubernetes 排障信息脚本

scripts/collect-k8s-debug-info.sh

#!/usr/bin/env bash set -e APP_NAME="${APP_NAME:-harness-demo-app}" NAMESPACE="${NAMESPACE:-dev}" echo "===== Deployment =====" kubectl get deploy ${APP_NAME} -n ${NAMESPACE} -o wide || true kubectl describe deploy ${APP_NAME} -n ${NAMESPACE} || true echo "===== ReplicaSet =====" kubectl get rs -n ${NAMESPACE} -l app=${APP_NAME} -o wide || true echo "===== Pods =====" kubectl get pods -n ${NAMESPACE} -l app=${APP_NAME} -o wide || true echo "===== Pod Describe =====" for pod in $(kubectl get pods -n ${NAMESPACE} -l app=${APP_NAME} -o jsonpath='{.items[*].metadata.name}'); do echo "----- describe pod: ${pod} -----" kubectl describe pod ${pod} -n ${NAMESPACE} || true echo "----- logs pod: ${pod} -----" kubectl logs ${pod} -n ${NAMESPACE} --tail=100 || true done echo "===== Service =====" kubectl get svc ${APP_NAME} -n ${NAMESPACE} -o wide || true kubectl describe svc ${APP_NAME} -n ${NAMESPACE} || true echo "===== Endpoints =====" kubectl get endpoints ${APP_NAME} -n ${NAMESPACE} -o wide || true echo "===== Events =====" kubectl get events -n ${NAMESPACE} --sort-by=.metadata.creationTimestamp | tail -n 50 || true

在 Harness 失败时，可以手动运行这个脚本：

export KUBECONFIG=${HARNESS_KUBE_CONFIG_PATH} APP_NAME=harness-demo-app NAMESPACE=dev scripts/collect-k8s-debug-info.sh

也可以在 Deploy Stage 的 failure strategy 中增加一个失败后执行的收集步骤。

十七：Harness Execution 页面重点看什么？

进入某次执行记录后，建议按以下顺序查看。

1. Summary

关注：

Pipeline 名称 执行状态 触发方式 执行人 分支 Commit Input Set 开始时间 耗时

2. Stage 列表

关注：

哪个 Stage 失败 哪些 Stage 被跳过 是否卡在审批 失败前最后一个成功 Stage 是哪个

3. Step 日志

关注：

失败 Step 的最后 50 行日志 是否有明确 error / failed / denied / timeout 是否是网络错误 是否是权限错误 是否是业务测试错误

4. Input Values

关注：

image_tag 是否正确 namespace 是否正确 deploy_env 是否正确 approval_required 是否正确 environmentRef 是否正确 infrastructureDefinition 是否正确

5. Retry / Rerun

如果确认是临时网络问题，可以重新运行。

如果是配置或代码错误，先修复后再运行。

十八：常见错误关键字速查表

十九：国内网络问题排查

1. Delegate 是否在线

kubectl get pods -n harness-delegate-ng kubectl logs -f deployment/firstk8sdel -n harness-delegate-ng

Harness 控制台查看：

Account Settings → Account Resources → Delegates

确认：

Connected Available Last heartbeat 正常

2. Delegate 能否访问 GitLab

kubectl exec -it deploy/firstk8sdel -n harness-delegate-ng -- sh curl -k -I https://gitlab.company.com

3. Delegate 能否访问 Harbor

curl -k -I https://harbor.company.com/v2/

4. Delegate 能否访问 Kubernetes API

kubectl auth can-i list pods -n dev kubectl auth can-i create deployment -n dev kubectl auth can-i patch deployment -n dev

5. CI Pod 能否访问 npm 源

在 CI Step 中添加：

npm config get registry curl -I https://registry.npmmirror.com

如果企业使用 npm 私服：

curl -I https://npm.company.com/repository/npm-group/

二十：Webhook / Trigger 排查

如果 Git push 后 Pipeline 没触发，查看两边。

1. Harness Trigger Activity

路径：

Pipeline → Triggers → 选择 Trigger → Activity History

关注：

是否收到 Webhook 是否匹配 Trigger 条件 是否因为分支不匹配被忽略 是否 inputYaml 缺失导致触发失败

2. GitLab Webhook Recent Deliveries

路径：

GitLab Project → Settings → Webhooks → Recent Deliveries

关注：

HTTP 状态码 请求是否发送成功 响应是否超时 Secret Token 是否一致 目标 URL 是否正确

常见问题：

GitLab 服务器不能访问 Harness SaaS 公司防火墙阻断出站 HTTPS Webhook URL 复制错误 Trigger 分支过滤不匹配

二十一：审批卡住排查

如果流水线停在 Manual Approval：

Manual Approval → Waiting

检查：

审批人是否在 User Group 中 审批人是否有权限访问该 Project 是否设置了 disallowPipelineExecutor 执行人是否正好也是审批人 是否发送了通知 审批超时时间是否过长

如果审批通知没到：

检查 Slack / 企业微信 Webhook Secret 检查 Delegate 是否能访问通知地址 检查 curl 脚本是否失败

二十二：故障分类方法

排查时可以把失败分成 6 类。

1. 代码类

npm test 失败 编译失败 语法错误 依赖版本冲突

负责人：

开发人员

2. 制品类

Docker build 失败 Docker push 失败 镜像 Tag 不存在 Harbor 权限不足

负责人：

DevOps / 平台工程师

3. 网络类

GitLab timeout Harbor timeout npm registry timeout SonarQube timeout Slack webhook timeout

负责人：

运维 / 网络 / 平台工程师

4. 权限类

Harbor unauthorized GitLab token 无权限 Kubernetes RBAC forbidden Secret 不存在

负责人：

平台工程师 / 安全管理员

5. Kubernetes 类

ImagePullBackOff CrashLoopBackOff Readiness probe failed Service endpoint 为空 rollout 超时

负责人：

开发 + 运维共同排查

6. Harness 配置类

Input Set 缺值 变量表达式写错 Connector 选择错误 Delegate 标签不匹配 Stage 条件写错

负责人：

DevOps / 平台工程师

二十三：构建失败后的标准处理流程

建议企业内部统一以下流程：

1. 查看 Harness Execution，确认失败 Stage 和 Step
2. 复制失败 Step 最后 50 行日志
3. 判断错误类型：代码 / 网络 / 权限 / K8s / Harness 配置
4. 如果是代码错误，分配给开发修复
5. 如果是网络或权限错误，分配给平台或运维
6. 修复后重新运行失败 Pipeline
7. 如果生产部署失败，执行回滚或人工介入
8. 记录故障原因和处理方式

不要直接说"流水线坏了"。

要明确：

失败在哪里？ 错误关键字是什么？ 影响哪个环境？ 是否已经产生制品？ 是否已经部署到 Kubernetes？ 是否需要回滚？

二十四：失败记录模板

建议每次重要失败都记录。

故障时间： 2026-06-18 10:30

Pipeline： nodejs-debug-demo

Execution ID： xxxxxxxx

触发方式： Git push / Manual / Cron

失败阶段： CI Build

失败步骤： Install Dependencies

错误关键字： npm ERR! 404

影响环境： 未部署，无生产影响

初步原因： package.json 中引入了不存在的依赖包

处理方式： 删除错误依赖并重新提交

负责人： 开发：张三

是否需要回滚： 否

最终状态： 重新运行成功

二十五：企业日志治理建议

1. 每条 Pipeline 都应有 Debug Context

建议所有 Pipeline 第一阶段都加：

Print Debug Context

输出：

Pipeline name Execution ID Trigger type Branch Commit SHA Image tag Environment Namespace Input Set

2. 不要在日志中输出 Secret

错误示例：

echo "TOKEN=<+secrets.getValue('harbor_robot_token')>"

正确做法：

echo "Harbor token loaded"

3. 关键步骤要有明确日志

建议每个脚本都加：

echo "开始安装依赖" echo "开始运行单元测试" echo "开始构建镜像" echo "开始推送镜像" echo "开始部署 Kubernetes" echo "开始健康检查"

不要只写一堆命令没有说明。

4. 错误退出要明确

脚本中建议：

set -e

或者：

command || { echo "命令执行失败：command" exit 1 }

5. 生产失败要收集 K8s 信息

生产部署失败后自动收集：

kubectl describe deploy kubectl get pods kubectl describe pod kubectl logs kubectl get events kubectl get endpoints

6. 建立故障知识库

建议整理：

错误关键字 常见原因 排查命令 解决方案 负责人

可放在：

Confluence 语雀 飞书文档 公司 Wiki Git 仓库 docs/troubleshooting.md

二十六：练习 1：制造 npm install 错误并定位

目标：

故意让 npm install 失败，并通过 Harness Step Log 定位原因。

操作：

1. 修改 package.json，添加不存在的依赖
2. 提交代码
3. 运行 Pipeline
4. 在 Execution History 中找到失败记录
5. 进入 Install Dependencies Step 查看日志
6. 找到 npm ERR! 404

验收：

能说明失败原因是依赖不存在或 npm 源中无该包 能修复 package.json 并重新运行成功

二十七：练习 2：制造单元测试失败并定位

目标：

故意让 npm test 失败，并确认后续 Docker Build 不执行。

操作：

1. 在 server.test.js 中添加 throw new Error
2. 提交代码
3. 运行 Pipeline
4. 查看 Unit Test Step 日志
5. 确认 Build And Push Image Step 未执行

验收：

能说明失败属于代码或测试问题 能确认测试失败会阻断制品发布

二十八：练习 3：制造镜像拉取失败并定位

目标：

部署一个不存在的镜像 Tag，观察 Kubernetes ImagePullBackOff。

操作：

1. 运行部署 Pipeline
2. image_tag 填写 not-exist-tag
3. 等待 Deploy Stage 失败
4. 执行 kubectl describe pod
5. 查看 Events 中 Failed to pull image

验收：

能说明失败属于 Kubernetes 拉镜像失败 能定位到镜像 Tag 不存在或 Harbor 权限问题

二十九：练习 4：制造 readinessProbe 失败并定位

目标：

错误配置 readinessProbe path，观察 rollout 超时。

操作：

1. 将 readinessProbe path 改为 /wrong-health
2. 重新运行部署
3. 查看 Harness rollout status 超时
4. kubectl describe pod
5. 找到 Readiness probe failed

验收：

能说明 Pod Running 不代表 Ready 能说明 Service 不会转发流量到未 Ready Pod

三十：验收标准

完成本文后，应达到：

已了解 Harness Execution History 的查看方式 已能查看 Stage 和 Step 日志 已能通过 Step Log 定位 npm install 失败 已能通过 Step Log 定位单元测试失败 已能通过 Build Log 定位 Docker build/push 失败 已能通过 Kubernetes Events 定位 ImagePullBackOff 已能通过 Pod logs 定位 CrashLoopBackOff 已能通过 describe pod 定位 readinessProbe 失败 已能查看 Delegate 日志 已能判断失败属于代码、网络、权限、K8s 还是 Harness 配置 已能编写故障记录 已掌握国内环境常见网络和证书排查方法

三十一：本篇总结

本篇完成了 Harness 日志查看与故障排查的基础落地。

你需要重点记住：

流水线失败时，先看 Execution History 再看失败 Stage 再看失败 Step 最后看 Step Log 的错误关键字 不要一开始就登录服务器乱查 Git 触发问题看 Trigger Activity 和 GitLab Webhook 构建问题看 CI Step Log 制品问题看 Docker Build / Harbor 权限 部署问题看 K8s Rolling Deploy 和 kubectl events 应用问题看 Pod logs 和 readiness/liveness probe Delegate 问题看 Delegate 状态和 Delegate Pod 日志 国内网络问题重点看代理、防火墙、证书和私有仓库访问 生产故障必须记录 Execution ID、镜像版本、错误关键字和处理方式