一个运维的AI转型实录：从手动部署到云原生，踩了这些坑

去年这个时候我还是一个每天手动部署服务的运维。SSH登录服务器git pullnpm buildpm2 restart一套流程走下来20分钟。如果同时要部署3个服务就是1个小时。现在一条命令3个服务同时部署完成包括健康检查和回滚。不是我变快了是我换了套工具。这篇文章不是教你AI多厉害而是分享我从传统运维转型到云计算/AI运维的实际经历包括踩过的坑、考过的证、以及我觉得值得学的技术栈。踩坑一以为Docker就是容器化的全部2024年初我开始学Docker。觉得学会了Docker就算云原生了。写了一堆Dockerfile把服务全容器化了觉得自己很牛。然后遇到了第一个坑服务之间怎么通信Docker默认的bridge网络容器之间只能用IP通信。IP会变一重启就挂。我花了两天时间搞明白要用docker-compose又花了一天搞明白要用自定义网络。分享一个我实际在用的docker-compose配置三个服务自定义网络健康检查version: 3.8 services: app: build: ./app ports: - 3000:3000 networks: - backend healthcheck: test: [CMD, curl, -f, http://localhost:3000/health] interval: 30s timeout: 10s retries: 3 restart: unless-stopped ​ worker: build: ./worker networks: - backend depends_on: redis: condition: service_healthy environment: - REDIS_URLredis://redis:6379 ​ redis: image: redis:7-alpine networks: - backend healthcheck: test: [CMD, redis-cli, ping] interval: 10s ​ networks: backend: driver: bridge这个配置踩过两个坑。第一个是depends_on的condition: service_healthyDocker Compose v3默认不支持这个语法我第一次跑的时候直接报错。后来查了半天文档发现需要升级到v3.8才行。第二个是健康检查。我一开始没配healthcheck结果worker启动的时候redis还没ready连接直接被拒。加了healthcheck之后才解决。后来才发现Docker只是入门。真正的云原生是Kubernetes。但K8s的学习曲线太陡了我学了两个月才勉强能在生产环境用。给大家看一个我实际部署到K8s的Deployment配置apiVersion: apps/v1 kind: Deployment metadata: name: ai-service labels: app: ai-service spec: replicas: 3 selector: matchLabels: app: ai-service template: metadata: labels: app: ai-service spec: containers: - name: ai-service image: registry.cn-hangzhou.aliyuncs.com/myteam/ai-service:v2.1 ports: - containerPort: 8080 resources: requests: memory: 512Mi cpu: 500m limits: memory: 2Gi cpu: 2000m livenessProbe: httpGet: path: /health port: 8080 initialDelaySeconds: 30 periodSeconds: 10 readinessProbe: httpGet: path: /ready port: 8080 initialDelaySeconds: 5 periodSeconds: 5这个配置也踩过坑。initialDelaySeconds我一开始设成了5秒结果应用启动比较慢要加载模型健康检查连续失败导致Pod被反复重启。改成30秒之后才正常。这种坑文档里不会写只有实际部署过才会知道。经验别把Docker当终点它只是起点。但也别一上来就学K8s先搞懂Dockerdocker-compose能解决80%的问题。踩坑二自建CI/CD vs 云服务选错了方向2024年中我想搞自动化部署。当时有两个选择自建一套JenkinsGitLab Runner或者用阿里云的云效/DevOps平台。我选了自建。原因很简单——免费。然后我花了两周时间搭建Jenkins配插件写pipeline脚本。搞完之后发现维护Jenkins本身就要花不少精力。插件升级冲突、磁盘满了、Java版本不兼容……各种问题。更离谱的是有一次Jenkins挂了导致整个部署流程中断了3个小时。我凌晨2点被电话叫起来修。后来还是迁移到了阿里云云效。迁移只花了半天而且再也不用操心基础设施了。给大家看一段我之前写的Jenkinsfile自建时代的产物和现在云效的配置对比一下// 以前的Jenkinsfile又长又脆弱 pipeline { agent any stages { stage(Build) { steps { sh npm install sh npm run build } } stage(Test) { steps { sh npm test } } stage(Deploy) { steps { sh docker build -t myapp:${BUILD_NUMBER} . sh docker stop myapp || true sh docker rm myapp || true sh docker run -d --name myapp -p 3000:3000 myapp:${BUILD_NUMBER} } } } post { failure { mail to: teamexample.com, subject: Build Failed: ${env.JOB_NAME} #${env.BUILD_NUMBER}, body: Check console output at ${env.BUILD_URL} } } }这段脚本看着简单实际维护起来很痛苦。有一次npm registry挂了所有构建全部失败我手动改了三台Jenkins agent的npm config才修好。还有一次磁盘满了Jenkins直接罢工凌晨2点被电话叫起来清理日志。现在用云效之后同样的流程配置大概是这样简化版# .flow.yml阿里云云效 stages: - name: 构建 jobs: - job: build_node steps: - step: npminstall - step: npmbuild - name: 测试 jobs: - job: test steps: - step: npmbuild commands: - npm test - name: 部署 jobs: - job: deploy_aliyun steps: - step: deploy with: region: cn-hangzhou service: myapp image: registry.cn-hangzhou.aliyuncs.com/myteam/myapp不用管服务器不用管磁盘不用凌晨起来修Jenkins。构建日志、测试报告、部署状态全在云效控制台看。唯一的缺点是要花钱——但我们算了一下每月的费用大概200块比我凌晨2点加班的时薪便宜多了。经验除非你有专门的DevOps团队否则别自建CI/CD。云服务的成本比你想象中低省下来的时间比你省下来的钱值钱得多。踩坑三考ACP认证第三章差点放弃2024年底我决定考阿里云ACP云计算认证。原因很简单——跳槽的时候发现有ACP的候选人面试通过率高很多。备考过程踩了几个坑分享给大家。坑1官方文档太厚了。阿里云ACP的官方教材有500多页我看了两周才看了三分之一。后来发现了一个更高效的方法——先刷题把错题对应的知识点去官方文档里找。这样效率高了至少3倍。坑2云安全那章卡了我三天。ACP考试里云安全占的比重不小但我之前对安全完全没概念。KMS、RAM、安全组规则这些东西看文档看得头晕。后来在B站找了个系列视频跟着实操了一遍才搞明白。坑3模拟题和真题难度不一样。官方模拟题比较简单我第一次做能拿80分。但实际考试的时候有几道题考得很细比如某个产品的某个参数默认值是多少这种。这种题只能靠多刷题积累。最后考了86分过的。不算高但够用了。经验别只看文档一定要刷题实操。官方文档是知道有什么刷题是知道考什么实操是知道怎么用。三者缺一不可。踩坑四AIops不是运维AI这么简单今年初我开始接触AIops。一开始以为就是用AI工具辅助运维比如用ChatGPT写shell脚本之类的。后来发现完全不是这么回事。真正的AIops是让AI自主完成运维任务。比如异常检测、自动扩缩容、故障自愈。这需要你懂PrometheusGrafana的监控体系懂K8s的HPA/VPA懂时序数据的异常检测算法。分享一个我最近写的Prometheus告警规则用来自动检测API响应时间异常# prometheus-alerts.yml groups: - name: ai_service_alerts rules: # API响应时间P99超过2秒触发告警 - alert: HighLatency expr: histogram_quantile(0.99, rate(http_request_duration_seconds_bucket{jobai-service}[5m])) 2 for: 5m labels: severity: warning annotations: summary: AI服务响应时间过高 (P99: {{ $value }}s) description: {{$labels.instance}} 的P99延迟已超过2秒持续5分钟 ​ # GPU显存使用率超过90%触发告警 - alert: GPUHighMemory expr: nvidia_gpu_memory_used_bytes / nvidia_gpu_memory_total_bytes 0.9 for: 3m labels: severity: critical annotations: summary: GPU显存使用率超过90% description: {{$labels.instance}} GPU {{$labels.gpu}} 显存使用率: {{ $value | humanizePercentage }}写这个规则的时候踩了个坑for: 5m这个参数我一开始设成了for: 1m结果只要有一次请求慢了就告警一天能收到几十条告警邮件后来全团队都把告警群屏蔽了。改成5分钟之后只对持续性的问题告警误报率大幅下降。还有一个坑是GPU监控指标。Prometheus默认不采集nvidia_gpu_*指标需要额外装nvidia_gpu_exporter。我第一次部署的时候忘了装告警规则写了但永远不触发排查了半天才发现问题出在这里。我目前还在学。但有一个感触很深传统运维正在被替代但能设计和维护AI运维系统的人极度稀缺。IDC预测到2030年45%的日常IT运维任务将由AI智能体处理。如果你现在还在做手动部署、手动巡检这类工作真的要开始转型了。我现在的技术栈和学习路径分享一下我目前的技能栈给想转型的朋友参考已掌握Linux系统管理、Docker、Kubernetes基础、阿里云ACP、CI/CD云效、Shell/Python脚本、PrometheusGrafana监控正在学AIops异常检测、自动扩缩容、大模型应用开发LangChain、云原生安全下一步计划考ACE架构师认证把云计算的技能体系再往上拉一层关于考认证是不是智商税这个问题在CSDN评论区经常看到。说点我自己的看法。认证本身不值钱值钱的是备考过程中你学到的知识体系。我考ACP之前对云计算的理解是碎片化的——知道一些产品但不知道它们之间的关系。考完之后脑子里有了一张完整的云架构图。脉脉春招数据持证云计算工程师比无证的月薪高5000-8000元。这个溢价不是因为你有一张纸是因为你真的比别人多知道一些东西。但如果你只是背题库过了考试没有实际操作经验那确实没什么用。面试官问两个实操问题就露馅了。我的建议考认证做项目两条腿走路。踩坑总结写到最后总结几条我转型过程中最大的教训别在免费上浪费时间。自建Jenkins省了几百块但浪费了两周凌晨2点的加班。云服务该花就花。别把Docker当终点。Docker→K8s→Service Mesh云原生是一条很长的路但每一步都有明确的回报。别只背题不实操。ACP考试83分过了但如果不会在控制台实际操作面试一样过不了。别等准备好了再转型。我2024年初开始学Docker的时候也没觉得自己准备好了。就是硬着头皮学的。有在转型路上的朋友评论区聊聊你们卡在哪一步了或者已经转型成功的分享一下你们的经验。云计算从业者ACP云计算持证计划开始开始ACP大模型认证以上纯属个人经验欢迎交流。