LuminDream Hexo https://www.lumindream.site/ All rights reserved 2026, LuminDream 运维技术博客 · 书山有路勤为径 LuminDream's Blogs 2025-08-28T02:00:00.000Z LuminDream 当 AI 走进运维：这半年的观察与思考

写这篇随笔时，正值 2025 年 8 月底。回看这一年多，AI 对运维工作的渗透比我想象中快，但方式又和很多人最初预测的不一样。趁着周末，把这段时间的观察整理成文字——不谈宏大叙事，只说我自己和身边真实发生的变化。

一、它真实地改变了我的日常

排障：从”搜答案”到”问模型”

现在拿到一个报错，我的第一反应已经不是复制去搜索引擎，而是把上下文完整地丢给大模型：

1
2
3
4
5
6
# 我现在喂给 AI 的"排障提问模板"（比直接贴一行报错有用得多）
#
# 【环境】CentOS 7.9，Nginx 1.20，后端 Java 8 微服务
# 【现象】高峰期 502 增多，Nginx error.log 出现 upstream timed out
# 【已排查】后端存活、连接池未满、upstream 配置如下（贴配置）
# 【疑问】还有哪些方向没查？

把环境、现象、已做过的排查都交代清楚后，模型给的”嫌疑列表”质量明显高出一截——它经常能补上我没想到的方向，比如”检查 keepalive 超时与后端半连接数”这类容易被忽略的点。它不一定直接给答案，但确实帮我缩短了定位时间，尤其是那些”我怀疑是 A，其实是 B”的场景。

脚本与文档：初稿它写，质量关我把

写脚本的效率提升是最直观的。以前写一个日志统计脚本，从回忆语法到调试干净要小半天；现在把需求描述清楚，模型给的初稿基本能用，我再按生产标准改：补参数校验、加失败处理、写清日志输出。

1
2
3
4
# 典型协作流程（我在终端里的真实工作方式）
# 1. 描述需求：统计 access.log 中 5xx 占比，按小时输出，超过 10% 告警
# 2. 模型给初稿，我改造成巡检规范（函数、局部变量、日志落盘）
# 3. 手工验证两遍：造一条异常数据确认能触发告警

文档也受益——接口变更说明、故障复盘的结构化模板，让 AI 生成初稿再人工校对，省下的时间都花在了把话说准确上。

知识库：把团队的经验”喂”给 AI

企业内部最大的变化，是知识库问答助手的落地。我们把历年的故障记录、变更文档、环境清单整理成语料，做检索增强问答，值班同学遇到问题先问它：

语料类型具体内容价值
故障复盘根因、处理链路、止血动作新人不用”重新踩一遍坑”
变更记录什么时间改了什么、影响面快速定位”是不是变更引起的”
环境清单机器清单、拓扑、账号归属少问”这台是干嘛的”
常见问题运维知识库 FAQ值班第一道过滤

以前”老员工离职知识就断了”的问题，第一次有了系统性的解法。今年年初 DeepSeek-R1 开源之后，这类私有化部署的成本变得可接受，身边不少团队都在做类似的事。

二、我实际用 AI 做什么：一张分布表

场景频率AI 的角色我的把关点
报错分析 / 排障方向每天多次给嫌疑列表环境上下文是否交代清楚
脚本 / 配置初稿每天写初稿生产标准改造 + 验证
文档 / 复盘结构每周搭框架事实准确性
告警 / 日志模式分析每周找规律数据口径是否正确
知识库检索问答每天定位沉淀文档答案要回到原文核对

一个值得记住的观察：AI 用得越多，越发现”把问题描述清楚”本身是稀缺能力——环境、现象、已排查项、期望输出，这些信息组织得好，AI 和同事都能更快帮你。

三、它没有改变的东西

线上出了问题，模型可以告诉我”可能的原因”，但它不会替我被扣绩效，也不会替我跟业务方解释为什么影响了半小时。故障处理里最重的部分从来不是”知道答案”，而是在信息不完整、时间紧迫、多方压力下做决策——这部分需要的不是知识，是判断和担当。

还有一个更微妙的点：模型的建议在”标准环境”里很准，在生产环境里经常差一口气。我们的环境有太多历史包袱——遗留脚本、没文档的配置、说不清来由的依赖——这些”非标准”的东西模型看不到，只有人对这套系统的理解是完整的。所以 AI 给我的建议，我默认只信一半，另一半要靠对业务和环境的理解去校准。

关于”判断力”这件事，我在之前的文章里也聊过：排障的本质不是背命令，而是沿着正确的链路缩小范围——《进程与性能排查实战》、《日志排查体系》 里写的就是这套思路，AI 帮我把”缩小范围”这步做得更快，但”判断哪个方向值得查”仍然是人。

随着 AI 生成代码的能力变强，代码以外的质量责任反而更重了：变更的影响范围、回滚方案、监控覆盖——这些”上线前的最后一道关”，从来都是人在把。

四、行业里几个真实的时间点

这几个是我确切经历过的节点，写在这里提醒自己别被一时喧嚣带偏：

  • 2016 年：Gartner 提出 AIOps 概念，”智能运维”的口号喊了很多年；
  • 2021 年：GitHub Copilot 发布，代码辅助工具进入大众视野；
  • 2023 年：GPT-4、Claude 3 相继到来，大模型开始真正”能用”；
  • 2024-12：DeepSeek-V3 发布，开源模型性能第一次追上闭源第一梯队；
  • 2025-01：DeepSeek-R1 开源推理模型引爆讨论，也把”私有化部署大模型”的成本打了下来；
  • 2025 上半年：身边越来越多团队做出内部 AI 助手，AIOps 的落地场景回归理性——告警降噪、日志异常检测、根因分析辅助这三件事，做得比”端到端自动运维”实在得多。

写到这里特别提醒自己：AI 的发展太快，任何”预测”过三个月就会失真。这篇随笔只记录 2025 年 8 月这个时点真实发生的事，不做预言。下个季度回来看，大概率又不一样了。

五、我给自己定的三条原则

  1. 把它当放大器，不当拐杖：AI 帮我做得更快的事，我要清楚每一步在干什么——它错了我也要能看出来；
  2. 围绕”判断力”积累：命令和语法可以被生成，但对系统边界的理解、对风险的嗅觉、对业务的认知，只会越来越值钱；
  3. 文档和知识库变成硬资产：以前写文档是交接用，现在它们还是 AI 助手的”饲料”——写清楚、结构化，AI 才能帮上忙。

结语

2025 年的这个夏天，AI 对运维来说既不是革命也不是泡沫。它更像一个”能力很强的实习生”：上手快、知识面广，但需要有人定方向、把关、兜底。而我想要的定位，就是那个把关和兜底的人——顺便把实习生用得越来越好。

]]> https://www.lumindream.site/2025/08/28/%E5%BD%93AI%E8%B5%B0%E8%BF%9B%E8%BF%90%E7%BB%B4%E8%BF%99%E5%8D%8A%E5%B9%B4%E7%9A%84%E8%A7%82%E5%AF%9F%E4%B8%8E%E6%80%9D%E8%80%83/ 2025-08-28T02:00:00.000Z 从 DeepSeek 开源到企业内部 AI 助手落地，一个运维工程师在 2025 年夏天的真实观察：它改变了什么、改变不了什么、以及我们该往哪走。 当 AI 走进运维：这半年的观察与思考 2025-08-28T02:00:00.000Z LuminDream JSON 速通：运维视角的配置规范与排错

运维每天都在和 JSON 打交道——Prometheus 告警规则、Grafana Dashboard、K8s 资源清单、各种服务配置文件，全是 JSON 或它的表亲 YAML。但大多数人只在”报错时”才想起它的语法。这篇用运维视角把 JSON 速通一遍。

一、JSON 是什么（一句话）

JSON = 用文本表示”键值对 + 嵌套”的数据格式，人和机器都能读。本质就是一棵树。

二、只有 6 种数据类型（背下来）

类型写法示例
字符串双引号"nginx"
数字直接写80、1.5
布尔true/falsetrue
数组方括号["a","b"]
对象花括号{"key":"value"}
空nullnull

注意：字符串必须双引号，单引号在 JSON 里是非法字符——这是新手第一大坑。

三、结构速记：它就是一棵树

1
2
3
4
5
6
7
8
9
{
  "server": {
    "host": "10.0.8.11",
    "port": 80,
    "enabled": true,
    "tags": ["web", "prod"],
    "note": null
  }
}

读法：server 是根对象 → 里面 5 个键值对 → tags 是数组。心里有一棵树，嵌套就永远不乱。

四、运维真实配置长什么样

Prometheus 告警规则（每段都是”对象数组”）：

1
2
3
4
5
6
7
8
9
[
  {
    "alert": "NodeDown",
    "expr": "up == 0",
    "for": "5m",
    "labels": { "severity": "critical" },
    "annotations": { "summary": "节点 {{ $labels.instance }} 挂了" }
  }
]

五、最容易写错的 7 个坑（重点看）

  1. 单引号：JSON 字符串只能用双引号；
  2. 多余逗号：最后一个元素后面不能有逗号（["a","b",] ✗）；
  3. 少了逗号：对象/数组元素之间必须有逗号；
  4. 括号不配对：花括号方括号成对出现，层数多时从里往外数；
  5. 键没加引号：键必须是双引号字符串（{host: "x"} ✗，{"host":"x"} ✓）；
  6. 注释：JSON 不支持注释（YAML 的注释习惯别带进来）；
  7. 值裸写：undefined、NaN 不是合法值，用 null。

六、怎么快速校验「我写的 JSON 对不对」

1
2
3
4
5
6
7
8
9
10
11
# jq（神器，还能提取字段）：解析失败会明确报出行列
jq . config.json

# 提取/过滤（运维高频）
jq '.server.port' config.json          # 取值
jq '.[] | select(.alert=="NodeDown")' rules.json   # 过滤

# python 兜底（没装 jq 时）
python3 -m json.tool config.json

# 在线校验：json.cn 等（生产环境别贴敏感配置！）

七、3 分钟上手练习

1
2
3
# 1. 写一个 10 行配置，用 jq 校验
# 2. 故意写错一处（忘了逗号），看 jq 报错的行号位置
# 3. 用 jq 提取嵌套字段，习惯"树上取值"的思维

八、一句话总结

JSON 的规矩只有 6 种类型和 7 个坑，写完先 jq . 校验再贴进生产配置——这一条习惯能避开 90% 的配置文件事故。遇到 YAML/TOML 同理，格式校验永远在”应用重启”之前。

]]> https://www.lumindream.site/2023/08/27/json%E9%80%9F%E9%80%9A%E8%BF%90%E7%BB%B4%E8%A7%86%E8%A7%92%E7%9A%84%E9%85%8D%E7%BD%AE%E8%A7%84%E8%8C%83%E4%B8%8E%E6%8E%92%E9%94%99/ 2023-08-27T02:00:00.000Z 服务配置、Prometheus 告警规则、K8s 资源清单全是 JSON 系格式：6 种数据类型、7 个高频写错点、jq/python 快速校验，运维够用版。 JSON 速通：运维视角的配置规范与排错 2023-08-27T02:00:00.000Z LuminDream HTTP 协议与 Web 服务排障

浏览器报个 502、504，运维的第一反应应该不是”重启”,而是能准确说出这个状态码代表哪一层出了问题。这篇把 HTTP 协议的生产用法整理成一套排障体系。

一、HTTP 是什么

HTTP（超文本传输协议）把超文本文档从 Web 服务器传输到浏览器，应用层协议，基于 TCP 80/443。

URL 组成：协议://主机:端口/路径。三个特点：

  1. 请求/响应模型：客户端发请求，服务端回响应；
  2. 无状态：HTTP 本身不记录用户状态（靠 Cookie/Session 补）；
  3. 基于 TCP：先三次握手，再传 HTTP 报文。

一条命令看全流程（curl -v 是 Web 排障的第一工具）：

1
2
3
4
5
curl -v http://www.example.com/
# Trying 1.1.1.1...          ← DNS 解析出的 IP
# Connected to ...            ← TCP 连接建立（三次握手）
# > GET /index.html HTTP/1.1  ← 发出请求
# < HTTP/1.1 200 OK           ← 收到响应

二、请求方法与响应结构

GET vs POST：GET 参数在 URL 里（?a=1&b=2），POST 参数在请求体里。POST 更安全——参数不留在日志和地址栏。

响应报文：状态行（HTTP/1.1 200 OK）+ 头部 + 响应体。

三、状态码：生产高频场景（面试必问）

状态码含义排障方向
502 Bad Gateway反向代理连不上后端（Tomcat 挂了/端口不通/连接数满）ss -lnt 看后端端口 → tail 后端日志 → curl 后端健康检查
504 Gateway Timeout连上了后端但响应超时（后端慢/排队）后端日志、慢查询、线程池满
503 Service Unavailable服务暂时不可用（重启/维护/限流）看部署状态、限流配置
403 Forbidden无权限（nginx deny/目录权限）nginx 配置、文件权限
404 Not Found资源不存在路径写错、静态资源没部署
1
curl -s -o /dev/null -w "%{http_code}" http://localhost/   # 快速看状态码

四、关键头部字段（运维用途）

