老楊的實戰(zhàn)筆記：別被各種 “××Ops” 繞走——回到能用的根兒上
我做運維的這些年，見過太多熱詞像潮水一樣涌來，又像潮退時帶走了理性。DevOps 這事兒，剛出來是想把開發(fā)和運維的責(zé)權(quán)拉在一條線上，讓交付變得可控、可重復(fù)、能改進(jìn)。后來聽到的名字越來越多：DevSecOps、GitOps、CloudOps、AIOps、MLOps……它們不是騙人的“新瓶子裝舊酒”，而是把同一套能力在不同場景下的側(cè)重寫了出來。但問題是，很多團(tuán)隊忙著貼標(biāo)簽，反而把根本沒弄好的基礎(chǔ)給忽視了。下面把我這些年的落地經(jīng)驗，說得直白點，也給能直接用的實操命令，少廢話，多能上手。
我常說：真正值錢的，是自動化、監(jiān)控和協(xié)作這三樣?xùn)|西。把這三樣做好，80% 的問題就有解了。其他的那些 “Ops” ——可以選、也可不選，按需用就行。
說點接地氣的現(xiàn)實。很多公司現(xiàn)在的技術(shù)棧長這樣：GitLab 自建倉庫，Jenkins 做 CI，鏡像放 Harbor，運行在阿里云的 ECS 或 Kubernetes 上。這個組合幾乎適配多數(shù)傳統(tǒng)企業(yè)，我就在這種生態(tài)里落地過不止一次。接下來演示一個從代碼到部署的完整小流程，代碼、Docker、Jenkinsfile、以及用 Trivy 做鏡像安全掃描；這些命令你能直接復(fù)制到企業(yè)環(huán)境里跑（注意替換你的私有域名和憑據(jù)）。
先建個最簡單的 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"]構(gòu)建并運行鏡像，注意把鏡像地址換成自己 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 最簡模版，能把代碼檢出、構(gòu)建鏡像、推到 Harbor、再觸發(fā) K8s 更新。企業(yè)實際使用時，把憑據(jù) 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 是輕量且在國內(nèi)也好用的工具，掃描鏡像只需要一條命令：
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 流水線里，達(dá)到“構(gòu)建失敗即阻斷發(fā)布”的效果。別忘了對鏡像里敏感文件做靜態(tài)檢查，例如配置文件里的明文密碼、私鑰等，也要在流水線里用腳本 grep 一下，簡單但有效。
談到 GitOps，實際落地最關(guān)鍵的地方不是 ArgoCD 本身，而是把“應(yīng)用清單”當(dāng)成真正的單一可信來源（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我見過太多團(tuán)隊在“聲明式”上抓皮毛，結(jié)果是人還在用 kubectl apply 去修復(fù)集群里被手動改壞的東西。GitOps 的價值，就是把這種手工改動逼回到審計和變更流程里。
再說一點“文化”的問題，這東西比工具復(fù)雜也更耐煩。技術(shù)棧再好，如果溝通、度量、持續(xù)改進(jìn)沒上來，系統(tǒng)就會慢性病發(fā)作。我常對團(tuán)隊說幾句容易忘但很重要的話：
- 自動化不要半拉子：從構(gòu)建到部署、到回滾、到告警處理，盡量把可重復(fù)的步驟腳本化。
- 指標(biāo)與告警必須有優(yōu)先級：Prometheus+Grafana+Alertmanager 對多數(shù)場景夠用了；但指標(biāo)名字、標(biāo)簽、告警閾值要有約定，別上來就堆一堆零散的告警。
- 安全與合規(guī)要可驗證：掃描、SCA、鏡像簽名，至少做到“可查”和“可阻斷”。
- 協(xié)作是一項長期工程：代碼評審、運維 runbook（可操作的故障手冊）、演練頻次，這些都比花錢買個所謂 AIOps 平臺更能提升可靠性。
關(guān)于那些“高大上”的技術(shù)，比如 AIOps、MLOps，我的建議是：先把數(shù)據(jù)鏈路打通。告警、指標(biāo)、變更記錄要入庫并能被查詢和標(biāo)注，才能讓 ML 模型有“糧吃”。很多團(tuán)隊著急上 AIOps，卻連告警噪聲都處理不掉，這就像想用精密儀器修理一只破鐘，但是鐘還沒上發(fā)條。
最后把我的一個心法寫在這里，掛在白板上的是這樣一句話（也許有點俗，但我是真的用得上）：
DevOps 是根，安全護(hù)其脈，GitOps 明其道，CloudOps 展其勢。自動化是基礎(chǔ)，監(jiān)控與反饋是放大器，團(tuán)隊協(xié)作才是長期收益的泉源。
