LuminDream's Blogs

当 AI 走进运维：这半年的观察与思考写这篇随笔时，正值 2025 年 8 月底。回看这一年多，AI 对运维工作的渗透比我想象中快，但方式又和很多人最初预测的不一样。趁着周末，把这段时间的观察整理成文字——不谈宏大叙事，只说我自己和身边真实发生的变化。 一、它真实地改变了我的日常排障：从”搜答案”到”问模型”现在拿到一个报错，我的第一反应已经不是复制去搜索引擎，而是把上下文完整地丢给大模型： 123456# 我现在喂给 AI 的"排障提问模板"（比直接贴一行报错有用得多）## 【环境】CentOS 7.9，Nginx 1.20，后端 Java 8 微服务# 【现象】高峰期 502 增多，Nginx error.log 出现 upstream timed out# 【已排查】后端存活、连接池未满、upstream 配置如下（贴配置）# 【疑问】还有哪些方向没查？ 把环境、现象、已做过的排查都交代清楚后，模型给的”嫌疑列表”质量明显高出一截——它经常能补上我没想到的方向，比如”检查 keepalive 超时与后端半连接数”这类容易被忽略的点。它不一定直接给答案，...

Ansible Roles 与 Jinja2：部署剧本工程化实战单文件剧本写到三百行的时候，问题开始集中爆发：NFS 的部署逻辑和 rsync 的混在同一份文件里，改一处要通读全文；换台机器复用，全靠复制粘贴。后来我把所有剧本按官方的 roles 规范重构了一遍，顺带用 Jinja2 解决了”每台机器配置不一样”的老大难。这篇把重构的思路和三个实战案例整理出来。 一、为什么要 rolesroles 解决的是解耦：把”装 Nginx””装 MySQL””基础优化”各自拆成独立模块，谁需要就引用谁。 对比一下两种写法： 1234567891011121314# 重构前：所有步骤堆在一个剧本里deploy_all.yml ├── 基础优化 30 行 ├── NFS 安装配置 60 行 ├── rsync 安装配置 80 行 └── 应用部署 100 行# 重构后：按角色拆分roles/ ├── base/ # 基础优化 ├── install_nfs/ # NFS ├── rsync/ # rsync └── app/ # 应用...

Ansible 流程控制实战：when、循环、handlers 与标签写过几个剧本之后，你一定会遇到同一类需求：同一套剧本，web 机器该装 Nginx、db 机器该装 MySQL；配置文件只有真改了才重启服务；上百行的剧本想只跑其中一段调试。这些”分岔”和”联动”靠的就是流程控制。这篇把 when、循环、handlers、tags、include 和错误处理挨个过一遍。 一、when：一套剧本适配多主机when 是条件和执行之间的开关，最典型的三个场景： 不同系统装不同的包名（CentOS 用 yum，Ubuntu 用 apt）； 客户端和服务器共用一个剧本，但只有服务端需要推配置文件； 源码编译先判断”是否已经装过”，避免重复执行。 12345678910111213- hosts: web_group tasks: - name: 安装 CentOS 的 httpd yum: name: httpd state: present when: ansible_facts['os_family'] ...

Ansible Playbook 与变量体系实战ad-hoc 命令解决”临时干一票”的问题，但真正要重复用的东西必须落成 playbook。我写第一个剧本时的最大困惑不是语法，而是变量：同一个值，写在剧本里、写在清单里、用 -e 传进来，到底谁说了算？这篇把 playbook 的基础和变量体系一起理清楚——变量搞明白了，剧本才谈得上复用。 一、Playbook 是什么Playbook（剧本）是 Ansible 的编排文件，核心就两个概念： play：定义”在哪批主机上执行”，对应 hosts； task：定义”具体做什么”，一条 task 调一个模块。 一个 playbook 可以包含多个 play，一个 play 可以包含多个 task。和 ad-hoc 的区别：ad-hoc 是一条命今一次执行，playbook 有明确的执行顺序和依赖关系，而且可以持久保存、重复执行。 二、YAML 语法速记剧本用 YAML 写，语法规则不多，但每条都必须严守，而且错得悄无声息（缩进错了直接语法报错，写错了往往不报错但行为不对）： 只用空格缩进，绝对不能用 Tab； 同层级左对齐，一层缩...

Ansible 常用模块实战：从软件包到数据库Ansible 用起来之后，我给自己整理过一份”模块速查表”——不是背参数，而是记住”哪类活对应哪个模块、关键参数是哪几个”。这份表后来成了我写剧本时的第一参考，这篇把它整理出来，从最常用的软件包、文件、服务，一直到用 community.mysql 批量管理数据库。 一、命令执行三兄弟1234567891011# command：默认模块，执行单条命令，不支持管道和重定向- name: 查看主机名 command: hostname# shell：需要管道、重定向、变量展开时用- name: 查 nginx 进程 shell: ps -ef | grep nginx# script：把本地脚本推到远端执行，不用手动分发- name: 执行本地检查脚本 script: /opt/ops-ansible/scripts/check.sh 原则很简单：能用 command 就用 command（更安全，没有 shell 注入问题），需要管道才换 shell。 二、软件包管理1234567# yum：安装/卸载/指定版本- name...