头部运维用途
Servercurl -I 识别 Web 服务版本（安全审计/指纹）
Referer防盗链判断——图片 403 先看 Referer
Host决定 Nginx 走哪个 server 块——多站点访问错页面先查 Host
User-Agent区分爬虫/正常用户（封爬虫按 UA）

五、重定向 301/302/304

1
2
3
301 永久重定向：域名换了 / HTTP 跳 HTTPS（SEO 权重转移）
302 临时重定向：临时跳转（登录后跳回、活动页）
304 Not Modified：资源没变直接用缓存（配合 Last-Modified/ETag）

Nginx 配置示例：

1
2
3
4
5
server {
    listen 80;
    server_name www.example.com;
    return 301 https://$host$request_uri;   # HTTP 全站跳 HTTPS
}

六、PV / UV / IP（站长口径）

1
2
3
PV（Page View）：页面浏览量，一个人点 2 次算 2 个 PV
UV（Unique Visitor）：独立访客（去重 Cookie/设备），只算 1 个
IP：独立 IP 数（同一 NAT 出口只算 1 个）

经典计算题：公司大厦 100 人、每人 2 台设备、走同一个 NAT 出口、每人点 2 次 → PV=400、UV=200、IP=1。PV ≥ UV ≥ IP 永远成立；IP 在 NAT 场景只是近似值。

七、Web 全链路排障（面试讲故障故事用）

用户报”网站打不开”，从外层到内层逐层看：

1
2
用户浏览器 → DNS 解析 → 防火墙/安全组 → 负载均衡健康检查 → Nginx 日志
(access/error) → Tomcat 日志 → MySQL 慢查询 → 监控图（Zabbix/Prometheus）

入门手段永远是一句话：先 curl 本地确认服务在，再一层层往外查。用户反馈”打开慢”时用浏览器 F12 → Network → Timing 看各段耗时，定位是 DNS 慢、TCP 慢还是 TTFB（服务端处理慢）——比瞎猜快得多。

HTTP 这一层是 Web 排障的”界面层”：状态码告诉你错在哪一段，头部告诉你细节，curl 帮你复现全过程。配合前面的 TCP 和 DNS 知识，一条链路就完整了。

]]> https://www.lumindream.site/2023/08/24/http%E5%8D%8F%E8%AE%AE%E4%B8%8Eweb%E6%9C%8D%E5%8A%A1%E6%8E%92%E9%9A%9C/ 2023-08-24T02:00:00.000Z 网站报错怎么快速定位：HTTP 报文结构、请求方法、状态码语义（502/504/503/403/404）、关键头部字段、301/302/304 区别，以及全链路排查流程。 HTTP 协议与 Web 服务排障 2023-08-24T02:00:00.000Z LuminDream DNS 解析原理与排障实战

“网站打不开”的排查里，DNS 是最容易被忽略、又最常出问题的一层——IP 能访问、域名不能，十有八九就是它。这篇把 DNS 的完整解析流程和排障方法讲透。

一、DNS 是什么

DNS（域名系统）把域名翻译成 IP，好比电话簿：记名字不记号码。端口：一般走 UDP 53，数据量大或区域传输时走 TCP 53。

常用记录类型：

记录作用示例
A域名 → IPv4www.example.com → 1.1.1.1
AAAA域名 → IPv6—
CNAME别名（CDN 加速常用）www 指向 cdn.example.com

常用公共 DNS：阿里 223.5.5.5、腾讯 119.29.29.29、114.114.114.114、谷歌 8.8.8.8。

二、完整解析流程（递归 + 迭代）

以浏览器输入 www.baidu.com 为例：

1
2
3
4
5
6
7
8
9
10
11
第1步 查浏览器缓存
第2步 查操作系统缓存
第3步 查本地 hosts 文件（Windows: C:\Windows\System32\drivers\etc\hosts；Linux: /etc/hosts）
第4步 都没命中 → 请求本地 DNS 服务器（LDNS，如 223.5.5.5）【递归查询】
第5步 LDNS 先查自己的缓存，没有则开始【迭代查询】：
   ① LDNS 问根域名服务器"."（全球 13 个根，内置在 LDNS 里）
   ② 根服务器返回 .com 顶级域服务器 IP
   ③ LDNS 问 .com 顶级域服务器 → 返回 baidu.com 权威服务器 IP
   ④ LDNS 问 baidu.com 权威服务器 → 权威服务器查 A 记录，返回 www.baidu.com 的 IP
第6步 LDNS 缓存一份，把 IP 返回给客户端；客户端也缓存一份
第7步 浏览器用 IP 与服务器建立 TCP 连接

两种查询方式（面试必答）：

  • 递归查询：客户端 → 本地 DNS。客户端只问一次，LDNS 负责跑腿；
  • 迭代查询：本地 DNS → 根 → 顶级 → 权威。LDNS 逐级问，每级只告诉”下一级去哪问”。

三、排障命令

1
2
3
4
5
6
7
8
9
10
yum install -y bind-utils

dig www.baidu.com            # 最详细（推荐）
dig +trace www.baidu.com     # 看完整迭代链路（劫持排查神器）
nslookup www.baidu.com       # 基础查询
host www.baidu.com           # 精简查询

# 常见排查点：
cat /etc/resolv.conf         # nameserver 配置
grep domain /etc/hosts       # hosts 有没有被污染

四、三个真实故障案例

案例 1：网站突然打不开，IP 能访问、域名不能

排查链路：nslookup 域名 → 超时/无记录 → 查 /etc/resolv.conf → 发现 nameserver 写的是内网 DNS → 换 223.5.5.5 立即可解析。

根因：公司内网 DNS 故障/上游被污染。解决：切换 DNS 或同时配置多个 nameserver（nameserver 223.5.5.5 + nameserver 114.114.114.114）。

案例 2：dig +trace 发现权威服务器返回异常 IP（域名被劫持）

现象：解析结果指向一个不明 IP，访问弹广告。

处理：联系域名服务商核查解析记录；检查是否有 CNAME 被篡改；确认域名管理后台没有被盗号（查登录记录、改强密码）。

案例 3：CDN 切换后部分地区访问慢

现象：CDN 配置已切换，但部分用户还访问旧节点。

根因：LDNS 缓存了旧 IP，TTL 未到。处理：等 TTL 过期，或通知运营商刷新缓存。

生产规范：改解析前先看当前 TTL，提前把 TTL 调小（如 300 秒）再改记录，改完再恢复 TTL——避免切换后长时间缓存旧地址。

五、DNS 排障心法

遇到”域名不通”，按这个顺序走：本机 dig 看解析结果 → hosts 有没有污染 → resolv.conf 对不对 → 换公共 DNS 交叉验证 → dig +trace 看链路 → 联系域名服务商。其中”换公共 DNS 交叉验证”能快速区分是”本地 DNS 问题”还是”权威解析问题”，是效率最高的一步。

]]> https://www.lumindream.site/2023/08/17/dns%E8%A7%A3%E6%9E%90%E5%8E%9F%E7%90%86%E4%B8%8E%E6%8E%92%E9%9A%9C%E5%AE%9E%E6%88%98/ 2023-08-17T02:00:00.000Z 网站打不开先查 DNS：递归与迭代查询全流程、dig/nslookup/host 用法、三个真实解析故障案例（解析超时/被劫持/CDN 缓存）。 DNS 解析原理与排障实战 2023-08-17T02:00:00.000Z LuminDream TCP 协议实战：握手、挥手与连接排障

TCP 是面试必问、排障必用的核心协议。三次握手为什么是三次？大量 CLOSE_WAIT 怎么办？这篇把原理和排障串成一条线，附抓包实证。

一、TCP vs UDP：先分清楚

特性TCPUDP
连接面向连接（三次握手）无连接
可靠可靠（确认重传）不可靠
效率低高
应用HTTP/HTTPS、邮件、FTPDNS(53)、视频流、语音、DHCP

类比记忆：TCP 是”外卖必须送到你手里（有确认）”，UDP 是”放门口就走（无确认）”。端口范围 1~65535。

二、三次握手（原理 + 抓包）

1
2
3
4
5
6
7
客户端 C                          服务端 S
   │  SYN(seq=x)                    │
   │───────────────────────────────>│  S 收到，状态 SYN_RCVD
   │  SYN+ACK(seq=y, ack=x+1)       │
   │<───────────────────────────────│
   │  ACK(ack=y+1)                  │
   │───────────────────────────────>│  连接建立

三个关键点（面试背诵版）：

  1. SYN 报文不携带数据，但消耗一个序列号；
  2. 第 2 次握手把”确认 ACK”和”请求 SYN”合并成一个报文——所以是三次不是四次；
  3. seq/ack 都 +1 是确认机制核心：ack = 对方 seq + 1，表示”下次该收 x+1 了”。

抓包实证（tcpdump 抓 80 端口）看三个包的 seq/ack 严格递进——第 2 个包 ack = 第 1 个包 seq+1。

为什么不能只有两次握手？ 场景：客户端发出 SYN 在网络滞留，超时重发后正常完成连接并释放；此时滞留的旧 SYN 才到达服务端——如果只有两次握手，服务端会为这个”已失效的请求”建立连接并一直占用资源。三次握手里，服务端发出 SYN+ACK 后必须等客户端的 ACK 才建立——客户端没发新请求就不会回 ACK，服务端等不到就自动放弃。一句话：两次握手无法确认”客户端能收到服务端的报文”，也无法拒绝失效的旧请求。

三、四次挥手与 2MSL

1
2
3
4
5
6
7
8
9
10
客户端 C                            服务端 S
   │  FIN(seq=m)                     │
   │───────────────────────────────>│
   │  ACK(ack=m+1)                   │  S 还有数据要发，先确认
   │<───────────────────────────────│
   │   ...S 继续发剩余数据...          │
   │  FIN(seq=n)                     │
   │<───────────────────────────────│
   │  ACK(ack=n+1)                   │  C 进入 TIME_WAIT，等 2MSL
   │───────────────────────────────>│

为什么挥手 4 次而握手 3 次？ 握手时服务端可以把”确认+请求”合并成一个包（SYN+ACK）；挥手时服务端收到 FIN 后可能还有数据要发，不能立刻 FIN，必须先 ACK 再等数据发完单独 FIN——所以多一次。

挥手后客户端为什么要等 2MSL（Linux 默认约 60s）？

  1. 最后的 ACK 可能丢失——服务端没收到会重发 FIN，客户端在 TIME_WAIT 期间还能再回一次 ACK；
  2. 保证旧报文在网络中彻底消失，不会污染新连接。

四、连接状态与生产排障（重点）

1
2
ss -tulnp    # 查看连接状态统计
ss -s        # 汇总

三类生产高频异常：

状态含义处理
大量 CLOSE_WAIT对端关了，应用没关连接（代码层泄漏）查应用：Java 连接池泄漏、请求未关闭；ss -lnt | grep CLOSE_WAIT 确认，修代码/调连接池
大量 TIME_WAIT主动断开方等待 2MSL高并发短连接的正常现象；用 keep-alive 连接复用减少；net.ipv4.tcp_tw_reuse=1 谨慎开启
大量 SYN_RCVD收到 SYN 未完成握手，半连接堆积可能被 SYN 洪水攻击；查半连接队列 ss -lnt | grep SYN，上限 net.ipv4.tcp_max_syn_backlog，配合防火墙限速

连接不上的四步排查（任何”连不上”都按这个顺序）：

1
2
3
4
1. ss -lnt            # 服务有没有监听
2. telnet IP 端口      # 端口通不通（不通→防火墙/安全组）
3. 本机 curl           # 服务本身是否正常
4. 抓包看握手          # tcpdump -i eth0 port 端口：SYN 有没有到、有没有回 SYN-ACK

TCP 的问题说到底是”连接建不起来（握手）”和”连接关不掉（挥手/资源泄漏）”两类。把状态机和排障命令对应起来，大部分网络故障都能落地到具体的一层。

]]> https://www.lumindream.site/2023/08/10/tcp%E5%8D%8F%E8%AE%AE%E5%AE%9E%E6%88%98%E6%8F%A1%E6%89%8B%E6%8C%A5%E6%89%8B%E4%B8%8E%E8%BF%9E%E6%8E%A5%E6%8E%92%E9%9A%9C/ 2023-08-10T02:00:00.000Z 面试必问、生产必用的 TCP：三次握手为什么是三次、四次挥手为什么要等 2MSL、CLOSE_WAIT/TIME_WAIT/SYN_RCVD 三种异常状态的排查与处理。 TCP 协议实战：握手、挥手与连接排障 2023-08-10T02:00:00.000Z LuminDream 网络基础与 IP 子网规划实战

网络是运维一切排障的地基。报障电话里”上不了网””跨网段不通”的根因，80% 落在 IP 规划、掩码、网关这三件事上。这篇把网络基础与 IP 子网规划完整过一遍。

一、网络单位换算（先把这个算明白）

网络里最常见的”看起来很快”陷阱：

1
2
3
4
100Mbps 网卡 = 每秒传输 100M 个 bit
1 byte = 8 bit
100Mbps = 100000/8 KByte/s = 12500 KB/s ≈ 12.5 MB/s
千兆网卡 = 100 MB/s

所以百兆网卡实际跑 12.5MB/s 是”满速”，不是网卡坏了。存储单位按 1024 进制（K/M/G/T），网络单位按 1000 进制，这个差异也是排障时对不上数的主要原因。

