老杨的实战笔记：别被各种 “××Ops” 绕走——回到能用的根儿上

IT运维技术圈

发布于 2025-11-20 17:32:59

100

0. 写在前面：为什么你需要“神器”而非“常用命令

大家好,欢迎来到干货、技术、专业全方位遥遥领先的老杨的博客.

我做运维的这些年，见过太多热词像潮水一样涌来，又像潮退时带走了理性。DevOps 这事儿，刚出来是想把开发和运维的责权拉在一条线上，让交付变得可控、可重复、能改进。后来听到的名字越来越多：DevSecOps、GitOps、CloudOps、AIOps、MLOps……它们不是骗人的“新瓶子装旧酒”，而是把同一套能力在不同场景下的侧重写了出来。但问题是，很多团队忙着贴标签，反而把根本没弄好的基础给忽视了。下面把我这些年的落地经验，说得直白点，也给能直接用的实操命令，少废话，多能上手。

我常说：真正值钱的，是自动化、监控和协作这三样东西。把这三样做好，80% 的问题就有解了。其他的那些 “Ops” ——可以选、也可不选，按需用就行。

说点接地气的现实。很多公司现在的技术栈长这样：GitLab 自建仓库，Jenkins 做 CI，镜像放 Harbor，运行在阿里云的 ECS 或 Kubernetes 上。这个组合几乎适配多数传统企业，我就在这种生态里落地过不止一次。接下来演示一个从代码到部署的完整小流程，代码、Docker、Jenkinsfile、以及用 Trivy 做镜像安全扫描；这些命令你能直接复制到企业环境里跑（注意替换你的私有域名和凭据）。

先建个最简单的 Node.js 程序，演示链路最短的那段：

mkdir hello-devops && cd hello-devops
npm init -y
echo 'console.log("Hello DevOps!");' > index.js

写个 Dockerfile：

FROM node:18-alpine
WORKDIR /app
COPY . .
CMD ["node", "index.js"]

构建并运行镜像，注意把镜像地址换成自己 Harbor 的地址：

docker build -t harbor.mycorp.local/devops/hello:1.0 .
docker run --rm harbor.mycorp.local/devops/hello:1.0

控制台输出（简化）：

Hello DevOps!

好，镜像有了。下面是我常用的 Jenkins Pipeline 最简模版，能把代码检出、构建镜像、推到 Harbor、再触发 K8s 更新。企业实际使用时，把凭据 id、Git 地址、镜像地址改好就行。

pipeline {
    agent any
    stages {
        stage('Checkout') {
            steps {
                git 'https://gitlab.mycorp.local/devops/hello.git'
            }
        }
        stage('Build') {
            steps {
                sh 'docker build -t harbor.mycorp.local/devops/hello:$BUILD_NUMBER .'
            }
        }
        stage('Push') {
            steps {
                withCredentials([usernamePassword(credentialsId: 'harbor-cred', usernameVariable: 'USER', passwordVariable: 'PASS')]) {
                    sh 'docker login harbor.mycorp.local -u $USER -p $PASS'
                    sh 'docker push harbor.mycorp.local/devops/hello:$BUILD_NUMBER'
                }
            }
        }
        stage('Deploy') {
            steps {
                sh 'kubectl set image deployment/hello hello=harbor.mycorp.local/devops/hello:$BUILD_NUMBER'
            }
        }
    }
}

模拟控制台输出（简化）：

[Checkout] Cloning repository...
[Build] Step 1/4 : FROM node:18-alpine
[Build] ...
[Push] Pushing image harbor.mycorp.local/devops/hello:15
[Deploy] deployment.apps/hello image updated
Pipeline successful ✅

安全怎么做？别到处说“把安全左移”，而不落地。给你一个能立刻接入的扫描步骤，Trivy 是轻量且在国内也好用的工具，扫描镜像只需要一条命令：

trivy image harbor.mycorp.local/devops/hello:1.0

示例输出（简化）：

2025-10-13T10:00:00Z  INFO  Vulnerability scanning...
Node.js 18-alpine
=================
CVE-2025-XXXX  High   openssl  1.1.1w
...

把它加到 CI 流水线里，达到“构建失败即阻断发布”的效果。别忘了对镜像里敏感文件做静态检查，例如配置文件里的明文密码、私钥等，也要在流水线里用脚本 grep 一下，简单但有效。

谈到 GitOps，实际落地最关键的地方不是 ArgoCD 本身，而是把“应用清单”当成真正的单一可信来源（source of truth）。把 deployment、service 等 YAML 放到专门的 repo，变更走 PR、审查、合并、自动同步。举个最小例子，K8s 的一个简单部署清单：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello
spec:
  replicas: 1
  template:
    spec:
      containers:
      - name: hello
        image: harbor.mycorp.local/devops/hello:1.0

我见过太多团队在“声明式”上抓皮毛，结果是人还在用 kubectl apply 去修复集群里被手动改坏的东西。GitOps 的价值，就是把这种手工改动逼回到审计和变更流程里。

再说一点“文化”的问题，这东西比工具复杂也更耐烦。技术栈再好，如果沟通、度量、持续改进没上来，系统就会慢性病发作。我常对团队说几句容易忘但很重要的话：

• 自动化不要半拉子：从构建到部署、到回滚、到告警处理，尽量把可重复的步骤脚本化。
• 指标与告警必须有优先级：Prometheus+Grafana+Alertmanager 对多数场景够用了；但指标名字、标签、告警阈值要有约定，别上来就堆一堆零散的告警。
• 安全与合规要可验证：扫描、SCA、镜像签名，至少做到“可查”和“可阻断”。
• 协作是一项长期工程：代码评审、运维 runbook（可操作的故障手册）、演练频次，这些都比花钱买个所谓 AIOps 平台更能提升可靠性。

关于那些“高大上”的技术，比如 AIOps、MLOps，我的建议是：先把数据链路打通。告警、指标、变更记录要入库并能被查询和标注，才能让 ML 模型有“粮吃”。很多团队着急上 AIOps，却连告警噪声都处理不掉，这就像想用精密仪器修理一只破钟，但是钟还没上发条。

最后把我的一个心法写在这里，挂在白板上的是这样一句话（也许有点俗，但我是真的用得上）：