Ansible 入门实践：架构、安装与生产级 Inventory 管理公司服务器数量涨到三十多台的时候，我还在用最原始的办法：写个 for 循环，把 IP 列在脚本里，ssh 上去挨个执行。有一批机器的 SSH 端口改过，脚本跑一半断在中间，剩下的一半改了、一半没改——最后靠人工对账才收场。那次之后我把 Ansible 捡了起来，第一个动作就是把”哪些机器、分成几组、怎么连”从脚本里搬进 Inventory。 一、Ansible 是什么，为什么选它Ansible 是自动化配置管理工具，能力可以概括成几块： 远程执行：一条命令在多台主机上执行操作； 配置管理：批量配置软件服务，统一管理配置和启停； 事件驱动：按条件触发动作，比如”配置变了才重启服务”； 任务编排：用 playbook 把一套完整部署串起来，一条命令部署一整个架构； 跨平台：一套剧本兼容不同发行版，比如安装 Apache，CentOS 叫 httpd、Ubuntu 叫 apache2，Ansible 按系统类型分发。 它和手工脚本最本质的区别有两个：无 Agent（被控端什么都不用装，控制端通过 SSH 连过去执...

Jenkins 流水线实战：拉码、构建、发布与企微通知Jenkins 装好、SonarQube 能扫之后，我把整条链路串了一遍：开发推代码到 GitLab，Jenkins 自动拉取、扫描、打包，分发到 WEB 服务器完成切换，最后往企业微信群里发一条通知。这篇文章把这套流程的每一段拆开讲清楚，包括那个”软链切换”的发布方案——它是整条链路里最值得抄走的设计。 一、先看整条链路的全貌12345678910111213开发 push 代码 │ ▼GitLab 仓库 ── webhook 触发 ──► Jenkins │ 1. 拉取代码（SSH 密钥） │ 2. SonarQube 代码扫描 │ 3. 打包 tar.gz ▼ scp 分发到 WEB 服务器 ...

Jenkins 部署与 SonarQube 代码质量平台搭建公司内网环境要搭一套 CI，外网源一律不通，所有安装包都得先下载好再传进去。这种”离线两件套”（Jenkins + SonarQube）我装过两遍：第一遍边查文档边试，踩了权限和字体两个坑；第二遍顺手多了，这篇把完整流程整理出来。 一、为什么是 JenkinsJenkins 是基于 Java 的开源持续集成工具，监控持续重复的工作——拉代码、编译、测试、打包、部署，把这些动作从”人肉按顺序敲”变成”点一下按钮”。 它的定位是调度中心：自己不做具体的事，靠插件和脚本串联起 GitLab、SonarQube、构建机、部署目标。这也是它装完之后第一件事是装插件的原因。 二、部署：从 JDK 到启动Jenkins 2.4xx 之后的版本需要 JDK 11 以上，我用的 JDK 17。 1234567# 1. 安装 JDKrpm -ivh jdk-17_linux-x64_bin.rpmjava -versionrpm -qa | grep jdk # 确认装上了，输出 jdk-17-17.0.11-7.x86_64...

GitLab CI/CD 落地：Runner 注册与流水线模板实战上一篇文章里 GitLab 平台已经跑起来了，但开发还在找我手动拉代码、打包、传服务器。有次周五下午发版，我连做了六次”拉码、打包、scp、解压、换软链”，第七次是回滚。当天晚上我就把流水线搭了起来——人肉发布这件事，重复三次以上就该交给机器。 一、GitLab CI 的基本模型GitLab CI/CD 的逻辑不复杂： 代码仓库里放一个 .gitlab-ci.yml 文件，描述”要做什么”； Runner 是执行这些任务的代理，注册到 GitLab 之后领任务、干活、回报结果； 推送代码或创建 MR 触发流水线，按阶段顺序执行。 三个角色的分工：GitLab 负责调度，Runner 负责执行，yml 文件负责定义流程。运维的活主要在两块：把 Runner 管好，把 yml 模板写好给开发用。开发不需要懂 Runner 装在哪，只要知道”推代码之后跑去哪看结果”。 二、Runner 的注册与执行器选择Runner 可以注册在三个级别：项目级、组级、实例级。项目级最省事，实例级最通用，企业里一般...

GitLab 运维实战：部署、权限模型与备份恢复第一次接手 GitLab 是入职第二个月，前任运维交接时说了一句”这平台平时不用管，坏了再说”。结果第三周磁盘就写满了——仓库备份和日志把根分区撑爆，全组开发停工半天。从那以后我给 GitLab 定了两条规矩：磁盘单独挂盘并设监控，备份每天跑并且每月做一次恢复演练。这篇就是这套维护工作的完整记录。 一、运维和开发在 Git 上不是一回事同样是用 Git，职责完全不同： 维度 开发工程师 运维工程师 角色 Git 的使用者 平台的维护者 + 规范制定者 日常 写代码、提交、分支、合并、解冲突 部署维护 GitLab、管权限、备份恢复、配 Runner 关心点 我的代码能不能提交合并 平台稳不稳、权限对不对、能不能审计 典型操作 add / commit / push / merge gitlab-ctl、gitlab-rake、备份恢复 输出 业务代码 流水线模板、分支规范、审计记录 落到日常工作里，运维侧大概有这几块： GitLab 平台运维：安装升级、备份恢复、磁盘监...