二、网络设备三个角色

  • 交换机（二层）：让同一网络内的多台主机互通。靠 MAC 地址寻址（网卡物理地址，全球唯一，16 进制）。早期靠广播发数据，广播太多会形成”广播风暴”——拆成多个小局域网（广播域）解决；
  • 路由器（三层）：实现不同局域网互通，隔离广播风暴。路由 = 数据跨网段到达目的地的传递过程；
  • 网关：去往其他网段的必经之路（路由器的 IP）。看路由表：
1
2
route -n
# 0.0.0.0  10.0.8.254  0.0.0.0  UG  eth0   ← 默认路由，10.0.8.254 是网关

口诀记忆：交换机 = 认识的人（局域网内），路由器 = 朋友介绍的朋友（跨网段）。

三、分层模型：OSI 七层 vs TCP/IP 四层

OSI 七层（从下到上）：物理层 → 数据链路层 → 网络层 → 传输层 → 会话层 → 表示层 → 应用层。实际用的是 TCP/IP 四层（网络接口/网络/传输/应用）。

数据封装与解封装：

1
2
发送（封装，从上到下逐层加头）：应用 → TCP头+数据 → IP头+TCP头+数据 → 帧头+... → 比特流
接收（解封装，从下到上逐层去头）：逆过程

排障时”数据走到哪一层断了”是核心思路：物理层不通看网线/网卡，网络层不通看 IP/路由，传输层不通看端口，应用层不通看服务。

四、IP 地址与子网划分

分类与私有地址

IP = 网络号 + 主机号。公网地址全球唯一（Inter NIC 分配），私网地址组织内部使用可重复（RFC 1918）：

1
2
A类 10.0.0.0/8        B类 172.16.0.0/12      C类 192.168.0.0/16
默认掩码：/8=255.0.0.0   /16=255.255.0.0       /24=255.255.255.0

子网掩码与可用主机数

掩码的作用：区分网络号与主机号（网络位为 1，主机位为 0）。

1
2
3
4
一个网段可用地址 = 2^n - 2（n=主机位数，去掉网络地址和广播地址）
/24：2^8-2 = 254 台可用
/29：2^3-2 = 6 台可用
/30：2^2-2 = 2 台（点对点链路常用）

子网划分（向主机位借位）

生产场景：运营商给了 116.63.0.10/29——实际可用 6 个 IP（网络地址 .9 之后的 6 个，网关一般用第一个可用）。

1
2
172.20.1.0/18 → 掩码 255.255.192.0
（11111111 11111111 11000000 00000000，网络位 18 位）

划分的意义：防止地址浪费、隔离广播域、降低网关负载。计算工具用 subnet 计算器，但面试和排障要能手算掩码和可用数。

VLSM / CIDR

  • VLSM：可变长子网掩码——大段里再细分小段（如 /24 拆 4 个 /26）；
  • CIDR：无类域间路由——/n 记法的来源，IP 段合并表达（如 10.0.8.0/24 表示整个网段）。

五、Linux 网卡配置（CentOS 7）

1
2
3
4
5
6
7
8
9
10
11
12
# 文件：/etc/sysconfig/network-scripts/ifcfg-eth0
TYPE=Ethernet
BOOTPROTO=none          # 服务器固定 IP
IPADDR=10.0.8.11
PREFIX=24
GATEWAY=10.0.8.1
DNS1=223.5.5.5
ONBOOT=yes

# 生效：systemctl restart network（或 nmcli con reload）
# 临时加 IP（重启失效）：
ip addr add 10.0.8.12/24 dev eth0

六、常用排障命令速查

1
2
3
4
5
6
7
8
9
10
ping -c3 10.0.8.1            # 连通性（不通 ≠ 不可达——可能禁 ICMP）
traceroute www.example.com    # 路由跟踪，看卡在哪一跳（跨机房慢排查）
telnet 10.0.8.11 3306        # 端口通不通（服务级别，比 ping 高一层）
nc -vz 10.0.8.11 22          # netcat 快速端口检测
ss -tulnp                    # 监听端口与状态（比 netstat 快）
ss -lnt | grep SYN           # 半连接队列（SYN 洪水排查）
tcpdump -i eth0 tcp port 22  # 抓包（看握手、看请求有没有到本机）
nmap -sT -p 80,443 10.0.8.11 # 端口扫描（只扫自己管理的资产！）
route -n                     # 路由表
curl -v http://10.0.8.11/    # 应用层连通 + 全流程

上不了网排查流程（从下往上逐层排除）：

1
2
3
4
1. 网卡/物理层：ip a 看 IP 有没有、网线灯亮不亮
2. 网络层：ping 网关 → 通了说明本段通；ping 公网 IP（如 223.5.5.5）→ 不通查路由
3. 传输层：telnet 目标端口
4. 应用层：DNS 能不能解析（nslookup）、服务起没起

哪一层断了就处理哪一层——这是网络排障唯一正确的打开方式。下一篇把 TCP 协议本身讲透。

]]> https://www.lumindream.site/2023/08/03/%E7%BD%91%E7%BB%9C%E5%9F%BA%E7%A1%80%E4%B8%8EIP%E5%AD%90%E7%BD%91%E8%A7%84%E5%88%92%E5%AE%9E%E6%88%98/ 2023-08-03T02:00:00.000Z 从网速换算到子网划分：网络单位与设备、OSI/TCP/IP 分层、IP 分类与子网掩码、借位划分与 VLSM/CIDR，附网卡配置和常用排障命令。 网络基础与 IP 子网规划实战 2023-08-03T02:00:00.000Z LuminDream 定时备份与实时同步落地：cron + rsync + sersync

上一篇配好了 rsync 备份通道，但”能传”不等于”可靠”。真正的企业备份要有三件事：定时自动跑、校验完整性、失败要告警。这篇把备份闭环补完，再加一份”实时同步”方案。

一、定时备份：一个完整的客户端脚本

脚本职责：打包要备份的内容 → 携带 md5 校验信息 → 推送到备份服务器 → 本地只留最近 7 天。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
#!/bin/bash
# 客户端备份脚本：/server/scripts/client_rsync_backup.sh
# 1. 定义变量
BACKUP_SERVER="backup-server"
BACKUP_MODULE="web01"
SRC_DIR="/server/scripts /etc/nginx /var/www"
DST="/backup"
TS=$(date +%F)

# 2. 创建备份目录
mkdir -p $DST/$TS

# 3. 打包对应文件（已存在不重复打包）
cd $SRC_DIR_ROOT 2>/dev/null
[ -f $DST/$TS/scripts.tar.gz ] || tar zcf $DST/$TS/scripts.tar.gz -C /server scripts

# 4. 携带 md5 校验信息
find $DST/$TS -type f -name "*.tar.gz" | xargs md5sum > $DST/$TS/md5_$TS.txt

# 5. 推送至备份服务器
rsync -av --password-file=/etc/rsync.pass $DST/ rsync://$BACKUP_SERVER::$BACKUP_MODULE/

# 6. 本地保留最近 7 天
find $DST -mtime +7 -exec rm -rf {} \;
1
2
# 每天 01:00 执行
0 1 * * * /server/scripts/client_rsync_backup.sh >> /var/log/backup.log 2>&1

二、校验 + 邮件告警（服务端）

备份传完不算完，还得确认备份是完整的。服务端每天对账：用客户端留下的 md5 文件校验落盘数据，结果发邮件给管理员。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
#!/bin/bash
# 服务端校验脚本：/server/scripts/check_backup.sh
# 1. 定义变量
BACKUP_DIR="/backup/web01"
TS=$(date +%F)
MAIL_TO="ops@example.com"

# 2. 用 flag 文件做 md5 校验，结果存 result_日期
cd $BACKUP_DIR
[ -f $TS/md5_$TS.txt ] || exit 1
md5sum -c $TS/md5_$TS.txt > result_$TS.txt 2>&1

# 3. 把校验结果发给管理员
mailx -s "web01 备份校验 $(date +%F)" $MAIL_TO < result_$TS.txt

# 4. 清理：删除超过 7 天的校验结果、超过 180 天的备份数据
find $BACKUP_DIR -name "result_*" -mtime +7 -delete
find $BACKUP_DIR -type d -mtime +180 -exec rm -rf {} \;
1
2
# 每天 05:00 执行校验（备份 01:00 完成后，留足传输时间）
0 5 * * * /server/scripts/check_backup.sh

没有变量的备份是”假备份”，而这个闭环是：传完即校验、校验完即告警、告警完留痕。

三、实时同步：sersync（rsync + inotify）

定时任务有延迟——文件刚被篡改、或者业务要求秒级同步时，要用 inotify 监听目录变化，变化即触发 rsync。sersync 是最成熟的封装（原生 inotify-tools 脚本易漏事件）。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
# 1. 服务端（目标机）装 rsync 并配好多模块（同上篇 rsyncd.conf）
# 2. 客户端装 sersync（依赖 inotify 和 rsync）
wget https://example.com/sersync.tar.gz
tar zxf sersync.tar.gz -C /usr/local && cd /usr/local/sersync

# 3. 配置 confxml.xml 关键项（先备份再改）
# <fileSystem xfs="true"/>
# <filter start="false">           排除不想同步的文件（按需开启）
#   <exclude expression="(.*)\.svn"/>
# </filter>
# <inotify>
#   <delete start="true"/>
#   <createFolder start="true"/>
#   <createFile start="true"/>
#   <closeWrite start="true"/>
#   <moveFrom start="true"/>
#   <moveTo start="true"/>
#   <attrib start="false"/>
# </inotify>
# <localpath watch="/data/www">    监控目录
#   <remote ip="10.0.8.41" name="data"/>
# </localpath>
# <rsync>
#   <commonParams params="-az"/>
#   <auth start="true" users="rsync_backup" passwordfile="/etc/rsync.pass"/>
# </rsync>
# <failLog path="/tmp/rsync_fail_log.sh" timeToExecute="60"/>  失败每 60 分钟重试

# 4. 启动（-d 守护；-r 启动前先全量同步一次）
/usr/local/sersync/sersync2 -d -r -o /usr/local/sersync/confxml.xml

坑位提醒：同步多个目录需要多份 confxml + 多进程，一份配置管一个目录；海量文件场景先调大 inotify 上限：

1
sysctl -w fs.inotify.max_user_watches=524288

四、NFS 高可用演练（故障切换）

实时同步的终极用途：NFS 主备切换。两台机器保持目录一致（用上面的实时同步），主 NFS 挂了就切备机：

1
2
3
4
5
6
# 1. nfs 与 backup 两台服务配置保持一致（共享目录、权限、运行身份 www/666）
# 2. 平时用 rsync(ersync) 把主机的 /data 实时同步到备机
# 3. 模拟故障：主 NFS 宕机
# 4. web 节点强制卸载主 NFS，改挂备 NFS（业务侧一条命令切换）
umount -lf /data
mount -t nfs 10.0.8.41:/data /data

生产里这套再配个脚本或让业务侧感知主备地址（虚拟 IP 更好），切换时间从”小时级”降到”分钟级”。

小结

备份体系的完整形态：cron 定时 + rsync 传输 + md5 校验 + 邮件告警 + sersync 实时兜底。工具都是现成的，架构和脚本规范才是沉淀下来的资产——这套脚本模板之后每接一个新服务，改几个变量就能复用。

]]> https://www.lumindream.site/2023/07/20/%E5%AE%9A%E6%97%B6%E5%A4%87%E4%BB%BD%E4%B8%8E%E5%AE%9E%E6%97%B6%E5%90%8C%E6%AD%A5%E8%90%BD%E5%9C%B0cron%E5%8A%A0rsync%E5%8A%A0sersync/ 2023-07-20T02:00:00.000Z 把备份从"手工执行"变成"无人值守"：定时备份脚本、md5 校验与邮件告警、sersync 文件实时同步，以及一次 NFS 故障切换演练。 定时备份与实时同步落地：cron + rsync + sersync 2023-07-20T02:00:00.000Z LuminDream rsync 备份体系：从命令到企业备份架构

“数据没丢过”不代表备份做得对，”数据丢过且能恢复”才算。rsync 是 Linux 备份体系里最核心的工具——增量传输、断点续传、本地/远程全支持。这篇从命令用法讲到企业级备份架构。

一、核心概念与三种模式

rsync 有个特性是 scp 给不了的：增量同步——只传变化的部分，第二次执行默认就是增量，不重复传。

三种传输模式：

1
2
3
4
5
6
7
8
9
# 1. 本地拷贝（也做增量）
rsync -av /data/ /backup/

# 2. 守护进程模式（rsync://，走 873 端口，免 ssh 认证）
#   HOST:: 后面跟的是模块名（rsyncd.conf 里的 [backup]），不是目录路径！
rsync -av /data/ rsync://backup-server::backup

# 3. SSH 通道模式（走系统用户 + ssh 认证）
rsync -av -e ssh /data/ ops@10.0.8.41:/data/

-a 归档模式是主力，等价于 -rlptgoD：递归、软链接、权限、时间、属主属组、设备文件全部保留。

二、–delete：最重要也最危险的参数

1
2
# 语义：让目标目录和源目录完全一致——源没有的，目标必须删
rsync -av --delete /data/ /backup/

两个要点：

  1. 源、目标都要加斜杠，否则目标里会出现 源目录名/源目录名 嵌套；
  2. 方向要想清楚：--delete 是”以源为准”。企业里的经典用法是反向用——以备份服务器为准，把被黑/被改的目录恢复成备份状态：
