老楊的實戰筆記：別被各種 “××Ops” 繞走——回到能用的根兒上
我做運維的這些年，見過太多熱詞像潮水一樣涌來，又像潮退時帶走了理性。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，卻連告警噪聲都處理不掉，這就像想用精密儀器修理一只破鐘，但是鐘還沒上發條。
最后把我的一個心法寫在這里，掛在白板上的是這樣一句話（也許有點俗，但我是真的用得上）：
DevOps 是根，安全護其脈，GitOps 明其道，CloudOps 展其勢。自動化是基礎，監控與反饋是放大器，團隊協作才是長期收益的泉源。
