学习Linux路线5个阶段

线上服务器load突然飙到50，CPU使用率只有10%，你第一反应查什么？

他想了半天，说："重启试试？"

这就是问题所在。会敲命令和会干活，中间隔着一整个体系。背过ls、cd、chmod只是起点，真正的运维能力是：业务挂了知道从哪查、流量来了知道怎么扛、机器到几百台知道怎么管。

这篇文章把我带团队这些年验证过的学习路线整理出来，一共5个阶段。每个阶段我都写了验收标准——做到了再往下走，别让"收藏等于学会"的悲剧发生在自己身上。

01入门期

验收标准：不查笔记完成日常文件操作，遇到问题会自己翻man手册。

环境怎么搭

别只装一台虚拟机。直接装三台，取名node1、node2、node3，配好NAT网络互通。后面所有阶段都要用到这个最小集群。

发行版的选择，我的建议是Rocky Linux 9。原因很简单：企业服务器的主流是RHEL系，你学Ubuntu学得再熟，到公司一看全是CentOS系，照样抓瞎。面试问的也是RHEL系。

文件系统：先记这7个目录

第一周每天敲的命令

ls -lhat                 # 按时间排，人类可读

cp -a src/ dst/          # 保留权限的复制，运维必备

mv file.txt{,.bak}       # 一键备份成 file.txt.bak

less +F /var/log/messages   # 实时看日志，Ctrl+C退出

tail -100 app.log | grep ERROR  man ls                   # 完整手册，按 / 搜索

tldr tar                 # 社区示例版，比man好懂

说一句掏心窝的话：rm -rf 是生产事故第一高发命令。我见过工作五年的老运维手滑删了数据目录。养成习惯——删之前先 ls 看一眼，或者用 mv 挪到回收目录代替直接删。

入门期实战：

• 三台虚拟机装好，node1能免密SSH登录另外两台
• 找个配置文件练手：备份 → 修改 → 验证 → 回滚，走一遍完整流程
• 不看笔记，用man查出find按时间过滤的3种写法

02进阶期

验收标准：能用一条管道命令完成日志分析，不再用chmod 777解决问题。

权限：别只会777

区分初级和中级最简单的方法：看他遇到权限报错是不是直接chmod 777。这就像家里门坏了就把墙拆了——能进，但谁都能进。

# 权限的本质：u/g/o 三类人，r=4 w=2 x=1

chmod 750 script.sh    # 自己全权，组内可读可执行，外人无权# 精细控制：单独给张三读写权

setfacl -m u:zhangsan:rw /data/report.txt getfacl /data/report.txt# 

sudo：别让任何人知道root密码# visudo 里加一行，只放开需要的命令

zhangsan ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart nginx

文本处理：运维的瑞士军刀

这三条命令组合，我劝你背下来，工作头三年至少能用几百次：

# 统计访问最多的IP TOP10（背下来）

awk '{print $1}' access.log | sort | uniq -c | sort -rn | head

# 统计404出现次数

awk '$9 == 404 {c++} END {print c}' access.log

# 提取今天上午10点到11点的日志sed -n '/10:00/,/11:00/p' app.log

进程：两件事必须会

ps aux --sort=-%cpu | head -5   # 谁在吃CPU

kill -15 PID                    # 先礼貌地请它退出# 实在不行才 kill -9，进程来不及收拾残局，慎用

nohup ./app.sh > app.log 2>&1 &  # 后台常驻，关了SSH也不死

进阶期实战：

• 拿到一份Nginx日志，用awk统计UV、状态码分布、TOP10访问路径
• 从源码编译一次Nginx，把缺依赖的坑都踩一遍
• 写个守护脚本：进程挂了自动拉起，记日志

03管理期（2-3个月）：独立管服务器

验收标准：一台裸机到你手里，半天内能配置成可上线的Web服务器。

systemd：现代Linux的总管

systemctl enable --now nginx   # 启动+开机自启一条搞定

journalctl -u nginx -p err     # 只看nginx的错误日志

初级运维用现成的service，中级以上要会自己写。比如自研应用要托管给systemd：

# /etc/systemd/system/myapp.service

[Service]

 User=myapp 

ExecStart=/opt/myapp/bin/start.sh Restart=on-failure        

# 崩了自动拉起

RestartSec=5 LimitNOFILE=65535         

# 高并发必调，不然早晚 Too many open files

网络排障：四步走，别乱猜

服务不通的时候，90%的人是瞎试。正确的顺序是分层定位：

ping -c 4 目标IP        # 第一步：网络通不通

dig example.com         # 第二步：DNS解析对不对

curl -v 目标地址         # 第三步：应用层有没有响应

traceroute 目标IP       # 第四步：断在哪一跳

ss -tulnp               # 端口冲突排查首选：谁占了80端口

tcpdump -i eth0 -nn port 80 -c 100   # 终极武器：抓包

磁盘：生产最高频的问题

df -h                              # 哪个分区满了