1
2
# 服务器代码中毒被篡改：以备份机 /backup 为准，强制恢复业务机
rsync -av --delete rsync://backup-server::backup /server/www/

三、守护进程模式完整配置（服务端）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
# 1. 安装
yum install -y rsync

# 2. /etc/rsyncd.conf
cat > /etc/rsyncd.conf <<'EOF'
uid = rsync
gid = rsync
use chroot = no          # 不禁锢；软链可指模块外，需严格管理 path 权限
max connections = 10
read only = false        # 备份机要接收数据
list = false             # 不允许列出模块
auth users = rsync_backup
secrets file = /etc/rsync.passwd
[backup]
path = /backup
EOF

# 3. 创建虚拟用户（不能登录系统）
useradd rsync -s /sbin/nologin -M

# 4. 密码文件（服务端格式：用户名:密码，权限 600）
echo 'rsync_backup:Ops@2023' > /etc/rsync.passwd && chmod 600 /etc/rsync.passwd

# 5. 创建备份目录并授权
mkdir -p /backup && chown rsync:rsync /backup

# 6. 启动并验证 873 端口
systemctl start rsyncd && systemctl enable rsyncd
ss -tulnp | grep 873

四、客户端配置与免密

客户端只需装 rsync 工具，两种免密方式：

1
2
3
4
5
6
7
# 方式一：密码文件免密（客户端文件只写密码，不带用户名！）
echo 'Ops@2023' > /etc/rsync.pass && chmod 600 /etc/rsync.pass
rsync -av --password-file=/etc/rsync.pass /data/ rsync://backup-server::backup

# 方式二：环境变量
export RSYNC_PASSWORD='Ops@2023'
rsync -av /data/ rsync://backup-server::backup

五、多服务器备份架构：按客户端划分模块

多台业务机往一台备份机同步时，不要共用同一个模块——按客户端划分模块，实现身份物理隔离：

1
2
3
4
5
6
7
8
# 备份机 /etc/rsyncd.conf 里按客户端定义：
[web01]
path = /backup/web01
auth users = web01_bak

[web02]
path = /backup/web02
auth users = web02_bak

每个客户端只有自己模块的密码文件，A 机器即便密码泄露也碰不到 B 的备份目录。备份机的 /backup 目录按机器分目录，恢复时一目了然。

六、SSH 免密（配套）

需要走 SSH 通道时（如跨机房、需要系统用户权限），配置免密：

1
2
3
4
5
6
# 客户端生成密钥（一路回车）
ssh-keygen -t ed25519
# 分发公钥
ssh-copy-id -i ~/.ssh/id_ed25519.pub ops@10.0.8.41
# 验证
ssh ops@10.0.8.41 'hostname'

小结

备份体系的正确姿势是一套组合拳：rsync 负责传、密码文件负责认证、模块隔离负责安全、–delete 负责恢复。工具本身半小时能配完，真正值钱的是架构设计——下一篇把它升级成”定时 + 校验 + 告警 + 实时同步”的完整闭环。

]]> https://www.lumindream.site/2023/07/13/rsync%E5%A4%87%E4%BB%BD%E4%BD%93%E7%B3%BB%E4%BB%8E%E5%91%BD%E4%BB%A4%E5%88%B0%E4%BC%81%E4%B8%9A%E5%A4%87%E4%BB%BD%E6%9E%B6%E6%9E%84/ 2023-07-13T02:00:00.000Z 备份是运维的底线：rsync 三种传输模式与关键参数、守护进程模式完整配置、多服务器备份架构设计（身份隔离/免密），以及 --delete 的正确用法。 rsync 备份体系：从命令到企业备份架构 2023-07-13T02:00:00.000Z LuminDream NFS 共享存储实战：从挂载到生产读写分离

业务上线后没两天就会遇到一个问题：文件上传功能在多台服务器上各存各的，用户在 A 机传的图片，请求打到 B 机就 404 了。解法是让所有机器挂载同一份存储——NFS 是内网共享存储里最便宜、最常见的选择。这篇把 NFS 从原理到生产读写分离完整过一遍。

一、先理解 NFS 在干什么

NFS（Network File System）让你像用本地目录一样用远程目录。数据真正落在服务端，客户端只做挂载和读写。涉及两个角色：

  • 服务端：共享目录方，监听 2049 端口；NFSv3 还需要 rpcbind（端口映射服务）配合；
  • 客户端：挂载方，本地挂载点只是一个”门”，读写都打到服务端。

一句话记忆：服务端出目录、客户端进目录，数据永远在服务端那份。

二、服务端配置（6 步）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# 1. 安装（内网按网段放行 2049/rpcbind 即可，不建议直接全关防火墙）
yum install -y nfs-utils

# 2. 配置共享目录 /etc/exports
# 格式：共享路径  客户端地址(权限参数)
/data  172.18.1.0/24(rw,sync,no_root_squash)   # 注意客户端地址与参数间没有空格

# 3. 创建共享目录并授权
mkdir -p /data && chown -R nfsnobody:nfsnobody /data

# 4. 启动并加入开机自启（rpcbind 提供 NFSv3 端口映射，一起启）
systemctl start rpcbind && systemctl start nfs
systemctl enable rpcbind nfs

# 5. 验证：端口监听 + 实际生效的导出信息
ss -tulnp | grep 2049
cat /var/lib/nfs/etab        # etab 里有 /data 记录，说明 exports 配置正确
exportfs -rv                 # 修改 exports 后平滑加载，无需重启

三、客户端挂载（6 步）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
# 1. 安装客户端
yum install -y nfs-utils

# 2. 查看服务端共享了什么
showmount -e 172.18.1.31

# 3. 挂载
mkdir -p /nfsdir
mount -t nfs 172.18.1.31:/data /nfsdir

# 4. 验证
df -h | grep nfsdir
# 172.18.1.31:/data  62G  880M  58G  2%  /nfsdir

# 5. 写入测试：客户端写，服务端能看到同一份
echo "test" > /nfsdir/test.txt && ls -l /data/

# 6. 开机挂载（生产必须加 _netdev，避免网络未就绪时挂载失败卡开机）
echo '172.18.1.31:/data  /nfsdir  nfs  defaults,_netdev 0 0' >> /etc/fstab
mount -a    # 写完 fstab 必须用 mount -a 验证

卸载时提示 device is busy 是高频小坑：先 cd / 再 umount；实在不行 umount -lf 强制卸载。

四、权限与安全：生产必配的参数

NFS 的权限坑集中在身份映射上。服务端默认把客户端 root 映射成 nobody，但普通用户的 uid/gid 会原样透传——两边 uid 对不上就会出现”文件能看到但没权限写”。

统一身份的标准做法：all_squash + anonuid/anongid

1
2
3
4
5
6
7
8
9
# 服务端 exports：
/data  172.18.1.0/24(rw,sync,all_squash,anonuid=666,anongid=666)

# 服务端创建对应用户并授权
useradd -u 666 -g 666 www -s /sbin/nologin
chown -R 666.666 /data

# 客户端也建同 uid 用户（统一身份，避免权限不足）
useradd -u 666 -g 666 www -s /sbin/nologin

这样不管客户端是谁写的，落盘统一变成 uid=666，权限问题一次性根治。

安全挂载参数（静默数据不需要执行权限）：

1
2
3
mount -t nfs -o noexec,nodev,nosuid 172.18.1.31:/data /nfsdir
# noexec：禁止执行（防上传木马被直接运行）
# nodev / nosuid：禁设备文件与提权位

性能参数（可选）： noatime,nodiratime 禁止更新访问时间戳，减少 NFS 写放大，高 IO 场景明显。

五、生产案例：读写分离

需求：静态资源读多写少，且不同目录权限隔离——/data/r 只读、/data/w 可写，都映射到 www(666)。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# 服务端：
mkdir -p /data/{r,w}
echo 'www:x:666:666::/home/www:/sbin/nologin' >> /etc/passwd  # 或 useradd -u 666
cat >> /etc/exports <<'EOF'
/data/r  172.18.1.0/24(ro,sync,all_squash,anonuid=666,anongid=666)
/data/w  172.18.1.0/24(rw,sync,all_squash,anonuid=666,anongid=666)
EOF
exportfs -rv

# 客户端：
mount -t nfs 172.18.1.31:/data/r /data/r
mount -t nfs 172.18.1.31:/data/w /data/w
touch /data/r/xx && echo "Read-only file system"   # 只读目录写入报错（预期）
echo ok > /data/w/test                             # 可写目录正常

六、排障要点

  1. 挂载报 access denied：路径写错最常见——showmount -e 服务端 先看服务端实际导出的名字；
  2. 挂载卡住/超时：检查 rpcbind 是否启动、2049 与 rpc 端口（111）防火墙是否放行；
  3. 改完 exports 不生效：exportfs -rv 平滑加载，别重启 NFS 中断业务；
  4. 客户端看到文件但没权限：九成是 uid 不一致，按上面统一 anonuid 方案处理。

NFS 本身不复杂，把”数据在服务端、权限靠 anonuid、安全靠 noexec”这三条记住，生产基本够用。它解决的是”共享”，备份和灾备就是下一篇文章的事了。

]]> https://www.lumindream.site/2023/07/06/nfs%E5%85%B1%E4%BA%AB%E5%AD%98%E5%82%A8%E5%AE%9E%E6%88%98%E4%BB%8E%E6%8C%82%E8%BD%BD%E5%88%B0%E7%94%9F%E4%BA%A7%E8%AF%BB%E5%86%99%E5%88%86%E7%A6%BB/ 2023-07-06T02:00:00.000Z 多台服务器共享同一份数据怎么做：NFS 服务端/客户端完整配置、权限与安全挂载参数、读写分离生产案例，以及挂载排障记录。 NFS 共享存储实战：从挂载到生产读写分离 2023-07-06T02:00:00.000Z LuminDream Shell 三剑客与自动化脚本实践

运维的日常工作（看日志、查状态、做巡检）如果全靠手工敲命令，一天什么都干不了。把重复操作沉淀成脚本 + 定时任务，是运维从”救火”走向”自动化”的分水岭。这篇整理三剑客和 Shell 脚本的实战用法。

一、三剑客：grep / sed / awk

grep：过滤文本

1
2
3
4
grep -n "ERROR" app.log          # 带行号过滤
grep -v "^#" nginx.conf          # 排除注释行
egrep -n "ERROR|WARN" app.log    # 多关键词
grep -A5 "Exception" app.log     # 匹配后 5 行（看异常堆栈必备）

sed：按行过滤与批量修改

sed 是流编辑器，按行处理、无需打开文件，脚本化修改配置的核心工具。

1
2
3
4
sed -n '10,20p' nginx.conf       # 打印 10-20 行
sed -i 's/8080/8081/g' nginx.conf # 全局替换并写回（-i 原地修改）
sed -i '/^#/d' nginx.conf        # 删除注释行
sed -n '/^server/,/}/p' nginx.conf # 区间匹配

两个纪律：①-i 前先备份（cp xxx xxx.bak），改配置类文件尤其如此；②替换匹配尽量精确，避免误伤。

awk：取行取列与统计

1
2
3
4
awk '{print $1, $3}' access.log          # 取第 1、3 列
awk '$9 == 500 {print $1}' access.log    # 过滤 500 状态码的行
awk '{count[$1]++} END{for (k in count) print k, count[k]}' access.log | sort -k2 -rn | head
# 统计每个 IP 的请求次数，前 10 名（日志分析高频用法）

二、Shell 脚本规范

脚本骨架

1
2
3
4
5
#!/bin/bash
# 注释头：脚本用途、作者、修改记录（团队规范）
set -e          # 出错即停（排障友好）
# 变量：统一大写或用小写下划线
LOG_DIR="/data/logs"

变量与传参

1
2
3
4
5
6
7
8
# 特殊变量：$0 脚本名 $1-$9 位置参数 $# 参数个数 $? 上条命令退出码
# 判断：判断上一条命令是否成功就看 $?
ping -c1 www.baidu.com >/dev/null 2>&1 && echo "通" || echo "不通"

# 默认值（生产常用：环境变量没设就用默认）
PORT=${PORT:-3306}
# 强制必须设置：没传参数就报错退出
[ $# -lt 1 ] && echo "用法: $0 参数1" && exit 1

条件与循环

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
# 数值/字符串/文件判断
[ $FREE -lt 10 ] && echo "磁盘空间不足"      # 数值比较
[ -f /etc/nginx/nginx.conf ] && echo "存在"  # 文件判断
[ -z "$VAR" ] && echo "变量为空"

# 循环
for ip in 10.0.8.11 10.0.8.12; do ping -c1 -W1 $ip >/dev/null && echo "$ip 通" || echo "$ip 不通"; done
while read line; do echo "$line"; done < list.txt

# case 多路选择（服务操作脚本常用）
case "$1" in
  start) systemctl start nginx ;;
  stop)  systemctl stop nginx ;;
  *) echo "用法: $0 start|stop" ;;
esac

函数与局部变量

1
2
3
# 函数内的变量必须用 local，防止污染全局（这也是排查"变量莫名被改"的常见元凶）
log_info() { local msg="$1"; echo "[INFO] $(date '+%F %T') $msg"; }
check_disk() { local use=$(df -h / | awk 'NR==2{print $5}' | tr -d '%'); [ "$use" -gt 80 ] && echo "根分区使用率 ${use}%"; }

