先说说最近后台问我最多的一类问题刚入行运维或者刚转行过来Linux 只会重启服务器批量操作几十台机器还是手动一条条敲命令领导安排个“更新配置文件”的活能干一整天。如果你也是这样那 Ansible Shell CI/CD 这条线就是你急需补上的“自动化运维基本功”。这篇文章按一条完整的学习路径来写先建立自动化运维的整体认知再补齐 Linux 和 Shell 脚本基础然后上手 Ansible 批量管理最后把 CI/CD 串起来做完一个“代码提交后自动部署到多台服务器”的小型闭环。内容尽量照顾零基础读者代码都可以直接复制到自己的环境中验证已经有一定基础的开发者也可以直接跳到第 4 章和第 6 章看实战部分。1. 自动化运维在学什么先建立整体认知1.1 传统运维和自动化运维的区别传统运维模式下服务器数量少的时候人工操作勉强能接受。比如三五台机器登录上去改个端口、重启个服务半小时也能搞定。但服务器数量到几十台、上百台之后人工操作就会出现三个明显问题效率低同样的命令要重复执行几十次时间都花在“执行”而不是“思考”上。易出错人不是机器漏掉一台机器、写错一个参数在紧急变更时很容易发生。难追溯哪台机器改了什么、什么时候改的、谁改的完全没有记录。自动化运维的思路是把重复性操作变成脚本、变成工具、变成流水线让机器帮我们执行。这样同样的一件事原来手动做 2 小时自动化之后可能只需要 2 分钟而且每次结果一致。1.2 Ansible、Shell、CI/CD 三个工具怎么分工很多新手容易混淆这几个概念我先用一句话区分Shell 脚本你亲手写的“手工活说明书”做的是单机或少量机器上的自动化。Ansible批量执行工具通过 SSH 把指令下发到多台机器做的是“多机编排”。CI/CD把代码从提交到构建、测试、部署的整条链路自动化做的是“流程自动化”。可以这么理解Shell 脚本解决“某台机器上怎么做”Ansible 解决“一堆机器上怎么做”CI/CD 解决“代码改完之后怎么自动触发前面所有过程”。这三者的关系不是替代而是配合。真实项目里常见的组合是CI/CD 触发构建后调用 Ansible Playbook 批量分发部署而 Ansible 在执行过程中又会运行服务器上的 Shell 脚本来完成重启或健康检查。1.3 小白学习路线图如果你想用最短路径入门建议按下面的顺序走掌握 Linux 常用命令能看懂路径、文件、权限、进程、服务状态。学会写 Shell 脚本变量、条件、循环、函数、参数处理够了。上手 Ansible主机清单、ad-hoc 命令、Playbook、常用模块。理解 CI/CD 概念代码仓库、构建、测试、部署、流水线。做综合实战把 Shell 脚本、Ansible、CI/CD 串成一个完整案例。接下来每一章都对应这条路线上的一个节点。2. 环境准备与 Linux 基础补课2.1 学习环境说明如果你有一台云服务器或者本地虚拟机学习效果是最好的。版本不需要刻意追求最新常见的 CentOS Stream、Ubuntu 20.04/22.04、openEuler 等发行版都可以。本文示例以常见的 Linux 环境为例部分命令在 Debian 系和 RedHat 系中会有差异文中我会单独说明。如果你是 Windows 系统建议先装一台 Ubuntu 虚拟机或者直接用云厂商的按量付费服务器练手。不要一开始就把时间花在搭建复杂环境上先跑起来最重要。2.2 Linux 常用命令速览自动化运维离不开对 Linux 的理解。这里给出一组最常用的命令每一类只挑最核心的# 文件和目录 pwd # 查看当前路径 ls -lh # 以易读方式列出文件 cd /etc/nginx # 切换目录 mkdir -p /data/apps # 递归创建目录 cp -r config /backup # 复制目录 mv old.conf new.conf # 重命名文件 rm -rf /tmp/cache # 删除目录慎用 # 查看文件内容 cat /etc/hosts # 查看整个文件 less /var/log/syslog # 分页查看 tail -f app.log # 实时跟踪日志 # 查找和定位 find /etc -name *.conf # 按名称查找 grep -r error /var/log/ # 按内容搜索 which nginx # 查看命令位置 # 网络和拷贝 scp app.jar root192.168.1.10:/data/ # 跨机器拷贝文件 curl -I http://localhost:8080 # 看 HTTP 响应头这套命令不需要死记硬背只要知道“遇到什么场景用哪类命令”就行。真正的熟练是靠反复用比如每天在服务器上切换目录、看日志、查进程半个月就很顺了。2.3 新建用户与权限管理运维工作中尽量不要直接用 root 执行所有操作安全风险太高。新建一个普通用户再给必要的 sudo 权限是更合理的做法。# 新建用户 useradd ops # 设置密码 passwd ops # 把用户加入 sudo 组Debian/Ubuntu usermod -aG sudo ops # 如果是 RedHat/CentOS则加入 wheel 组 usermod -aG wheel ops # 切换到该用户检查权限 su - ops sudo whoami权限概念是整个 Linux 自动化绕不开的点。执行ls -l时看到的rwxr-xr-x第一位表示文件类型后面的三组分别代表“所属用户”“所属组”“其他人”的读、写、执行权限。写 Shell 脚本或 Ansible 任务时很多报错都跟权限有关所以后面遇到 Permission denied先想到这一层。2.4 安装 Python 与 AnsibleAnsible 基于 Python 开发控制端需要 Python 环境。现代 Linux 发行版大多自带 Python 3可以先用python3 --version确认。Ansible 的安装方式有很多最省事的是用 pip 安装到用户目录# 确认 Python3 已安装 python3 --version # 安装 pip如果还没有 curl -sS https://bootstrap.pypa.io/get-pip.py | python3 # 安装 ansible pip3 install --user ansible # 查看版本 ansible --version--user参数表示只安装到当前用户目录不需要系统级权限比较适合学习环境。生产环境建议参考官方文档做好版本管理。需要注意Ansible 版本迭代比较快不同版本的模块参数可能有差异示例代码如果遇到参数不识别优先查一下当前版本的模块文档。3. Shell 脚本自动化运维的“手工活”3.1 Shell 脚本入门从第一行开始Shell 脚本就是把你平时在终端里手动敲的命令存到一个文件里加上一些逻辑控制让批量操作更高效。创建一个最简单的脚本#!/bin/bash # 文件名hello.sh echo Hello, Automation! echo 当前时间是$(date)第一行#!/bin/bash叫 shebang告诉系统用哪个解释器执行这个脚本。然后赋予执行权限并运行chmod x hello.sh ./hello.sh输出Hello, Automation! 当前时间是Mon Aug 12 10:23:45 CST 2025如果不想加执行权限也可以直接用bash hello.sh运行。3.2 变量、条件、循环与函数Shell 脚本真正发挥作用是靠变量和逻辑控制。先看一个包含变量、条件判断和循环的完整示例#!/bin/bash # 文件名check_servers.sh # 简单巡检脚本检查一组服务器上某个端口是否开放 SERVERS(192.168.1.11 192.168.1.12 192.168.1.13) PORT8080 for ip in ${SERVERS[]}; do if nc -z -w3 $ip $PORT /dev/null 21; then echo [OK] $ip:$PORT 端口可达 else echo [FAIL] $ip:$PORT 端口不可达 fi done这里用到了三个核心语法SERVERS(...)定义数组。for ip in ...循环遍历。if ...; then ... else ... fi条件判断。实际使用时把 IP 换成你自己的服务器列表把nc -z -w3换成相应的检测命令就是一个可用的基础巡检脚本。函数用来封装重复逻辑。看一个带函数的版本#!/bin/bash # 文件名upgrade_app.sh deploy() { local APP_NAME$1 echo 开始部署 $APP_NAME # 模拟部署过程 sleep 2 echo $APP_NAME 部署完成 } deploy order-service deploy user-servicelocal声明的变量只在函数内有效$1是传给函数的第一个参数这种写法能避免全局变量污染。3.3 进阶技巧shift、错误忽略、文件重命名写脚本时经常会遇到三个进阶需求解析多个命令行参数、希望脚本出错时不要中断、批量重命名文件。先看shift的用法。$1、$2代表脚本接收的第一个、第二个参数shift的作用是把参数列表整体左移通常用来循环处理参数#!/bin/bash # 文件名args_demo.sh while [ $# -gt 0 ]; do echo 当前处理参数$1 shift done运行./args_demo.sh a b c输出当前处理参数a 当前处理参数b 当前处理参数c再看“忽略错误继续执行”。Shell 脚本默认遇到错误不一定立刻退出但使用set -e后一旦命令返回非零状态就会中断。如果你明确知道某条命令可能失败但失败不影响后续流程可以这样处理#!/bin/bash set -e echo 删除旧备份如果不存在也继续 rm -rf /data/backup_old || true echo 继续执行后续步骤|| true的意思是前面的命令失败时执行true让整条表达式认为执行成功脚本不会退出。另一种方式是set e临时关闭严格模式执行完成后再set -e恢复。最后看一个利用find和循环批量重命名文件的示例#!/bin/bash # 修改当前目录下所有 .log 文件的后缀为 .bak for file in $(find . -maxdepth 1 -name *.log); do mv $file ${file%.log}.bak echo 已重命名$file - ${file%.log}.bak done${file%.log}是 Shell 的参数扩展语法表示去掉文件名的后缀。3.4 Shell 脚本常见坑新手写 Shell 经常会踩几个典型的坑这里整理出来问题现象常见原因解决思路脚本执行时报Permission denied文件没有执行权限chmod x script.sh或用bash script.sh执行变量名旁边拼接字符出错变量边界不清晰用${var}包裹变量名循环文件名带空格时被拆开没有加引号始终用$file包住变量set -e下脚本意外退出某个命令退出码非零按需使用 换行符错误导致$\r报错Windows 编辑导致 CRLF用sed -i s/\r$// script.sh转换Shell 本身不复杂但细节非常多。建议平时把常用逻辑积累成自己的脚本片段库后面写 Ansible、写 CI/CD 时都能复用。4. Ansible批量管理服务器的“遥控器”4.1 Ansible 工作原理Ansible 的架构用一句话概括控制端通过 SSH 连接被管理主机把要执行的模块或命令推送到目标机器并执行执行结果返回控制端。它的优势有三个无需在被管理端安装 agent只要目标机器支持 SSH 即可。使用 YAML 编写的 Playbook配置清晰、可重复执行。幂等性好同样的 Playbook 重复执行结果一致不会重复叠加变更。理解 Ansible 时只需要抓住四个核心概念控制端、被管理节点、Inventory主机清单、模块执行具体操作的功能单元。4.2 Inventory 主机清单Inventory 就是告诉 Ansible“去管哪些机器”的文件。默认路径是/etc/ansible/hosts但更推荐在项目目录维护自己的 inventory 文件。# 文件名inventory/hosts.ini [web_servers] 192.168.1.11 192.168.1.12 [db_servers] 192.168.1.21 ansible_userroot [all:vars] ansible_userops ansible_ssh_private_key_file~/.ssh/id_rsa方括号里是组名web_servers下面就是组内的主机。all:vars是全局变量区统一配置 SSH 用户和密钥路径避免每条主机重复写。在控制端先生成 SSH 密钥并拷贝到目标机器ssh-keygen -t rsa -b 4096 ssh-copy-id ops192.168.1.11 ssh-copy-id ops192.168.1.12然后测试连通性ansible web_servers -i inventory/hosts.ini -m ping-m ping表示使用 ping 模块它并不是真的去 ping 目标而是检查能否通过 SSH 正常执行任务。返回绿色pong说明控制端到目标机器的通道已经打通了。4.3 ad-hoc 命令快速上手临时执行一条命令时不必写 Playbook用 ad-hoc 命令就够了。ad-hoc 是 Ansible 中一次性执行任务的方式。批量查看服务器的磁盘使用情况ansible web_servers -i inventory/hosts.ini -m shell -a df -h批量安装软件包Debian/Ubuntu 系ansible web_servers -i inventory/hosts.ini -m apt -a namenginx statepresent -b-b表示使用 sudo 提权。批量把某个服务设置为开机自启ansible web_servers -i inventory/hosts.ini -m systemd -a namenginx statestarted enabledyes -bad-hoc 适合快速操作但复杂任务还是推荐写成 Playbook方便保存、复用、版本管理。4.4 Playbook 实战复制文件到所有节点并授权现在来看一个最常见的需求把控制端的一个文件复制到所有节点并设置权限。搜索热词里也高频出现“ansible 复制文件到所有节点并授权 777 权限”这个需求在部署场景中很常见比如配置文件、启动脚本、安装包的分发。先创建一个测试文件echo version1.0.0 /data/app.conf然后写一个 Playbook# 文件名copy_file.yml --- - name: 复制配置文件到所有节点 hosts: web_servers remote_user: ops become: yes tasks: - name: 创建目标目录 ansible.builtin.file: path: /data/apps/config state: directory mode: 0755 - name: 复制文件到所有节点 ansible.builtin.copy: src: /data/app.conf dest: /data/apps/config/app.conf mode: 0777 - name: 验证文件写入结果 ansible.builtin.command: cat /data/apps/config/app.conf register: result - name: 输出验证信息 ansible.builtin.debug: msg: {{ result.stdout }}执行ansible-playbook -i inventory/hosts.ini copy_file.yml需要强调一点mode: 0777是搜索热词里明确提到的需求也是很多部署文档里的写法但生产环境中 777 权限意味着所有用户都可读可写可执行安全风险很高。一般配置文件用0644脚本文件用0755只有少数共享目录场景才考虑 777。如果你拿到一个要求 777 的需求先问自己一个问题为什么它需要 777是目录结构问题还是运行用户不统一从运维安全的角度尽量规避无差别提权。执行完成后Ansible 会汇总每一台机器的执行结果包含 changed、ok、failed 等状态。如果你的 Playbook 里有任何任务失败Ansible 会明确指出是哪台主机、哪个任务、什么原因。再补充一个 Playbook 中很实用的写法——用with_items循环处理多个文件- name: 批量复制多个配置文件 ansible.builtin.copy: src: files/{{ item }} dest: /data/apps/config/{{ item }} mode: 0644 loop: - app.conf - nginx.conf - logback.xml这比写三个 copy 任务要干净很多。Ansible 的学习重点就是掌握常用模块的使用比如 file、copy、command、shell、apt、yum、systemd、template、service 等再结合变量、循环、条件判断已经能覆盖大部分批量运维场景。5. CI/CD把部署流程自动化5.1 什么是 CI/CDCIContinuous Integration持续集成的意思是代码每次提交到仓库后自动触发构建和测试尽早发现集成问题。CDContinuous Deployment/Delivery持续部署/交付的意思是代码通过测试后自动部署到目标环境。对运维来说CI/CD 带来的最大价值是开发提交代码后不再需要你来手动登录服务器拉代码、打包、重启而是由流水线自动完成。流程上通常是这样代码提交 - 触发流水线 - 拉取代码 - 构建/编译 - 运行测试 - 构建镜像或产物 - 部署到服务器 - 健康检查5.2 常见工具选择CI/CD 工具非常多常见的有GitLab CI与 GitLab 深度集成配置文件写在项目仓库里。GitHub Actions适合 GitHub 托管代码模板丰富。Jenkins老牌 CI/CD 工具插件多适合复杂企业环境。云厂商的 CI/CD 产品比如阿里云效、腾讯云 CODING国内企业用得比较多。新手不建议一上来就去啃 Jenkins 的插件体系可以先从一个最轻量的流水线配置学起理解清楚流程再迁移到其他工具。5.3 最简单的 CI/CD 流水线思路以 GitLab CI 为例在项目根目录创建.gitlab-ci.yml# 文件名.gitlab-ci.yml stages: - build - deploy build-job: stage: build script: - echo 开始构建 - mkdir -p dist - echo app-$(date %Y%m%d%H%M%S) dist/version.txt artifacts: paths: - dist/ deploy-job: stage: deploy script: - echo 开始部署 - ansible-playbook -i inventory/hosts.ini deploy.yml only: - main这个配置表达了两件事build-job负责构建生成dist/version.txt作为产物。deploy-job在 main 分支提交后执行调用 ansible-playbook 完成部署。artifacts用于把构建产物传递到后续阶段。实际项目中构建阶段可能是mvn package、npm run build、docker build等部署阶段也会更复杂但核心结构是一致的。需要说明不同工具、不同版本之间配置差异很大上面的写法只是用来理解思路实际使用时请以你选择的工具官方文档为准。5.4 与 Ansible、Shell 的组合方式CI/CD 并不是要替代 Ansible 和 Shell而是把两者集成到流水线里。常见的分工方式是CI 部分用工具自带的 script 执行构建命令比如 Maven、Gradle、npm。CD 部分调用 Ansible Playbook让 Ansible 负责目标服务器的配置变更和部署。在 Ansible Playbook 内部又可能需要调用 Shell 脚本来处理复杂逻辑比如启动脚本、健康检查脚本。也就是说越靠近“流程编排”的层级用 CI/CD 工具越靠近“服务器操作”的层级用 Ansible越靠近“单机细节”的层级用 Shell。这样划分之后每一层职责都清晰出了问题也好排查。6. 综合实战从代码提交到自动部署6.1 场景描述现在把前面所有内容串起来做一个完整的案例场景设定如下应用是一个简单的 Java 服务代码托管在 GitLab 仓库。项目中有三个文件需要自动化目标是把构建产物一个 jar 包部署到两台 web 服务器上并在部署完成后检查服务是否正常启动。完整的链路是代码提交 - GitLab CI 构建 jar 包 - 调用 Ansible Playbook - 分发 jar 包到两台服务器 - 执行 Shell 脚本启动服务 - 健康检查6.2 编写 Shell 部署脚本先写一个应用启动脚本放在项目的scripts/start_app.sh#!/bin/bash # 文件名scripts/start_app.sh APP_NAMEdemo-app APP_JAR/data/apps/demo/demo-app.jar PID_FILE/data/apps/demo/app.pid LOG_FILE/data/apps/demo/app.log start() { if [ -f $PID_FILE ] kill -0 $(cat $PID_FILE) 2/dev/null; then echo 应用已经在运行中PID: $(cat $PID_FILE) exit 0 fi echo 启动 $APP_NAME ... nohup java -jar $APP_JAR $LOG_FILE 21 echo $! $PID_FILE echo 启动完成PID: $(cat $PID_FILE) } start这个脚本做了三件最基本的事情检查进程是否已在运行、后台启动 Java 服务、把 PID 写入文件。健康检查脚本scripts/check_app.sh#!/bin/bash # 文件名scripts/check_app.sh HEALTH_URLhttp://127.0.0.1:8080/actuator/health for i in $(seq 1 15); do CODE$(curl -s -o /dev/null -w %{http_code} $HEALTH_URL || true) if [ $CODE 200 ]; then echo 健康检查通过HTTP 状态码: $CODE exit 0 fi echo 等待应用启动... ($i/15) sleep 2 done echo 健康检查失败 exit 1健康检查脚本的关键点是设置重试次数和超时时间避免应用还在启动过程中就被误判失败。6.3 编写 Ansible Playbook项目中的部署 Playbookdeploy.yml--- - name: 部署 demo-app 到 web 服务器 hosts: web_servers remote_user: ops become: yes vars: app_jar: demo-app.jar remote_dir: /data/apps/demo tasks: - name: 创建远程目录 ansible.builtin.file: path: {{ remote_dir }} state: directory mode: 0755 - name: 复制 jar 包到所有节点 ansible.builtin.copy: src: dist/{{ app_jar }} dest: {{ remote_dir }}/{{ app_jar }} mode: 0755 - name: 复制启动脚本 ansible.builtin.copy: src: scripts/start_app.sh dest: {{ remote_dir }}/start_app.sh mode: 0755 - name: 复制健康检查脚本 ansible.builtin.copy: src: scripts/check_app.sh dest: {{ remote_dir }}/check_app.sh mode: 0755 - name: 执行启动脚本 ansible.builtin.shell: bash {{ remote_dir }}/start_app.sh - name: 执行健康检查 ansible.builtin.shell: bash {{ remote_dir }}/check_app.sh register: check_result - name: 打印健康检查结果 ansible.builtin.debug: msg: {{ check_result.stdout }}这个 Playbook 的流程是创建目录 - 分发 jar 包 - 分发脚本 - 启动服务 - 健康检查。每一步都依赖上一步成功任何一步失败Ansible 都会中止后续任务这正是批量部署需要的特性。6.4 在 CI 中使用在项目根目录创建.gitlab-ci.yml# 文件名.gitlab-ci.yml stages: - build - deploy variables: APP_JAR: demo-app.jar build-job: stage: build script: - echo 开始构建应用 - mkdir -p dist - echo 模拟构建产物 dist/demo-app.jar artifacts: paths: - dist/ - scripts/ deploy-job: stage: deploy script: - echo 开始部署到服务器 - ansible-playbook -i inventory/hosts.ini deploy.yml only: - main这里用echo模拟了构建过程真实项目中会替换成实际的构建命令。artifacts把构建产物和脚本保存下来供 deploy 阶段使用。6.5 验证流程在本地手动模拟流水线的执行顺序# 1. 模拟 CI build 阶段 mkdir -p dist echo 模拟构建产物 dist/demo-app.jar # 2. 确认 ansible 能连通所有节点 ansible web_servers -i inventory/hosts.ini -m ping # 3. 执行部署 ansible-playbook -i inventory/hosts.ini deploy.yml如果一切正常你会看到 Ansible 逐台执行任务所有任务显示 ok 或 changed最终健康检查通过。之后任意一台服务器上执行cat /data/apps/demo/app.pid都能看到对应的进程 PID说明部署成功。这个案例虽然简单但已经具备了一个自动化部署闭环的完整骨架。理解它之后再往里面加变量、加环境隔离、加回滚逻辑都会容易很多。7. 常见问题与排查思路自动化运维上手过程中报错是非常正常的。这里整理几个高频问题问题现象常见原因解决思路ansible命令未找到pip 安装的是用户级PATH 未包含执行export PATH$PATH:~/.local/bin或安装后重新登录 shellSSH 连接超时或被拒绝未配置免密认证或目标机器 SSH 端口非默认用ssh-copy-id配置密钥检查ansible_user和端口参数任务执行报Permission denied当前用户无权限操作目标路径Playbook 中使用become: yes或确认用户是否在 sudo 组脚本执行成功但服务未启动脚本中 java 命令找不到或 PATH 不完整用绝对路径或在脚本中显式 export PATHPlaybook 重复执行结果不一致任务没有做到幂等使用模块内置的幂等操作如 file、copy、service而非 commandok状态但文件没更新copy 模块对比 src 与 dest 内容一致时不会覆盖检查源文件 md5 与目标文件是否一致需要强制更新时考虑用force: yes执行 shell 时提示/bin/bash^M脚本是 Windows 格式有 CRLF 换行在服务器上执行sed -i s/\r$// script.sh转换再补充一个较隐蔽的问题在使用ansible的shell模块时如果命令涉及管道、重定向或特殊字符要注意引号处理。ad-hoc 命令里建议把整条命令用双引号包起来Playbook 里则直接写在cmd:或shell参数中即可。排错时推荐一个通用思路先确认网络连通再确认认证然后确认路径权限最后确认命令本身。逐层排查比直接搜报错要快很多。8. 最佳实践与工程建议8.1 安全与权限尽量不用 root 直连。Ansible 的remote_user使用普通用户需要提权时通过become: yes完成。SSH 密钥代替密码登录私人密钥不要提交到代码仓库。文件权限遵循最小授权原则不要无脑 777配置文件 0644、脚本 0755 是常规选择。涉及生产环境变更先在一个测试节点验证再扩大到全量节点。Ansible 的limits和serial参数可以控制执行批次。批量变更生产环境时Ansible 的--check模式可以先做预检ansible-playbook -i inventory/hosts.ini deploy.yml --check--check不会真正修改目标机器只会模拟执行并报告可能发生的变化。这是上线前非常重要的手段。8.2 可维护性Playbook 中使用变量不要硬编码服务器 IP、路径和密码。敏感信息使用 Ansible Vault 加密。inventory 按环境拆分hosts-dev.ini、hosts-prod.ini不同环境用不同变量文件。Shell 脚本和 Ansible Playbook 都纳入 Git 管理变更可追溯。脚本尽量保持短小精悍一个脚本只做一件事方便复用和调试。所有脚本增加必要注释尤其是说明“为什么这么做”而不是“做了什么”。8.3 生产环境注意事项部署前备份关键文件和数据库部署失败时能快速回滚。使用滚动发布或分批发布避免一次性重启所有实例。健康检查要放到部署流程里服务未正常启动时自动停止流水线。保留历史产物比如按构建号或时间戳存放 jar 包便于回滚到上一个可用版本。日志集中收集CI/CD 的日志、Ansible 的执行日志、服务运行日志分开管理排查问题时能快速定位。有一条经验值得单独拿出来说自动化脚本上线初期宁可慢一点多做检查也不要为了“看起来自动化”而跳过验证步骤。自动化不是把不可靠的操作变成更快的不可靠操作而是把可靠的操作固化下来让每次执行结果都可预期。9. 给你的一点点学习建议最后说几个我对这套技术栈的真实感受。第一不要把三个东西分开学完再合。Ansible 和 Shell 完全可以边用边学你只要指定一批测试机器反复练习复制文件、执行命令、修改配置就够了不必背语法。第二所有练习都建议在测试环境进行。自己开两台虚拟机或者用云厂商的按量实例练完就释放成本很低。不要一上来就在生产环境试因为自动化脚本的破坏速度远高于手动操作一条错误的批量命令可能让所有服务器同时出问题。第三学自动化运维最忌讳只记命令。命令本身很容易查到真正的价值是流程设计能力知道哪些操作应该固化到脚本里哪些操作应该留给人工确认哪些操作需要增加回滚机制。这些能力靠的是不断做项目、不断踩坑。如果你现在刚好是从零开始不用着急照着这篇文章先搭好环境把第一个 Shell 脚本跑起来再用 Ansible 批量操作两台机器最后把一个最小的 CI/CD 流水线跑通。整套流程走下来你就能对自动化运维有非常直观的认识。接下来再根据实际项目需求往某个方向深入比如更复杂的 Playbook 写法、Jenkins 流水线、容器化部署都会轻松很多。
尧图网络