du -sh /var/log/* | sort -rh | head  # 哪个目录占的

lsof +L1                           # 关键：df和du对不上时用它

第三条解释一下：文件删了空间没释放，是因为还有进程占用着这个文件。日志轮转没配好经常踩这个坑，lsof +L1一查一个准。

管理期实战：

• 给自研脚本写systemd unit：开机自启+崩溃自动拉起
• 让同事给你制造一个网络故障，用四步法定位出来
• 亲手制造一次"删了文件空间没释放"，再用lsof解决
• 写带锁、带日志、带失败告警的备份脚本，crontab每天跑

04高级期（3-6个月）：架构与性能

验收标准：能搭高可用集群，能独立定位性能瓶颈。

高可用：先理解VIP漂移

单机必挂，这是物理规律。入门级的无单点方案是 Keepalived + Nginx 双机：

• 两台机器绑同一个虚拟IP（VIP），对外只暴露VIP
• 主节点活着，VIP在主机上；主挂了，VIP秒级漂移到备机
• 用户无感知，业务不中断

主节点核心配置就这几行：

vrrp_instance VI_1 {     

state MASTER     

interface eth0     

virtual_router_id 51    

priority 100            # 备机写90

virtual_ipaddress {         

10.0.0.100/24      # 对外的VIP

      }   

}

性能排查：先量化，再定位，最后调

性能问题最大的坑是上来就改内核参数。正确做法是先用60秒跑一轮检查（这套方法来自Netflix的性能专家Brendan Gregg）：

uptime           # load超过核数 = 有任务在排队

dmesg | tail     # 有没有OOM、硬件报错

vmstat 1 5       # r列高=CPU排队；si/so>0=内存换页

mpstat -P ALL 1  # 单核打满还是整体都高

pidstat 1        # 哪个进程在搞事

iostat -xz 1     # %util接近100% = 磁盘瓶颈

free -h          # 看available，别只看free

sar -n DEV 1     # 网卡流量打没打满

回到开头的面试题：load高但CPU低，大概率是磁盘IO把进程堵住了。用iostat -xz 1看await，再用pidstat -d找是谁在疯狂读写。这不是背出来的，是这套流程跑出来的。

确认瓶颈之后才谈调优。高并发场景常改这几个（写进/etc/sysctl.conf）：

net.core.somaxconn = 65535      # 连接队列加长

net.ipv4.tcp_tw_reuse = 1       # TIME_WAIT复用

fs.file-max = 1048576           # 文件句柄上限

vm.swappiness = 10              # 少用swap，数据库机器设1

监控：Prometheus全家桶

机器超过5台，人肉巡检就不现实了。标配组合：

监控盯什么？Google SRE的四大黄金指标：延迟、流量、错误、饱和度。这四样盯住了，80%的问题能在用户发现之前先报警。

高级期实战：

• node1+node2搭Keepalived双机，拔主机网线，验证VIP漂移和业务不断
• 用wrk把Nginx压到极限，观察TIME_WAIT堆积，调参后再压，对比数据
• Prometheus+Grafana部署起来，CPU超80%推告警到钉钉或企微
• 用stress故意吃光内存制造OOM，再从日志里还原全过程

05资深期（6-12个月）：平台与体系

验收标准：能设计并落地容器平台和自动化运维体系。

Kubernetes：抓住主线别迷路

K8s概念多到劝退，但主线就一条：Pod是原子，Deployment管副本，Service管访问，Ingress管入口。

日常用得最多的是排障三板斧，覆盖80%的问题：

kubectl get pods -n myapp              # 看状态

kubectl describe pod xxx -n myapp      # 看Events，调度失败都在这

kubectl logs xxx -n myapp --previous   # 看崩溃前的日志

常见状态对照，遇到直接查：

Ansible：机器多了之后的标准答案

管3台机器可以手工，管300台必须自动化。Ansible的核心思想是幂等：同一个剧本跑一遍和跑十遍，结果一样。

- hosts: webservers   

become: yes   

tasks:    

     - name: 安装Nginx  

     dnf:    

        name: nginx 

        state: present      # 已装就跳过，这就是幂等

      - name: 推送配置 

      template:        

       src: nginx.conf.j2 

       dest: /etc/nginx/nginx.conf

       notify: 重启nginx     # 配置没变就不重启

故障处理：章法比技术重要

线上出事的时候，技术反而退居其次，章法决定损失大小。四步走：

1. 先止血
   。回滚、切流量、重启，哪个快用哪个。别上来就查根因——业务每多挂一分钟，损失都在扩大。
2. 再保现场
   。动手恢复之前，把日志、进程列表、网络连接快照存下来。最怕重启一把梭，现场冲没了，复盘变成猜谜。
3. 然后定位
   。按层查：应用日志→系统指标→网络→硬件，用监控数据缩小范围，别凭感觉。
4. 最后复盘
   。写清楚时间线、根因、改进项、负责人、Deadline。复盘只问"系统为什么让人有机会犯错"，不问"谁的锅"。

资深期实战：

• k3s搭个K8s集群，部署多副本应用，配Ingress和HPA自动扩缩
• 写一套Ansible剧本：新服务器一键初始化（用户/加固/监控agent）
• GitLab CI搭流水线：提交代码→测试→构建镜像→部署，全自动
• 完整演练一次故障处理四步法，写出复盘报告

最后，六条掏心窝的建议

1. 命令不用背，思路必须熟。服务不通先ping再dig再curl，这个顺序应该是条件反射，不是知识点。

2. 每解决一个问题，写三行笔记。问题、原因、命令。攒一年，这就是你最值钱的资产，比任何教程都好用。

3. 在虚拟机里故意搞破坏。删库、写满磁盘、改错fstab，然后救回来。救过火的人和没救过火的人，处理故障时的心跳都不一样。

4. 先学RHEL系。企业主流是Rocky/Alma这一系，面试也主要问这个。

5. 阶段四之前别碰K8s。基础不牢直接上K8s的人，连Pod为什么起不来都查不明白，白白被劝退。

6. 找个真实场景。给自己的项目搭监控、帮朋友管台服务器。简历上"独立负责"四个字，比十张证书管用。