三、定时任务：crontab

五段式：分 时 日 月 周 命令。

1
2
3
4
5
6
7
8
9
10
crontab -e
# 每天凌晨 2 点备份
0 2 * * * /opt/scripts/backup.sh >> /var/log/backup.log 2>&1
# 每 10 分钟巡检一次
*/10 * * * * /opt/scripts/check.sh
# 每周日凌晨 3 点清理
0 3 * * 0 /opt/scripts/cleanup.sh

crontab -l     # 查看
crontab -r     # 删除（慎用）

定时任务三个高频坑：

  1. 脚本里的环境变量（PATH）是精简的：在 crontab 里直接写 rsync、python3 可能 command not found——脚本开头显式定义或用绝对路径；
  2. 输出重定向必须写：不写 >> log 2>&1，脚本报错内容会发到系统邮箱（没人看），排障全靠猜；
  3. 任务没执行先查三件事：crontab -l 任务在不在、脚本权限（chmod +x）、手动跑一遍有没有报错。

四、一个完整的巡检脚本案例

把”每天的磁盘/内存/负载巡检”沉淀成脚本，配 crontab 每天跑，结果统一写到日志：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
#!/bin/bash
# 日常巡检：磁盘、内存、负载
LOG="/var/log/ops/daily-check.log"
TS=$(date '+%F %T')

echo "===== $TS 巡检开始 =====" >> $LOG

# 磁盘使用率 TOP 检查
df -h | awk 'NR>1 && $5+0 > 80 {print "磁盘告警: " $0}' >> $LOG

# 内存
free -h | awk 'NR==2 {print "内存: 总量"$2" 已用"$3" 可用"$7}' >> $LOG

# 负载（超过核数阈值提醒）
LOAD=$(uptime | awk -F'load average:' '{print $2}' | cut -d, -f1)
echo "负载: $LOAD" >> $LOG
1
0 8 * * * /opt/scripts/daily-check.sh

脚本化的收益是复利式的：每次把重复操作写成脚本 + 定时任务，后面所有机器都能复用，也逼着自己把每一步操作想清楚——这正是排查和自动化能力一起提升的过程。

]]> https://www.lumindream.site/2023/06/28/shell%E4%B8%89%E5%89%91%E5%AE%A2%E4%B8%8E%E8%87%AA%E5%8A%A8%E5%8C%96%E8%84%9A%E6%9C%AC%E5%AE%9E%E8%B7%B5/ 2023-06-28T02:00:00.000Z 把日常巡检变成自动化脚本：grep/sed/awk 三剑客实战、Shell 脚本规范（变量/判断/循环/函数）、crontab 定时任务与排障，附日志分析脚本案例。 Shell 三剑客与自动化脚本实践 2023-06-28T02:00:00.000Z LuminDream 磁盘管理与 LVM 在线扩容实战

磁盘告警（/ 使用率 90%）是运维半夜被叫醒的高频原因。给磁盘规划做对了两件事——用 LVM、留扩容路径——大多数告警都能在业务无感的情况下解决。这篇是磁盘管理的完整实战。

一、分区表：MBR vs GPT

对比项MBRGPT
最大容量2TB大得多
主分区数最多 4 个128 个
工具fdiskparted / gdisk
场景小于 2T 的盘大于 2T 的盘必须 GPT

一条判断记住：小于 2T 用 fdisk（MBR），大于 2T 用 parted（GPT）。

二、RAID 选型：一句话对比

级别最少磁盘可用容量容错特点典型场景
RAID01100%无最快最脆，坏一块全丢缓存/临时数据，生产几乎不用
RAID1250%1 块完全镜像，安全但写慢系统盘、关键小数据
RAID53(n-1)/n1 块均衡，坏 1 块靠校验重建通用业务盘（非数据库）
RAID10450%每组 1 块先镜像再条带，快且安全数据库等高 IO 关键业务

生产选型就记一条：数据库上 RAID10，通用数据 RAID5，系统盘 RAID1——不追求理论极致，追求”故障时能扛住”。

三、LVM：为什么磁盘规划一定要用它

直接分区 + 格式化虽然简单，但空间不够时只能换更大盘、迁移数据，停机时间长。LVM 的核心价值一句话：不停止服务、不卸载目录，在线扩容。

LVM 三层概念：PV（物理卷，把盘擦干净打标记）→ VG（卷组，把 PV 收进一个池）→ LV（逻辑卷，从池里切出来用）。

初始化流程

1
2
3
4
5
6
7
8
9
# 1. PV：把新盘变成物理卷
pvcreate /dev/sdb
# 2. VG：建卷组（池）
vgcreate data_vg /dev/sdb
# 3. LV：从池里切 100G 给逻辑卷
lvcreate -L 100G -n data_lv data_vg
# 4. 格式化并挂载（写入 /etc/fstab 开机自动挂载）
mkfs.xfs /dev/data_vg/data_lv
mkdir /data && mount /dev/data_vg/data_lv /data

在线扩容（四层，一步都不能少）

场景：/data 只剩 10% 空间，新买了一块 200G 云盘 /dev/sdc，不停机扩到 300G。

1
2
3
4
5
6
7
8
9
10
11
# 1. 物理层面：新盘变成 PV
pvcreate /dev/sdc
# 2. 卷组层面：新 PV 并入 VG（池变大了）
vgextend data_vg /dev/sdc
# 3. 逻辑层面：池里空间全部给 LV
lvextend -l +100%FREE /dev/data_vg/data_lv
# 4. 文件系统层面：让文件系统"感知"变大（关键！）
# ext4：
resize2fs /dev/data_vg/data_lv
# xfs（CentOS 7+ 默认，注意 xfs 要传挂载点而不是设备名）：
xfs_growfs /data

完成后 df -h 立刻看到 300G，全程业务无中断。踩坑点：xfs 用 xfs_growfs /data（挂载点），ext4 用 resize2fs（设备名），混用会报错。

扩容后必做的巡检项

  • pvs / vgs / lvs 三连确认三层状态一致
  • 新盘没在 fstab 里重复挂载（避免重启后两个挂载点打架）
  • 告警阈值（如 80% 告警、90% 危险）在监控里同步更新

四、swap 扩容

内存吃紧时给系统加 swap 是最快的临时缓解：

1
2
3
4
5
6
7
8
9
10
11
12
free -h                                  # 先看现状

# 1. 生成 4G 空文件
dd if=/dev/zero of=/swapfile bs=1M count=4096 status=progress
# 2. 权限必须 600，否则 mkswap 报"不安全"
chmod 600 /swapfile
# 3. 格式化为 swap
mkswap /swapfile
# 4. 启用
swapon /swapfile
# 5. 写入 fstab 永久生效
echo '/swapfile swap swap defaults 0 0' >> /etc/fstab

注意：swap 是缓解不是根治，长期还是看应用内存优化或扩容内存。

五、一次深夜磁盘告警实录

凌晨 2 点收到 / 使用率 92% 告警。处理链路：

  1. df -h 确认告警真实性（92%，确实是根分区）；
  2. du -h --max-depth=1 -x / | sort -hr | head -10 定位大头目录（-x 不扫挂载点，防止 NFS 卡死）→ 是 /data/logs 应用日志；
  3. 查 logrotate 配置——新上线的服务没配轮转，大日志一直在涨；
  4. 手工 logrotate -f 触发一次轮转 + 临时清理，空间回到 60%；
  5. 补上该服务的 logrotate 规则，事件闭环。

磁盘管理的核心就三句话：初始化用 LVM、扩容走四层、日志交给 logrotate——做到这三点，磁盘类故障基本都能”白天处理、晚间无感”。

]]> https://www.lumindream.site/2023/06/21/%E7%A3%81%E7%9B%98%E7%AE%A1%E7%90%86%E4%B8%8ELVM%E5%9C%A8%E7%BA%BF%E6%89%A9%E5%AE%B9%E5%AE%9E%E6%88%98/ 2023-06-21T02:00:00.000Z 磁盘空间告急时不停机扩容的完整流程：分区表选择、RAID 选型对比、LVM 四层扩容操作（ext4/xfs 区别）、swap 扩容，以及一次深夜磁盘告警的处理实录。 磁盘管理与 LVM 在线扩容实战 2023-06-21T02:00:00.000Z LuminDream iptables 防火墙实战：四表五链与 NAT 转发

iptables 劝退很多人是因为命令又多又碎。但只要先把”四表五链 + 数据包流向”这个架构想明白，规则就是往架构里填句子。这篇从架构讲起，配合两个真实的 NAT 落地方案。

一、架构：四表五链 + 数据包流向

iptables 是操作内核 netfilter 的用户态工具，不是服务。规则存在内核内存，重启丢失，需手动保存。

四张表决定”干什么”：

表作用挂的链
filter过滤（默认表）：放行/丢弃INPUT, FORWARD, OUTPUT
nat地址转换：改 IP/端口PREROUTING, POSTROUTING, OUTPUT
mangle改包属性（TTL/TOS/MARK）全部链
raw绕过连接跟踪（高级优化）PREROUTING, OUTPUT

五条链决定”什么时候干”：

链触发时机
PREROUTING路由判断前（进门）
INPUT目的=本机，进入进程前
FORWARD本机转发（当路由器）
OUTPUT本机进程发出后
POSTROUTING路由判断后、出网卡前（出门）

数据包两条主干路径必须背下来：

1
2
访问本机：入网卡 → PREROUTING → 路由(本机) → INPUT → 进程 → OUTPUT → POSTROUTING → 出站
帮人转发：入网卡 → PREROUTING → 路由(转发) → FORWARD → POSTROUTING → 出站

二、常用规则写法

1
2
3
4
5
6
7
8
# 查看（-v 带计数，-n 不反解域名）
iptables -L -v -n
# 放行/拒绝
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -p tcp --dport 3306 -s 10.0.8.0/24 -j ACCEPT   # 只放行内网网段
iptables -A INPUT -p tcp --dport 80 -j DROP
# 删除规则：-D 或先 -L --line-numbers 看编号再删
iptables -D INPUT -p tcp --dport 80 -j DROP

高频概念：

  • DROP vs REJECT：DROP 静默丢包（防扫描更安全，但客户端表现是超时）；REJECT 明确拒绝（利于调试，报错快）。对外防火墙用 DROP。
  • 匹配顺序：链内自上而下，命中即停。具体放行规则放前面，默认策略兜底。
  • 看命中次数：iptables -L -v -n 的 pkts/bytes 列。排障时计数器不增长 = 包根本没走到这条规则，往上游找。
  • 持久化：iptables-save > /etc/sysconfig/iptables，开机 iptables-restore 恢复（或直接装 firewalld 管持久化）。

三、案例 1：SNAT 共享上网

场景：内网 20 台服务器走一台网关机器共享上网，网关双网卡（内网 + 公网）。

1
2
3
4
5
6
7
8
9
10
# 1. 开启内核转发
echo 1 > /proc/sys/net/ipv4/ip_forward
# 永久生效：/etc/sysctl.conf 里 net.ipv4.ip_forward=1 后 sysctl -p

# 2. 内网过来的流量出公网时把源地址换成网关公网 IP
iptables -t nat -A POSTROUTING -s 10.0.8.0/24 -o eth0 -j SNAT --to-source 100.64.8.1

# 3. 放行 FORWARD
iptables -A FORWARD -s 10.0.8.0/24 -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

四、案例 2：DNAT 端口映射

场景：公网访问 100.64.8.1:8080，映射到内网 Web 服务器 10.0.8.11:80。

1
2
3
4
5
6
7
8
9
# 进网关的流量，目标地址改写为内网服务器
iptables -t nat -A PREROUTING -d 100.64.8.1 -p tcp --dport 8080 -j DNAT --to-destination 10.0.8.11:80

# 源地址也换成网关（否则内网服务器回包找不到"公网客户端"路由）
iptables -t nat -A POSTROUTING -d 10.0.8.11 -p tcp --dport 80 -j SNAT --to-source 100.64.8.1

# 放行 FORWARD，验证
iptables -A FORWARD -p tcp --dport 80 -j ACCEPT
curl http://100.64.8.1:8080

五、排障要点

  1. 规则看起来对但不生效：先看 iptables -L -v -n 计数器，规则没命中就往上游（PREROUTING/路由）排查；本机访问走 INPUT，转发走 FORWARD，别弄错链。
  2. NAT 后业务不通：八成忘了回程 SNAT，或没开 ip_forward。
  3. 重启后规则全没了：没做 save/restore——这句几乎每次踩坑都会被想起。

iptables 上手后，内网隔离、端口映射、共享上网这些场景都能自己搞定，而”包往哪走”的架构感，也是后面学 nftables、云安全组时通用的底层认知。

]]> https://www.lumindream.site/2023/06/15/iptables%E9%98%B2%E7%81%AB%E5%A2%99%E5%AE%9E%E6%88%98%E5%9B%9B%E8%A1%A8%E4%BA%94%E9%93%BE%E4%B8%8ENAT%E8%BD%AC%E5%8F%91/ 2023-06-15T02:00:00.000Z 不背命令直接上手 iptables：四表五链架构与数据包流向、常用规则写法、SNAT 共享上网与 DNAT 端口映射两个生产案例，以及规则丢失的坑。 iptables 防火墙实战：四表五链与 NAT 转发 2023-06-15T02:00:00.000Z LuminDream 网络管理与 SSH 安全加固实战

网络是运维的”水电煤”——不通就什么都干不了，而 SSH 又是唯一的管理通道，它的安全等级直接决定服务器被不被攻破。这篇把网络基础配置和 SSH 加固基线完整过一遍。

一、网卡与 DNS 配置

CentOS 7 系网卡配置在 /etc/sysconfig/network-scripts/ifcfg-eth0：

1
2
3
4
5
6
7
8
9
TYPE=Ethernet
BOOTPROTO=none        # 服务器用固定 IP：none/static；笔记本才用 dhcp
NAME=eth0
DEVICE=eth0
ONBOOT=yes            # 开机自动启用
IPADDR=10.0.8.11      # 内网固定 IP（本机局域网内唯一）
PREFIX=24
GATEWAY=10.0.8.1
DNS1=223.5.5.5        # 阿里云公共 DNS

改完必须重启网络服务生效：systemctl restart network。

DNS 排查三连：

1
2
3
cat /etc/resolv.conf   # 本机 DNS 配置
cat /etc/hosts         # 本机 hosts 解析
nslookup / dig 域名     # 实际解析验证

生产教训：DNS 配错是”最隐蔽”的网络故障——服务看起来都正常，就是偶发连接超时。排查时先确认 resolv.conf 指向可达的 DNS，再看 hosts 有没有被污染（改 hosts 前先备份）。

常用公共 DNS 记住即可：223.5.5.5（阿里）、114.114.114.114（电信）、8.8.8.8（谷歌）、202.106.0.20（联通）。

二、SSH 加固：生产基线

装好 openssh-server 后，/etc/ssh/sshd_config 按这个基线配（每项都有明确目的）：

1
2
3
4
5
6
7
8
9
10
11
# 1. 禁止密码登录（生产必须密钥登录）
PasswordAuthentication no
# 2. 禁止 root 直接登录
PermitRootLogin no
# 3. 修改端口（默认 22，避开暴力破解的常规扫描）
Port 2222
# 4. 连接超时（避免无效连接占资源）
ClientAliveInterval 60
ClientAliveCountMax 3

systemctl restart sshd   # 重启前先检查语法：sshd -t

改端口前注意：sshd -t 验证配置、确认防火墙放行新端口、保持当前 SSH 会话别断开，三步都做好再重启，否则容易把自己锁在外面（我见过不止一次改配置改到连不上的现场）。

密钥登录配置流程：

1
2
3
4
5
# 1. 客户端生成密钥：ssh-keygen -t ed25519
# 2. 服务端存放公钥（目录 700、文件 600，企业规范）
mkdir -p /root/.ssh && chmod 700 /root/.ssh
echo "公钥内容" >> /root/.ssh/authorized_keys && chmod 600 /root/.ssh/authorized_keys
# 3. 确认密钥能登录后，再把 PasswordAuthentication 改为 no

三、一次暴力破解防护实录

事件：某台云服务器的 /var/log/secure 里出现大量 Failed password for root，来自境外 IP 的扫描在持续撞库。

应对三步：

  1. 立即 PermitRootLogin no + 改 SSH 端口，观察 secure 日志，撞库流量明显下降；
  2. 部署 fail2ban：同一 IP 连续失败 5 次封禁 10 分钟，日志里 Failed 快速归零；
  3. 长期措施：密钥登录全覆盖 + 堡垒机（JumpServer）统一入口，服务器不再直连公网。

四、网络排查命令速查

1
2
3
4
5
ip addr                 # 查看网卡 IP（ip a）
ss -tulnp               # 查看监听端口（替代过时的 netstat）
ss -s                   # 连接统计
ping / traceroute       # 连通性与路由路径
tcpdump -i eth0 port 80 # 抓包定位（网络问题的最终手段）

常用服务端口对照：SSH 22、HTTP 80、HTTPS 443、MySQL 3306、Redis 6379、DNS 53——排查”端口不通”时先分清是防火墙拦了还是服务没监听：ss -tulnp 确认监听，firewall-cmd --list-all（或 iptables）确认放行。

网络故障排查的核心纪律：先本机后远端、先端口后路由、先防火墙后抓包，一步步缩小范围，不要上来就抓包大海捞针。

]]> https://www.lumindream.site/2023/06/08/%E7%BD%91%E7%BB%9C%E7%AE%A1%E7%90%86%E4%B8%8ESSH%E5%AE%89%E5%85%A8%E5%8A%A0%E5%9B%BA%E5%AE%9E%E6%88%98/ 2023-06-08T02:00:00.000Z 从网卡配置到 SSH 加固的一整套网络管理实践：静态 IP 配置、DNS 解析链路、sshd_config 生产基线，以及一次暴力破解防护实录。 网络管理与 SSH 安全加固实战 2023-06-08T02:00:00.000Z LuminDream 文件系统深入：inode、软硬链接与高效查找

文件系统相关的故障往往最反直觉：df -h 明明有空间却写不进去、删了大文件空间却没变、文件名带特殊字符删不掉。这篇从 inode 机制讲起，把这类问题的原理和解决办法收在一起。

一、inode：文件系统里最被低估的概念

文件在磁盘上分两部分：inode（存放元数据：权限、属主、大小、指向数据块的指针）和数据块（真正的内容）。文件名只是 inode 的一个”门牌”。

1
2
3
ls -i 文件名        # 查看 inode 号
stat 文件名         # inode 的完整元数据
df -i               # 看 inode 使用率（IUse% 是否 100%）

经典故障：磁盘有空间但写不进去。df -h 还剩 20G，但建文件报 No space left on device——查 df -i，IUse% 100%，全是小文件把 inode 耗尽了。定位小文件最多的目录：

1
find /data -type f | cut -d/ -f3 | sort | uniq -c | sort -nr | head -10

清理或归档这些小文件（通常是日志、缓存、临时文件）即可恢复。inode 或磁盘空间任意一个满，磁盘都无法写入。

二、软链接 vs 硬链接

1
2
ln 源文件 硬链接      # 硬链接：共享同一个 inode
ln -s 源文件 软链接   # 软链接：独立 inode，指向路径
特性硬链接软链接
inode相同不同
删除源文件链接依然有效链接失效（红底白字）
跨文件系统不可以可以
目录不可以可以

生产中最常用的其实是软链接三件事：

  1. 保持路径不变，解决磁盘不够：数据迁到大盘，软链回原路径，应用无感知；
  2. 代码上线：current -> release-20230510，切换即回滚；
  3. 去软件版本号：/usr/local/mysql -> mysql-5.7.42。

三、find：高段位用法

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# 基本：名称/类型/深度
find ./ -name "*.log" -type f
find ./ -maxdepth 2 -type d

# 按大小：+10M 大于 / -10M 小于 / 组合区间
find ./ -size +10M
find ./ -size +10M -a -size -15M

# 按修改时间：-mtime +7 七天前改过 / -mmin -60 一小时内
find ./ -mtime +7
find ./ -mmin -30 -name "*.txt"

# 按 inode 找（删特殊文件名的文件）
find . -inum 123456 -delete

面试和生产都高频的经典题——删 7 天前的日志：

1
2
3
find /var/log -type f -mtime +7 -exec rm -f {} \;
# 更稳的写法：先 -exec ls -l 复查，确认无误再执行
find /var/log -type f -mtime +7 -exec ls -l {} \;

文件名带空格、特殊字符时用 -print0 + xargs -0 安全处理：

1
find . -name "*.log" -print0 | xargs -0 rm

四、权限规范：三个”绝不做”

  • 绝不做 chmod 777：任何场景都不给全权限，最小权限原则是底线（面试问到”为什么不用 777”就答这条）；
  • 绝不拿 -R 递归改系统目录：chmod -R / chown -R 只准作用于业务目录，误改 /etc、/bin 会直接搞崩系统；
  • 服务文件权限匹配运行用户：nginx 文件归 nginx:nginx、mysql 文件归 mysql:mysql，这是服务能正常读写的前提。

常规权限速查：644 配置文件、755 脚本/目录、600 敏感文件、750 业务私密目录。

1
2
chown -R nginx:nginx /usr/local/nginx/html   # 部署后必做：属主属组对齐
umask                                          # 默认权限由 022 派生：文件 644、目录 755

五、一次”空间不释放”排查实录

现象：删了几个 G 的大日志，df -h 空间一点没变。

排查：

  1. lsof | grep deleted → 找到被删除但仍被进程持有的文件，确认真凶是正在写日志的 java 进程；
  2. 直接重启进程会导致应用短暂中断（不可取）——生产做法：> /proc/<pid>/fd/<句柄号> 清空句柄指向的内容，空间立即释放，应用无感知；
  3. 事后把”日志按天切割 + logrotate 轮转 + 保留 7 天”写进规范，从根上避免大日志长期占用。

文件系统的坑大多是”原理没吃透 + 操作不规范”叠加出来的，把 inode、链接、权限这三块理解透，排障时基本能一眼定位。

]]> https://www.lumindream.site/2023/05/31/%E6%96%87%E4%BB%B6%E7%B3%BB%E7%BB%9F%E6%B7%B1%E5%85%A5inode%E8%BD%AF%E7%A1%AC%E9%93%BE%E6%8E%A5%E4%B8%8E%E9%AB%98%E6%95%88%E6%9F%A5%E6%89%BE/ 2023-05-31T02:00:00.000Z 文件删不掉、磁盘空间不释放、inode 耗尽——三个真实场景理解 Linux 文件系统：inode 机制、软硬链接区别、find 高阶用法与权限规范。 文件系统深入：inode、软硬链接与高效查找 2023-05-31T02:00:00.000Z LuminDream 用户权限与 sudo 提权规范实践

接手一套生产环境时，我最先看的就是账号体系：有多少人知道 root 密码、普通用户被授了什么权。账号体系乱的环境，安全事件只是时间问题。这篇整理一套可落地的用户与提权规范。

一、用户分类与 UID 规划

用户类型UID用途
root（管理员）0系统管理
普通用户1000+登录操作
虚拟用户1-999跑服务用（mysql、nginx 等），不可登录

生产铁律：任何对外服务绝不用 root 跑，每个服务建独立虚拟用户，权限最小化。

用户管理的几个关键文件：

  • /etc/passwd：用户信息（密码位永远是 x，真正的密码在 shadow）
  • /etc/shadow：加密后的密码
  • /etc/group：组信息
  • /etc/skel/：新用户家目录的模板
1
2
3
4
5
6
7
8
# 创建普通用户
useradd ops
# 创建虚拟用户：指定 UID/GID、不建家目录、禁止登录
groupadd -g 888 app
useradd -u 888 -g 888 -M -s /sbin/nologin app

# 删除用户（-r 连文件一起删）
userdel -r ops

二、su 与 su - 的区别（高频踩坑点）

1
2
su ops       # 借用身份，但 PATH/环境变量还是原来的（non-login shell）
su - ops     # 完全"变成"这个用户：环境、家目录、PATH 全换（login shell）

经典坑：用 su root（不带横杠）切过去后 echo $PATH 里没有 /usr/sbin、/sbin，执行某些命令直接 command not found。原因就是 non-login shell 只读 ~/.bashrc，不读 /etc/profile 系列。

命令切换后身份家目录/HOME环境要输谁的密码
su / su rootroot不变不加载 root 的root 密码
su - / su - rootroot/root加载 root 的root 密码
su - mysqlmysql/home/mysql加载 mysql 的mysql 密码

三、sudo：最小权限提权

sudo 的正解是”把最小必要权限授给该用的人”，而不是把 root 密码交出去。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
visudo   # 编辑 /etc/sudoers（自带语法检测，优先用它）

# 授权单个命令
ops  ALL=(ALL)  /usr/bin/cat

# 授权多个命令（给开发/测试）
ops  ALL=(ALL)  /usr/bin/cat,/usr/bin/cd

# 全权+取反（运维常用：除了 rm 都行）
ops  ALL=(ALL)  NOPASSWD: ALL,!/usr/bin/rm

# 使用与查看
sudo -l                              # 自己有哪些提权命令
sudo cat /var/log/secure             # 提权执行

sudo 配置的坑有两类：

  1. 给了 NOPASSWD: ALL 等于裸奔：提权后 rm、chmod 都能干。给 ALL 时一定要配合 ! 取反关键危险命令，或者干脆按命令列表授。
  2. 授权命令写相对路径：sudoers 里命令必须是绝对路径（which cat 先查绝对路径），否则规则永远不生效。

四、安全补充：登录审计

1
2
last      # 登录详细信息（来源 IP、时间、时长）
lastlog   # 每个用户最后一次登录时间

五、一次 root 直登整改记录

接手时发现多台服务器 sshd_config 里 PermitRootLogin yes，且 root 用弱密码——意味着任何能猜到密码的人都能直接拿到最高权限。

整改三步：

  1. 关 root 远程直登：PermitRootLogin no，重启 sshd；
  2. 给运维同事建 ops 账号，按职责授 sudo 最小权限（开发只有日志查看权，运维才有管理权）；
  3. 推行 sudo 日志留痕：visudo 里加上 Defaults logfile=/var/log/sudo.log。

结果：root 密码从”人人皆知”变成”仅紧急情况两人知晓”，日常操作全部走 sudo + 留痕，事后审计有据可查。

]]> https://www.lumindream.site/2023/05/24/%E7%94%A8%E6%88%B7%E6%9D%83%E9%99%90%E4%B8%8Esudo%E6%8F%90%E6%9D%83%E8%A7%84%E8%8C%83%E5%AE%9E%E8%B7%B5/ 2023-05-24T02:00:00.000Z 生产账号体系怎么建：用户分类与 UID 规划、passwd 文件解读、su 与 sudo 的正确用法、最小权限提权配置，以及 root 直登的整改记录。 用户权限与 sudo 提权规范实践 2023-05-24T02:00:00.000Z LuminDream 进程与性能排查实战：从 ps/top 到负载分析

“服务器变慢了”是运维收到最多的反馈，但它背后可能是 CPU、内存、磁盘 IO、网络任意一环的问题。这篇把排查思路和工具串成一条完整的链路，遇到问题按顺序走，很少会抓瞎。

一、排查思路：先定位资源，再定位进程

标准四问：

  1. 谁在吃 CPU？→ top / ps aux --sort=-%cpu
  2. 谁在吃内存？→ free -h / top / ps aux --sort=-%mem
  3. 谁在等 IO？→ top（看 D 状态）/ iostat
  4. 谁在占端口/文件？→ lsof / ss

二、ps：进程快照

1
2
3
4
5
ps aux                          # 完整信息（%CPU %MEM STAT）
ps -ef                          # 完整格式（含 PPID、启动时间）
ps aux --sort=-%cpu | head -20  # 按 CPU 排序
ps aux --sort=-%mem | head -20  # 按内存排序
ps -ef --forest | grep -A5 nginx  # 进程树，看父子关系

STAT 列是重点——它直接告诉你进程卡在哪：

状态含义排查提示
R运行/排队等 CPU结合 %CPU 看是否异常
S睡眠等事件正常
D不可中断的磁盘等待磁盘有问题（NFS 挂、磁盘故障），kill 不掉
Z僵尸进程父进程没 wait() 收尸，找父进程处理
T被暂停如 Ctrl+Z

三、top：动态监控

1
2
3
4
top
# 交互键：P 按CPU排序 M 按内存 T 按时间 1 展开每核 c 完整命令 H 看线程
top -u www-data        # 只看某用户的进程
top -Hp 1234           # 看线程级（排查 Java 线程吃 CPU 必备）

负载的判读：load average: 12.50, 8.30, 4.20 是 1/5/15 分钟平均负载。负载要和 CPU 核数对比：

1
2
nproc   # 查看核数
# 以 4 核为例：负载 <4 正常；=4 跑满；>4 有排队；>8 严重过载立即查

CPU 各列关注 wa（iowait）和 si（软中断）：wa > 20% 立刻查磁盘 IO（iostat）；si 高说明网络流量大，查网卡和连接数。

内存看 free -h，重点盯 si/so（swap 换入换出）：vmstat 1 如果 si/so 持续非零，说明内存吃紧在疯狂换页，要扩容或优化应用。

四、lsof：谁占用了什么

1
2
3
4
lsof -i :80          # 谁在监听 80 端口
lsof -p 1234         # 某进程打开了哪些文件
lsof | grep deleted  # 查"文件删了但空间没释放"的元凶
lsof +D /data        # 谁占用了某目录（umount 报 busy 时用）

经典场景：rm 了大日志但 df -h 空间没变——进程还持有文件句柄，文件没真正释放。解决：重启进程，或 > /proc/进程PID/fd/句柄号 清空。

五、一次 Java 线程高 CPU 排查实录

现象：业务反馈接口 P99 飙升，top 看到 java 进程 CPU 400%（占满 4 核）。

排查链路：

  1. top -Hp 1234 找到最耗 CPU 的线程 PID（比如 3039）；
  2. 转十六进制：printf "%x\n" 3039 → bdf；
  3. jstack 1234 | grep -A20 'nid=0xbdf' → 定位到具体业务线程和代码行；
  4. 发现是某个批量任务循环里不断创建连接未释放，上线前压测没覆盖到；修复后二次压测，CPU 回到 20% 以内。

六、工具补充记忆点

  • pidstat -u 2 5：每 2 秒采样 5 次看进程 CPU；-d 看 IO；-w 看上下文切换（自愿切换多=在等锁/IO，非自愿多=CPU 竞争激烈）
  • pmap -x <pid>：进程内存分布
  • /proc/cpuinfo、/proc/meminfo、/proc/loadavg、/proc/<pid>/cmdline：最底层数据来源，没有工具时直接读这里

排查性能问题没有银弹，但固定这套”先资源、后进程、再线程”的顺序，大部分问题都能在半小时内定位到根因。

]]> https://www.lumindream.site/2023/05/17/%E8%BF%9B%E7%A8%8B%E4%B8%8E%E6%80%A7%E8%83%BD%E6%8E%92%E6%9F%A5%E5%AE%9E%E6%88%98/ 2023-05-17T02:00:00.000Z 线上变慢怎么办：ps/top/free/lsof 一套组合拳定位 CPU、内存、IO 瓶颈，负载与进程状态的正确解读，以及 Java 线程高 CPU 的真实排查案例。 进程与性能排查实战：从 ps/top 到负载分析 2023-05-17T02:00:00.000Z LuminDream 软件包管理避坑指南：Yum / Apt 换源与生产实践

软件管理是所有 Linux 操作的入口，装错了源、乱跑了 update，轻则环境不可用，重则直接干崩生产。这篇把两系包管理的日常操作和生产避坑点整理成一份清单。

一、先建立两层结构的心智模型

不管哪个发行版，软件管理都是两层：

  • 高层工具（自动解决依赖）：RedHat 系 yum/dnf、Debian 系 apt/apt-get——生产中 99% 的场景用它们；
  • 底层工具（只管单个包）：rpm、dpkg——只在装本地安装包、排查依赖时用。

配置文件位置：RedHat 系在 /etc/yum.repos.d/（每个 .repo 一个源），Debian 系在 /etc/apt/sources.list 和 sources.list.d/。

二、RedHat 系日常操作

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# 安装
yum install -y nginx              # -y 自动确认（脚本里必须加）
yumdownloader --resolve nginx     # 只下载不安装（排查依赖问题用）

# 查询
yum info nginx                    # 包信息
rpm -qa                           # 已安装的所有包
rpm -ql nginx                     # 某个包装了哪些文件
rpm -qf /usr/sbin/nginx           # 反查：这个文件属于哪个包
rpm -qi nginx                     # 包的详细信息

# 升级（生产慎用！）
yum update --security -y          # 只更新安全补丁（生产推荐）
yum update -y                     # 全量更新——可能升级内核导致重启起不来

全量 yum update 是生产大忌。我吃过一次亏：凌晨跑了个全量升级，把内核从 3.10 升到了新版本，第二天重启服务器直接进不去系统，最后靠 grub 手动切回旧内核才救回来。从那以后生产只做 --security 安全更新，大版本升级一律走变更评审 + 灰度环境验证。

换源（阿里云，CentOS 7 为例）：

1
2
3
4
mkdir /etc/yum.repos.d/bak
mv /etc/yum.repos.d/CentOS-*.repo /etc/yum.repos.d/bak/
curl -o /etc/yum.repos.d/CentOS-Base.repo https://mirrors.aliyun.com/repo/Centos-7.repo
yum clean all && yum makecache

本地 rpm 安装（底层工具）：

1
2
3
4
rpm -ivh nginx-1.20.1-1.el7.x86_64.rpm   # 安装本地包（-i 安装 -v 详细 -h 进度条）
rpm -Uvh nginx-1.20.1-1.el7.x86_64.rpm   # 升级安装（没装过就装，装过就升）
rpm -e nginx                             # 卸载
rpm -e --nodeps nginx                    # 强删（极少用，除非确认后果）

三、Debian 系日常操作

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# 源：deb = 二进制包源（一般用不到 deb-src 源码源）
# 组件：main/restricted/universe/multiverse（开源程度不同）

apt update                              # 刷新索引（相当于 makecache）
apt install -y nginx
apt search nginx
apt show nginx                          # 包信息
apt depends nginx                       # 依赖关系

# 升级：只更新已装包（不增删依赖）
apt update && apt upgrade -y
# 完整升级：会处理依赖变更，可能删旧包
apt full-upgrade -y

apt remove nginx                        # 卸载保留配置
apt purge nginx                         # 彻底卸载（连 /etc 配置一起删）
apt autoremove -y                       # 清理孤立依赖（装完卸完跑一下）

本地 deb 安装与依赖修复：

1
2
3
4
dpkg -i nginx_1.18.0-0ubuntu1_amd64.deb
apt install -f -y                       # 报依赖错误时修复，自动补装缺失依赖
dpkg -l nginx                           # 状态标记：ii=已安装, rc=删了但配置残留
dpkg -S /usr/sbin/nginx                 # 反查文件属于哪个包

四、两个高频排障场景

  1. 装包报依赖错误：先 yum search/yum deplist（或 apt depends）看依赖闭包，缺什么补什么；本地包优先用高层工具的本地安装参数（yum localinstall），让依赖自动解决。
  2. rpm -qf 反查没结果：文件可能是手动编译安装的，不在任何 rpm 包内——这类文件升级时要特别注意，卸载重装会丢。

小结

包管理的核心纪律就三条：换源用国内镜像、生产只做安全更新、卸载前看清依赖提示。把这三点写进初始化检查清单（见《Linux 发行版选型与系统初始化实践》），基本能避开 90% 的软件管理事故。

]]> https://www.lumindream.site/2023/05/10/%E8%BD%AF%E4%BB%B6%E5%8C%85%E7%AE%A1%E7%90%86%E9%81%BF%E5%9D%91%E6%8C%87%E5%8D%97yum%E4%B8%8Eapt%E6%8D%A2%E6%BA%90%E5%AE%9E%E8%B7%B5/ 2023-05-10T02:00:00.000Z 线上线下两套环境的软件包管理经验：yum/apt 换源、装包卸载避坑、本地 rpm/deb 安装、依赖排查，以及 update 全量升级的教训。 软件包管理避坑指南：Yum / Apt 换源与生产实践 2023-05-10T02:00:00.000Z LuminDream 日志排查体系：journalctl 与生产日志轮转

线上出故障时，第一步永远是翻日志。但日志查得好不好，直接决定定位问题的速度。这篇整理 systemd 生态下 journald / journalctl 的完整用法，以及生产环境怎么把日志管住、不爆盘。

一、journalctl：集中式日志查询

systemd 自带 systemd-journald 守护进程，把内核消息、系统服务、自定义服务的输出全部收集进一个二进制数据库（/run/log/journal/ 或持久化后的 /var/log/journal/）。journalctl 就是查询它的工具。

一句话说清它的定位：”journalctl 是 systemd 生态的日志查询命令，集中管理所有 systemd 单元和内核日志，支持结构化过滤和持久化存储。”

常用查询

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
# 看某个服务的日志（生产最常用）
journalctl -u nginx.service
journalctl -u nginx -f              # 实时跟踪（类似 tail -f）

# 按时间过滤
journalctl --since "2023-04-01 10:00:00" --until "2023-04-01 11:00:00"
journalctl -u 服务名 --since "1 hour ago"

# 本次启动以来的日志（重启后查故障原因必备）
journalctl -b                       # 当前启动
journalctl -b -1                    # 上一次启动
journalctl --list-boots             # 列出所有启动记录

# 按优先级过滤
journalctl -p err                   # 只看错误及以上
# 级别：emerg, alert, crit, err, warning, notice, info, debug

# 内核日志 / 指定进程
journalctl -k
journalctl _PID=1234

踩过的坑：journald 没持久化

有段时间重启服务器后 journalctl -b -1 查不到上次的日志，一度以为是命令写错了。查了一圈才发现：CentOS 7 最小化安装时，journald 的日志默认存在内存里（/run/log/journal），一重启全清空。

解法是建持久化目录：

1
2
3
4
5
6
7
8
9
mkdir -p /var/log/journal
systemd-tmpfiles --create --prefix /var/log/journal
systemctl restart systemd-journald

# 同时限制日志大小防爆盘（编辑 /etc/systemd/journald.conf）
# SystemMaxUse=2G       日志最多占 2G，超了自动删最老的
# SystemKeepFree=500M   至少给系统留 500M 空闲
# MaxRetentionSec=1month 最多保留 1 个月
systemctl restart systemd-journald

二、logrotate：防爆盘的根本

journald 只管自己的库，业务日志（nginx、应用自己打的日志）得靠 logrotate 管。配置在 /etc/logrotate.conf（全局）+ /etc/logrotate.d/（每个服务一个文件）。

以 nginx 为例的标准配置：

1
2
3
4
5
6
7
8
9
10
11
12
/var/log/nginx/*.log {
    daily              # 每天切一次
    rotate 7           # 保留 7 份旧的
    compress           # 旧日志压缩成 .gz
    delaycompress      # 昨天的先不压，方便临时查
    missingok          # 文件不存在不报错
    notifempty         # 空文件不轮转
    sharedscripts
    postrotate
        [ -f /var/run/nginx.pid ] && kill -USR1 `cat /var/run/nginx.pid`  # 通知 nginx 重开日志文件
    endscript
}

两个验证命令先背下来：

1
2
logrotate -d /etc/logrotate.d/nginx   # 调试模式，只演练不真执行，查语法
logrotate -f /etc/logrotate.d/nginx   # 强制立刻轮转一次，验证生效

三、配套排查：系统日志文件

除了 journald，传统系统日志文件依然是安全排查的一线阵地：

  • /var/log/messages：系统日志
  • /var/log/secure：系统登录和退出日志——如果 secure 里出现大量 Failed，说明有人在暴力破解密码，要立刻加固 SSH

四、一次”查不到日志”的完整复盘

现象：应用半夜崩溃，早上重启后想查崩溃时刻的日志，journalctl -b -1 只返回了启动信息，没有应用输出。

排查链路：

  1. journalctl --list-boots 确认存在上一次启动记录 → 排除命令用错；
  2. 检查 /run/log/journal vs /var/log/journal → 发现只有内存目录，持久化没做；
  3. 补建目录并重启 journald，观察 /var/log/journal 开始落盘；
  4. 后续同类问题都能查到 -b -1 的完整日志。

总结：日志体系的搭建要在上线前完成，而不是故障后才想起来——持久化、轮转、保留策略这三件事，每台新机器初始化时就要一起落下。

]]> https://www.lumindream.site/2023/04/26/%E6%97%A5%E5%BF%97%E6%8E%92%E6%9F%A5%E4%BD%93%E7%B3%BBjournalctl%E4%B8%8E%E7%94%9F%E4%BA%A7%E6%97%A5%E5%BF%97%E8%BD%AE%E8%BD%AC/ 2023-04-26T02:00:00.000Z 日志是排障的第一现场：journalctl 结构化查询技巧、journald 持久化配置、logrotate 防爆盘方案，以及一次"查不到上次日志"的排查记录。 日志排查体系：journalctl 与生产日志轮转 2023-04-26T02:00:00.000Z LuminDream Systemd 服务管理实战：从 Unit 编写到日常运维

把一套应用从”手动 nohup 启动”改成 systemd 托管，是运维规范化里回报最高的一件事——开机自启、崩溃拉起、日志集中、权限隔离一次全解决。这篇把从零手写 .service 到日常运维的完整过程捋一遍。

一、先理解三个角色

  • .service 文件 = 一份”岗位说明书”：写明怎么启动、怎么停止、什么情况下重启；
  • systemctl = 操作指令：对服务执行 start / stop / enable / status；
  • systemd = 管理进程：负责读懂说明书、监控所有服务。

现代主流 Linux 全部用 systemd，老掉牙的 SysV init 那套（/etc/inittab、rc.local 塞脚本）只在新装系统时偶尔遇见，不建议再往里写东西。

二、.service 文件的三段式

每个 Unit 文件由 [Unit]、[Service]、[Install] 三部分构成，缺一不可。放在 /etc/systemd/system/（管理员自定义，优先级最高）或 /usr/lib/systemd/system/（软件包自带）。

[Unit]：声明依赖

1
2
3
4
5
[Unit]
Description=支付网关服务
Documentation=https://wiki.internal/payment
After=network.target mysql.service      # 启动顺序：网络和 MySQL 之后
Wants=mysql.service                     # 弱依赖：mysql 挂了不影响本服务

生产里最常见的坑：Java 应用在 MySQL 还没就绪时就启动了，连接池初始化报错。所以 After 一定要把依赖关系写清楚。

[Service]：定义怎么干活

1
2
3
4
5
6
7
8
9
10
[Service]
Type=simple             # 默认值：ExecStart 启动的进程就是主进程
ExecStart=/usr/bin/java -jar /app/payment/app.jar
Restart=on-failure      # 异常退出才重启（MySQL 等数据库推荐）
RestartSec=10           # 重启间隔，防止故障时疯狂重启
TimeoutSec=60           # 启动/停止超时
User=appuser            # 绝不用 root 跑对外服务
Group=appgroup
LimitNOFILE=65535       # 文件句柄上限，高并发服务必须调
PrivateTmp=true         # 独立临时目录，防 /tmp 提权

Type 的选择直接决定 systemd 能不能正确跟踪进程：

Type适用场景
simple前台运行的程序（Node.js、Python Web 服务）
forking会分叉后台的传统服务（Nginx、MySQL）
oneshot执行一次就退出的脚本，配合 RemainAfterExit=yes
notify支持 sd_notify 的现代程序，就绪后主动通知

[Install]：挂靠开机流程

1
2
[Install]
WantedBy=multi-user.target

systemctl enable 的实质，就是在 /etc/systemd/system/multi-user.target.wants/ 下创建指向本文件的符号链接，开机进入多用户模式时自动拉起。

三、两个真实案例

案例 1：手工安装的 MySQL 5.7（Type=forking）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
[Unit]
Description=MySQL 5.7 Database Server
After=network.target

[Service]
Type=forking
User=mysql
Group=mysql
PIDFile=/data/mysql/data/mysqld.pid
ExecStart=/usr/local/mysql/bin/mysqld_safe --defaults-file=/etc/my.cnf
ExecStop=/usr/local/mysql/bin/mysqladmin -u root shutdown
Restart=on-failure
RestartSec=10
LimitNOFILE=65535
PrivateTmp=true

[Install]
WantedBy=multi-user.target

mysqld_safe 会分叉出真正的 mysqld 进程，所以必须 Type=forking 并指定 PIDFile，否则 systemd 会误判服务已退出。

案例 2：Java 微服务（Type=simple）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
[Unit]
Description=Order Service
After=network.target mysql.service redis.service
Wants=mysql.service redis.service

[Service]
Type=simple
User=appuser
Group=appgroup
WorkingDirectory=/app/order
ExecStart=/opt/jdk11/bin/java -jar /app/order/order-service.jar --spring.profiles.active=prod
Restart=always
RestartSec=15
EnvironmentFile=/etc/sysconfig/order-service
StandardOutput=journal
StandardError=journal
LimitNOFILE=65536

[Install]
WantedBy=multi-user.target

敏感配置（数据库密码）绝不写在 Unit 的 Environment 里明文，而是用 EnvironmentFile 指向权限 600 的配置文件，或交给密钥管理系统注入。

四、日常运维命令

1
2
3
4
5
6
7
8
systemctl start/stop/restart/status 服务名
systemctl daemon-reload              # 修改 Unit 后必须重载
systemctl enable --now 服务名         # 开机自启 + 立即启动
systemctl cat 服务名                  # 查看服务实际生效的配置
systemctl list-units --type=service --state=failed   # 列出所有启动失败的服务（排查必用）
systemctl is-enabled 服务名           # 是否开机自启
systemd-analyze verify xxx.service   # 校验 Unit 语法
systemd-analyze security xxx.service # 服务安全加固评分

五、两个排障经验

  1. 改了单位文件不生效：九成是忘了 systemctl daemon-reload，新文件 systemd 根本不认识。
  2. Restart=always 的服务疯狂重启：启动即崩的程序会不停刷日志，光看 status 一时半会看不出来，要注意结合 RestartSec 和 StartLimitIntervalSec/StartLimitBurst 限制重启次数，同时去 journal 里看崩溃原因——这就是下一篇日志排查的内容。
]]> https://www.lumindream.site/2023/04/19/systemd%E6%9C%8D%E5%8A%A1%E7%AE%A1%E7%90%86%E5%AE%9E%E6%88%98/ 2023-04-19T02:00:00.000Z 手写 .service 文件落地服务的完整过程：Unit/Service/Install 三段式参数详解、Java 应用与 MySQL 的两种真实案例、systemd 常用运维命令与排障思路。 Systemd 服务管理实战：从 Unit 编写到日常运维 2023-04-19T02:00:00.000Z LuminDream Linux 发行版选型与系统初始化实践

新项目立项时，第一个要拍板的技术决策往往不是中间件，而是服务器操作系统选什么。这个选择会影响后面两三年里所有服务的部署方式、排障手段和团队的知识积累。分享一下我这边沉淀下来的选型逻辑和初始化流程。

一、发行版选型：先看业务形态

Linux 发行版分两大主流派系，国内生产环境基本只在这两系里选：

派系代表发行版包管理典型场景
RedHat 系RHEL、CentOS、Rocky Linux、AlmaLinuxrpm + yum/dnf金融、运营商、政企等传统企业，占比最高
Debian 系Debian、Ubuntu Serverdeb + apt互联网公司、云原生/K8s 生态

选型上我的判断标准有两条：

  1. 团队熟悉度优先。维护成本里最贵的不是软件授权，是团队踩坑经验的积累。上一套系统工程师熟的发行版，比”据说更好”的陌生发行版值钱得多。
  2. 看未来的支持周期。CentOS 8 提前停服、CentOS 7 也在 2024 年走到尽头后，新项目我会优先 Rocky Linux / AlmaLinux（RHEL 的二进制兼容替代），存量机器逐步规划迁移；云上新建的容器化集群则倾向 Ubuntu Server，K8s 生态对 Debian 系的适配更积极。

实际对比中容易踩的差异点记一下：

对比项RedHat 系Debian 系
装软件yum install nginxapt install nginx
服务管理systemctlsystemctl
网络配置/etc/sysconfig/network-scripts//etc/netplan/
防火墙firewalldufw
SELinux默认开启（坑多，要主动处理）默认 AppArmor

国产化环境（政企信创）还会遇到 openEuler、银河麒麟、统信 UOS、龙蜥等，基本都是基于上述两系衍生，包管理习惯可以平移，主要是要提前确认依赖软件的兼容性。

二、装完系统先做这几件事

新机器到手，我按“四件套”顺序初始化：主机名 → 时间 → 源 → 加固。

1. 主机名规范

主机名不是随便起的，要让人一眼看懂这台机器是干什么的。我这边用的规范是 业务-环境-编号：

1
2
3
4
5
6
7
# 示例：商品服务生产第 3 台 / MySQL 测试库第 1 台
goods-prod-03
mysql-test-01

# 查看/修改主机名
hostname                        # 查看当前主机名
hostnamectl set-hostname mysql-test-01   # 永久修改（写入 /etc/hostname）

2. 时间同步

时间不同步是生产事故的高发元凶——日志对不上、证书校验失败、分布式事务错乱都跟它有关。初始化时直接用 chrony 指向国内 NTP 源：

1
2
3
4
5
timedatectl set-timezone Asia/Shanghai   # 时区必须设对
hwclock -w                               # 系统时间同步给硬件时间

# 确认时间同步状态
timedatectl

顺手养成记录时间戳的习惯，备份文件的命名里带时间，恢复时才知道用哪份：

1
2
TS=$(date +%Y%m%d_%H%M%S)
cp /etc/nginx/nginx.conf /backup/nginx.conf_${TS}

3. 更换软件源

海外官方源在国内拉包又慢又容易超时，装机后第一件事就是把源切到国内镜像。以阿里云为例，RedHat 系：

1
2
3
4
mkdir /etc/yum.repos.d/bak
mv /etc/yum.repos.d/CentOS-*.repo /etc/yum.repos.d/bak/
curl -o /etc/yum.repos.d/CentOS-Base.repo https://mirrors.aliyun.com/repo/Centos-7.repo
yum clean all && yum makecache

Debian 系（Ubuntu 22.04 举例）：

1
2
3
4
cp /etc/apt/sources.list /etc/apt/sources.list.bak
sed -i 's|http://archive.ubuntu.com|http://mirrors.aliyun.com|g' /etc/apt/sources.list
sed -i 's|http://security.ubuntu.com|http://mirrors.aliyun.com|g' /etc/apt/sources.list
apt update

4. 内核/版本确认

接手存量机器时第一件事永远是确认系统版本，判断后续命令兼容性：

1
2
3
uname -r                 # 当前运行内核（看 el7/el8 后缀判断系）
cat /etc/redhat-release  # 发行版版本
rpm -qa | grep kernel    # 装了几个内核（升级后清理旧内核用）

三、初始化检查清单（贴机房/贴云主机都适用）

这套清单我每次装机都会过一遍，既是操作记录也是交接文档：

  • 主机名符合 业务-环境-编号 规范
  • 时区 Asia/Shanghai、时间同步正常（timedatectl 确认）
  • 软件源已切换国内镜像、makecache 通过
  • SSH 已加固（密钥登录、禁 root 直登、改端口）——详见网络加固那篇
  • 防火墙按业务最小放行
  • 常规目录已按规范预建（/data、/backup 等）

小结

发行版选型没有绝对最优，只有“团队能长期维护”和“生命周期内不踩停服坑”这两个硬条件；初始化流程固定成清单后，新机器从到手到可交付基本控制在半小时内，也为后面所有的故障排查打好了基线。

]]> https://www.lumindream.site/2023/04/12/linux%E5%8F%91%E8%A1%8C%E7%89%88%E9%80%89%E5%9E%8B%E4%B8%8E%E7%B3%BB%E7%BB%9F%E5%88%9D%E5%A7%8B%E5%8C%96%E5%AE%9E%E8%B7%B5/ 2023-04-12T02:00:00.000Z 从发行版选型到装机初始化的一整套落地实践：RedHat/Debian 两系怎么选、内核版本怎么查、主机名/时间/换源怎么做，附生产检查清单。 Linux 发行版选型与系统初始化实践 2023-04-12T02:00:00.000Z