1. 先搞清楚Linux和Windows的本质差异再动手1.1 一切皆文件到底是什么意思很多初学者第一次接触Linux时最不适应的地方是——怎么没有C盘、D盘双击桌面的图标为什么不能打开东西我第一次完整负责一台Linux服务器时心态也是崩溃的。但当你真正了解Linux的设计哲学之后会发现这种看起来不友好的背后恰恰是它强大的原因。Linux的核心设计思想是一切皆文件。硬件设备、管道、网络连接、进程信息几乎所有的资源都被抽象成了文件。你的硬盘是文件键盘是文件甚至CPU的信息也挂在/proc目录下的文件里。这意味着什么呢意味着你的系统信息可以通过read、write这样的普通文件操作来访问整个系统的接口是统一的。举个例子我想看看系统当前的内存使用情况在Linux里就是cat /proc/meminfo。我觉得CPU有问题就看cat /proc/cpuinfo。这些操作背后没有复杂的API就是读文件。当你习惯这种思维方式后排查问题的路径会变得非常清晰先想想这个东西在Linux里被抽象成了什么文件然后去读它。1.2 组合优于集成小工具拼出大能力Windows下面的很多软件试图把什么都集成在一起我给你一个图形界面你点什么就出什么。Linux走了另外一条路每个工具只做一件事但把这件事做到极致。grep负责文本查找sed负责文本替换和行处理awk负责数据分列和格式化输出sort负责排序cut负责截取字段。单独看任何一个工具都不复杂但通过管道|把它们组合起来就能完成非常复杂的数据处理任务。这种感觉有点像搭积木。之前我处理一份访问日志想统计某个时间段内请求次数最多的前10个IP一条命令就搞定grep 2025-01-15 10: /var/log/nginx/access.log | awk {print $1} | sort | uniq -c | sort -nr | head -10这条命令虽然没有用任何编程语言却完成了按时间段过滤、取IP字段、排序、计数去重、按次数倒序、取前10这一连串操作。放到Windows的图形环境里你反而不知道用什么工具来做这件事。这就是Linux组合优于集成的威力——你不用学一个庞大的数据处理软件学会几个小命令就能自由拼装出自己需要的功能。1.3 多用户与权限为什么默认不能直接跑root在Windows里许多年来默认管理员就是上帝权限想干什么就干什么。Linux不一样它从设计之初就是多用户操作系统权限隔离提供了非常清晰的边界。Linux的权限分为三类文件所有者、用户组、其他用户。每种组又有三种权限读、写、执行。这套模型虽然简单却构成了Linux安全体系的地基。日常使用中我强烈建议不要一直用root用户跑操作。为什么因为root的权限没有边界一个手滑的rm -rf可能把整个系统删掉一个配错的配置文件可能让服务完全无法启动。我在某次部署时就因为用root改了一个系统配置文件把系统环境变量搞坏了导致所有命令都找不到路径当时整个人都懵了。后来养成习惯平时用普通用户需要提权时用sudo每次都明确知道自己要以管理员身份执行哪一条命令。这个习惯帮我挡掉了不少低级事故。2. 命令行实操每天都会用到的核心命令体系2.1 文件与目录管理把这些命令变成肌肉记忆如果你问一个老运维最常用的命令是什么答案大概率还是那批最基础的文件操作命令。这些命令不需要查文档必须做到条件反射速度可以用。操作需求命令注意事项切换目录cdcd -可以回到上一次的目录查看目录内容ls建议直接用ls -lah显示隐藏文件和详细信息复制文件cp -a-a保留所有属性复制目录必须加-r移动/重命名mv跨文件系统时会先复制再删除速度慢删除文件rm删目录加-r删文件不需要递归查看文件内容cat、less大文件用lesscat会把内容一次性刷满屏幕查找文件find复杂条件查找效率极高创建目录mkdir -p-p可以递归创建目录不会报错有个细节值得单独说cp和rsync的区别。cp适合单机内、同文件系统的复制rsync适合大目录、跨机器同步它支持增量传输断点续传还能通过--delete参数让目标目录与源目录完全一致。我第一次做服务器数据备份时不知道rsync用cp复制了一个上百GB的目录中途断了只能从头再来白白浪费了几个小时。后来换了rsync备份效率提升了一大截。2.2 文本处理四件套grep、sed、awk、sort文本处理能力是Linux命令行的杀手级优势。很多你以为需要写程序处理的事情其实用这几条命令就能在几秒内完成。grep是文本搜索的主力。常规用法是grep 关键字 文件名但更常用的是配合管道处理命令输出。我排查服务异常时最常用的套路是tail -500 /var/log/syslog | grep -i error这样只显示最后500行日志中出现error的记录不区分大小写。grep -c可以统计匹配行数grep -v可以做反向匹配排除不需要的行。sed是流编辑器最典型的用途是批量替换文本。我的需求是批量修改配置文件里的端口号sed -i s/8080/9090/g /etc/nginx/conf.d/*.conf-i表示直接修改原文件。这条命令把当前目录下所有配置文件里的8080批量改成9090。要提醒一句用-i之前最好先备份原文件或者用sed -i.bak这样的写法让命令自动生成备份文件。我自己有过使用sed -i误改配置的教训从此凡是批量改文件前都先备份。awk是分列处理的利器默认按空格把每行拆成多个字段$1是第一列$2是第二列。假如我想查系统进程里nginx占用的内存ps aux | grep nginx | grep -v grep | awk {print $6}sort和uniq的组合专门对付统计需求。具体用法就是我前面提过的访问日志统计场景。uniq -c会在每行前面统计重复次数sort -nr按数值倒序排列。这几个工具配合管道基本可以处理运维中遇到的九成日志统计需求。2.3 进程与资源查看系统状态一网打尽系统变慢、服务挂了、CPU飙到百分之百这些排查都需要看进程和资源信息。top是最基础的实时进程监控工具按shift P按CPU排序按shift M按内存排序。不过我更推荐一个新一点的工具htop显示更友好支持鼠标操作但可能默认没有安装需要用包管理器装一下。free -h看内存注意这里的缓冲区buff/cache其实是可以被系统回收利用的实际可用内存要看available这一列而不是直接看free那列。很多新手看到free很小就紧张其实是在物理内存中缓存了文件页并不代表内存不够用。df -h看磁盘分区使用率du -sh看某个目录的占用总大小。进程管理方面杀进程的经典指令是kill -9 PID但-9意味着强制终止不给进程任何善后机会。能先用普通kill默认发SIGTERM信号就让进程主动退出的就别急着-9否则很可能留下异常状态的文件或锁。我见过有人对数据库进程直接kill -9结果数据库重启后出现数据文件不一致的报错修复起来极其麻烦。systemctl是CentOS 7和Ubuntu 16.04之后的主流服务管理工具。常用的几条systemctl start nginx systemctl enable nginx systemctl status nginx systemctl daemon-reload启动服务、设置开机自启、查看状态、重载配置全部靠这几条。不要再去背那些老旧的service nginx start方式了systemctl统一化了服务管理配置文件里有任何语法错误daemon-reload就会立刻告诉你答案。3. 系统与磁盘规划装系统之前就该想清楚的事3.1 分区方案根分区、swap、数据分区怎么切装系统时分区规划合理未来能省掉十倍麻烦。我见过太多因为分区规划不合理最后只能破坏性重装系统的案例。先说根分区/。这个分区决定了操作系统核心文件的存放空间必须预留足够大小。安装的软件、系统日志、缓存很多都默认写到/下面。我建议至少在60GB以上如果你要装各种开发环境、数据库、编译工具链100GB都不算多。再聊swap。swap是磁盘上模拟出来的内存空间当物理内存不够时系统会把不常访问的内存页换到swap里。过去内存小的年代swap对服务器的稳定性至关重要。我个人的经验是内存小于8GB时swap设置成内存的2倍内存超过16GB时swap给4到8GB就够了主要是为了应对突发的内存压力防止进程被直接杀死。数据分区要单独挂载。比如数据库数据存/var/lib/mysql网站文件存/www日志存/var/log。这样做的核心价值是隔离故障——如果日志或缓存把某个分区写满了不会拖垮整个系统其他方面的运行尤其是不会把数据库所在的分区连带撑爆。我自己管理的一台服务器就专门划了独立分区给日志某次日志量暴增几十GB其他业务完全没受影响。3.2 LVM逻辑卷管理硬盘不够时的扩容救星LVM完整解决的问题是电脑空间不够了要不要重装系统。传统分区方案下一个分区的大小是在装系统时就定死的后面想扩容非常痛苦。LVM把物理磁盘分成物理卷PV再聚合到卷组VG最后从卷组里划分逻辑卷LV。逻辑卷的大小可以随时调整还可以跨多块物理磁盘聚合。我举一个实际场景。某台服务器最初分配了100GB数据分区跑了不到一年发现快满了。用LVM的话只需要插入一块新硬盘或者把另一块闲置磁盘加进来pvcreate /dev/sdb vgextend 卷组名 /dev/sdb lvextend -L 200G /dev/卷组名/数据逻辑卷 resize2fs /dev/卷组名/数据逻辑卷前两步把新磁盘加入卷组第三步给逻辑卷增加200GB第四步让文件系统感知到变大的空间。全程在线操作不需要卸载、不需要重启服务。如果用的是传统分区这种扩容基本上只能靠停机迁移伤害性极大。不过LVM也不是没有缺点理论上多了一层抽象如果物理卷损坏恢复难度比普通分区稍高。所以在规划时我通常只对数据分区和根分区做LVM并且坚持把重要数据做备份不要把一切希望都寄托在某种技术上。3.3 文件系统选型ext4、XFS的背景差异格式化分区时有个选择文件系统类型。最常见的是ext4和XFS两者都是成熟的老牌文件系统日常使用差距不大但特性上有倾向性。ext4是Red Hat系和Debian系的默认选择稳定、兼容性好、对新手最友好支持在线扩容支持ext3直接升级。如果拿不准选什么ext4肯定不会错。XFS的强项是大文件、高并发的吞吐性能特别适合数据库的数据文件、虚拟化镜像这种大体积文件。XFS还支持更大容量的单个文件系统但XFS不能缩容只能扩容而且它原先不建议直接作为根分区使用后来新版系统才逐步放开限制。还有一个有趣的是btrfs它自带快照、压缩、校验功能但功能越复杂出问题的概率也越高。公有云、生产环境保守选择ext4或XFS就好btrfs之类的新玩意是折腾型玩家的玩具生产环境不要拿稳定性开玩笑。4. 权限与安全加固从入门到实用的完整路径4.1 权限位的逐位拆解权限管理是Linux安全模型的核心。一个文件或目录的权限用10个字符表示比如drwxr-xr--。第一个字符d表示这是个目录。后面三个字符一组依次是所有者权限、用户组权限、其他人权限r代表读、w代表写、x代表执行。我理解权限模型有个生活化的类比文件是房间所有者是房东用户组是一家人其他用户是路人。房东能做什么家人能做什么路人能做什么分别由三组权限位控制。调整权限的命令是chmod。最常用的写法是数字法r4、w2、x1把三个数字加起来。比如chmod 750表示所有者rwx、组rx、其他人无权限。这个数字法的好处是简洁chmod -R 755 目录就能递归设置整个目录树的权限。chown用来变更所有者和组chown -R nginx:nginx /www把自己创建的目录交给nginx用户管理这是一条非常常见的部署操作。实际运维中我踩过一个和权限有关的坑网站上传图片后打开显示404排查了半天发现是图片目录权限不对进程写不进文件。日志系统通常不会告诉你权限不足这种细节需要你用ls -l把所有者、用户组比对一遍才能定位问题。4.2 sudo策略最小化提权前面说过不要一直用root但真实业务场景总有需要管理员操作的时候sudo就是那个可控的提权通道。sudo的配置文件是/etc/sudoers官方推荐不要直接改这个文件而是用visudo命令编辑它会在保存时校验语法操作失误不会立刻破坏系统。给指定用户授权时不要一上来就user ALL(ALL) ALL这样的大宽泛权限尽量细化到命令级别某个普通用户 ALL(ALL) /bin/systemctl restart nginx这样的话这个用户只能通过sudo重启nginx服务其他任何管理员操作都执行不了权限收得很窄。这个思路来自最小权限原则每个用户应该只拥有完成他工作需要的最少权限。如果某个开发人员只需要重启应用服务、查看日志就只给他这些权限其他所有操作一律走正常审批流程。4.3 防火墙基础白名单思维一台Linux服务器放在公网上桌面系统常见的诱惑就像暴露在随时有人敲门的环境里。防火墙的核心思维是白名单默认拒绝一切外部连接只放行明确信任的流量。这个思维和物理世界的门禁系统很像。主流系统里管理防火墙的工具包括firewalldCentOS系和ufwUbuntu系。在CentOS上我习惯这样操作firewall-cmd --permanent --zonepublic --add-rich-rulerule familyipv4 source address192.168.1.0/24 port port22 protocoltcp accept firewall-cmd --reload这条命令只允许内网网段访问SSH的22端口公网IP一律进不来。数据库端口、管理端口用同样方式限制来源IP把端口暴露面控制住是成本最低的安全手段之一。有人觉得防火墙配置麻烦干脆关掉了事。这种图省事的做法等于把大门敞开被扫描到开放端口后接下来就是暴力破解、漏洞探测、勒索加密一条龙服务实际就是这么残酷。4.4 系统日志审计日志审计经常被忽略但在排查安全事件时日志是唯一能还原真相的证据来源。Linux系统有两个日志体系老的系统日志保存在/var/log/messages或/var/log/syslog。新版系统里更核心的是journalctl它是systemd统一的日志系统可以查询系统启动以来所有的服务日志。查询某个服务最近的报错直接journalctl -u nginx.service --since 1 hour ago --no-pager | grep -i error安全审查时我特别关注/var/log/secure或auth.log所有用户认证成功的记录都在里面。可以统计一下有没有人暴力破解你的SSH账号grep Failed password /var/log/secure | awk {print $11} | sort | uniq -c | sort -nr | head -10把来源IP按攻击次数排个序如果发现某个IP连续尝试几百次那就是明显的暴力破解迹象。我处理这种问题的方法简单粗暴先用防火墙封禁该IP再看有没有账号被攻破的痕迹最后建议启用密钥登录、关闭密码登录。这一套操作下来被暴力破解的风险能下降一个数量级。5. 日志与故障排查的一线经验5.1 journalctl日志排查实例我处理过一次服务偶尔性超时的疑难杂症。应用本身看起来没挂但请求响应时间长达几十秒非常影响体验。一开始怀疑网络问题检查了半天没问题又怀疑数据库连接池也看不出异常。后来想起看一下systemd日志里有没有报错执行journalctl -u 某应用服务 --since 3 hours ago --no-pager结果发现日志里反复出现进程堆内存溢出后自动重启的记录。这个信息没有在应用日志里体现却在systemd日志中留下了痕迹。原来应用的内存限制设置得太低流量稍微上来就触发了内存上限进程反复被杀重启。调整了内存限制和堆配置之后超时问题再没出现过。这个案例给了我一个深刻教训排查问题不要只盯着应用自己的日志系统层面的日志同样重要。journalctl -u 服务名能看到服务何时启动、何时停止、停止时有没有异常信号这些信息往往比应用日志更接近问题的根因。出现异常后还能配合时间戳反向追踪journalctl --since 2025-01-20 10:00:00 --until 2025-01-20 10:30:00精确查看某个时间窗口里到底发生了什么。5.2 磁盘写满的排查完整链路磁盘空间满了这是运维里最常见的故障之一可能性非常多。如果数据库突然写入失败、日志突然打不出来、网站突然500第一个念头就应该看看磁盘。完整的排查顺序是先确认整体情况再逐级缩小范围。第一步看磁盘整体使用率df -h出现/dev/mapper/root 100%这种输出时说明某个分区已经满了。第二步进入该分区的根目录找具体是哪个目录占用最大du -sh /* 2/dev/null | sort -hr | head -10du -sh /*算出根目录下每个一级目录的占用大小然后排序取前10。找到嫌疑目录后再逐层深入du -sh /var/log/* | sort -hr | head -10就这样一级一级往里追直到定位到占用最大的具体文件或目录。最常见的元凶是应用日志、数据库日志、缓存目录、临时文件。处理手段对应日志轮转、定时清理、把数据目录挪到独立大分区。有个小坑值得说用rm删掉了文件df -h还是显示100%。原因是进程还在持续写入这个文件。在Linux里rm文件只是删除了目录项的引用文件其实还占着磁盘空间直到打开它的所有进程关闭或者退出。解决办法是找出还在占用这个文件的进程并重启它或者用cat /dev/null 文件名把文件内容清空而不是删除文件cat /dev/null /var/log/某个被占用的日志.log这个操作保留了文件在磁盘上的索引节点所以进程不会丢失写入句柄同时又释放了空间。5.3 网络故障的排查顺序网络出了问题很多人第一反应是重启服务器或者重启网络服务。其实排查网络有明确的基本步骤按顺序走比瞎试高效得多。先看本机IP是否正常ip addr确认网卡有正确的IP地址。再看路由和网关ip route网关错了数据包根本发不出去。然后ping一下网关再ping一下外网地址区分是内网问题还是外网问题。ping通了说明链路和路由方面基本正常。接下来测试DNS解析nslookup 某个域名一个常见现象是IP能通但域名访问不了十有八九是DNS配置问题检查/etc/resolv.conf里的nameserver配置。如果以上都正常还是无法访问服务需要看端口是否在监听ss -lntp | grep 80这个命令能显示80端口有没有被进程监听。没监听就是服务没起来监听着但外部连不上再看防火墙有没有放行。这里的排查顺序是本机网络配置、网关路由、公网连通、DNS解析、端口监听、防火墙规则。掌握了这套顺序绝大多数网络问题十分钟内就能定位。6. Shell脚本与自动化把重复劳动变成定时任务6.1 从一条命令到一段脚本Linux命令行有一个水晶般的能力每一个你手动执行的操作都可以写成脚本再把它交给定时任务。运维里最宝贵的就是自动化思维。Shell脚本本质上就是把一批命令放进同一个文件按顺序执行。定义一个简单的备份脚本#!/bin/bash # 备份指定目录到备份目录保留最近7天 backup_dir/backup/mysql source_dir/var/lib/mysql date_str$(date %F) tar -czf $backup_dir/mysql_$date_str.tar.gz $source_dir find $backup_dir -name mysql_*.tar.gz -mtime 7 -exec rm {} \;这个脚本做的事情是把数据库文件打包成当天的带日期的压缩包然后删除7天前的备份。在Linux里学会写脚本只需要几周但带来的时间节省却是一辈子的。手动执行一条命令只要几秒钟但脚本可以挂上定时任务每天凌晨自动执行不需要有人惦记着这件事。写脚本有几个基本习惯很重要。脚本开头必须有#!/bin/bash声明解释器执行前先chmod x 脚本.sh变量加双引号以防包含空格的文件名导致意外date类命令能通过命令替换生成当天的结果。备份脚本由于涉及定时执行建议写完后先用bash -n 脚本.sh检查语法再手动跑一遍确认输出和清理行为都符合预期再挂到定时任务。6.2 日志清理脚本的完整实现日志清理是最典型的自动化需求。服务跑起来后日志文件会不断增长磁盘迟早被撑满光靠人肉删除不现实。我常用的日志清理策略是只保留最近N天的文件脚本如下#!/bin/bash log_root/data/logs keep_days30 find $log_root -mtime $keep_days -name *.log -delete这段脚本通过find查找超过30天的.log文件并直接删除。有人会担心-delete误删重要文件那就加上-type f只匹配普通文件先用不带-delete的命令查看匹配结果确认无误后再启用真正的清理。配合crontab -e设置定时任务每天凌晨3点执行0 3 * * * /root/scripts/clean_log.shcrontab的五个字段分别是分钟、小时、日期、月份、星期其中*代表任意值。调试cron任务时常见的坑是脚本手动执行正常定时执行却不生效。原因几乎都是环境变量问题——cron执行时用的是精简环境PATH里面可能没有脚本里用到的命令所在的路径。在脚本开头显式声明PATH/usr/local/bin:/usr/bin:/bin或者全部用绝对路径能解决一大批这类问题。有个更高级的日志管理方案是logrotate它是系统自带的日志轮转工具按天、按大小自动切割日志文件还能设定保留数量。配置在/etc/logrotate.d/下像这样的配置就表示每天切割某个日志/data/logs/business.log { daily rotate 7 compress missingok }如果你连脚本都不想写logrotate几乎就是开箱即食的方案。不过它只处理日志文件无法处理类似清理临时上传文件这类需求因此写自己的脚本仍然是必备技能。6.3 cron实战中的细节定时任务粒度方面cron的最小粒度是分钟如果你需要每隔30秒执行一次任务cron做不到需要在脚本里自己通过循环控制或者用systemd-timer。我自己遇到过一个场景监控脚本需要每20秒检查一次服务状态cron根本排不了那么密的任务最后是用sleep在脚本里做了循环。#!/bin/bash while true; do /root/scripts/check_service.sh sleep 20 done然后用cron每分钟启动这个脚本一次脚本自身通过sleep控制轮询频率。这种方法非常适合轻量级监控任务不过要注意脚本内部不能出现无法自动退出的逻辑否则会产生多个重复进程。7. 最后补几个新手最容易踩的坑7.1 常见坑盘点第一个坑是rm -rf配合通配符使用时不加检查。我见过有人写rm -rf /www/备份目录 /本意是删掉备份目录但手滑多打了个空格结果把根目录删了。这不是段子是真的会发生的低级事故。我的建议是执行任何删除操作前先用ls看路径是否正确rm尽量不要带-f让系统在删除前提示确认更保险的写法是每次删除前先cd到目标目录再相对路径删除减少绝对路径误删的几率。第二个坑是修改配置文件后不检查语法就重启服务。改错了语法不仅服务起不来还会影响线上业务。nginx改完配置先执行nginx -t检查语法systemd服务改完配置先systemctl daemon-reload再重启。第三个坑是权限配置过于宽泛最典型的就是chmod -R 777。一旦目录对所有人都开放写权限你就失去了日志可信度——攻击者可以篡改目录里的任意文件。我用777处理过临时开发环境的问题但生产环境一旦出现777我就会警惕是不是哪里配置不严谨。第四个坑是遇到问题先重启不分析根因。重启确实能临时恢复服务但如果是配置错误、磁盘写满、内存泄漏这类问题重启后过段时间又会复发。能通过日志定位到具体原因的一定要找到根因再行动不然就是在拖延故障。7.2 学习路径方面的个人建议Linux不适合像背课本一样硬啃最佳学习方式是带着问题学。如果完全没基础我最推荐的学习路径是先装一个Linux虚拟机或者直接买一台便宜云主机把日常操作全部切换过去。不用刻意背命令只要重复使用命令自然就记住了。遇到不会的操作先查文档了解原理再试验和总结经验。有基础后想提升核心做法是从会用命令升级到理解原理。比如你熟悉了ps可以进一步看进程是怎么管理调度的你熟悉了网络命令可以进一步看TCP握手挥手的状态变化。原理层面的理解不会直接反映在命令输入效率上但对问题排查会有决断性的帮助。最后一定不能少的是手动搭建一套完整环境。比如亲手装一个LNMP环境配置虚拟主机、数据库、日志轮转、防火墙规则再模拟几次故障演练排查。整个过程走一遍之后你对Linux的理解会从碎片化命令库转变为一个系统化操作系统后续无论维护哪台服务器、排查什么问题心里都会有一个底色。我个人在这条路上走下来的最大体会是Linux并没有多神秘它就是一套以文件、权限、进程、网络为核心要素的逻辑学会的关键在于多用、多踩坑、多总结。把每天的异常都当作一次学习机会一段时间下来你就能从新手变成一个遇到故障能稳住心态的老手。 
长河君 · 2026/10/19 3:23:56 · 阅读 1.2k Linux运维实战：从文件权限到Shell脚本自动化排查全指南
1. 先搞清楚Linux和Windows的本质差异再动手1.1 一切皆文件到底是什么意思很多初学者第一次接触Linux时最不适应的地方是——怎么没有C盘、D盘双击桌面的图标为什么不能打开东西我第一次完整负责一台Linux服务器时心态也是崩溃的。但当你真正了解Linux的设计哲学之后会发现这种看起来不友好的背后恰恰是它强大的原因。Linux的核心设计思想是一切皆文件。硬件设备、管道、网络连接、进程信息几乎所有的资源都被抽象成了文件。你的硬盘是文件键盘是文件甚至CPU的信息也挂在/proc目录下的文件里。这意味着什么呢意味着你的系统信息可以通过read、write这样的普通文件操作来访问整个系统的接口是统一的。举个例子我想看看系统当前的内存使用情况在Linux里就是cat /proc/meminfo。我觉得CPU有问题就看cat /proc/cpuinfo。这些操作背后没有复杂的API就是读文件。当你习惯这种思维方式后排查问题的路径会变得非常清晰先想想这个东西在Linux里被抽象成了什么文件然后去读它。1.2 组合优于集成小工具拼出大能力Windows下面的很多软件试图把什么都集成在一起我给你一个图形界面你点什么就出什么。Linux走了另外一条路每个工具只做一件事但把这件事做到极致。grep负责文本查找sed负责文本替换和行处理awk负责数据分列和格式化输出sort负责排序cut负责截取字段。单独看任何一个工具都不复杂但通过管道|把它们组合起来就能完成非常复杂的数据处理任务。这种感觉有点像搭积木。之前我处理一份访问日志想统计某个时间段内请求次数最多的前10个IP一条命令就搞定grep 2025-01-15 10: /var/log/nginx/access.log | awk {print $1} | sort | uniq -c | sort -nr | head -10这条命令虽然没有用任何编程语言却完成了按时间段过滤、取IP字段、排序、计数去重、按次数倒序、取前10这一连串操作。放到Windows的图形环境里你反而不知道用什么工具来做这件事。这就是Linux组合优于集成的威力——你不用学一个庞大的数据处理软件学会几个小命令就能自由拼装出自己需要的功能。1.3 多用户与权限为什么默认不能直接跑root在Windows里许多年来默认管理员就是上帝权限想干什么就干什么。Linux不一样它从设计之初就是多用户操作系统权限隔离提供了非常清晰的边界。Linux的权限分为三类文件所有者、用户组、其他用户。每种组又有三种权限读、写、执行。这套模型虽然简单却构成了Linux安全体系的地基。日常使用中我强烈建议不要一直用root用户跑操作。为什么因为root的权限没有边界一个手滑的rm -rf可能把整个系统删掉一个配错的配置文件可能让服务完全无法启动。我在某次部署时就因为用root改了一个系统配置文件把系统环境变量搞坏了导致所有命令都找不到路径当时整个人都懵了。后来养成习惯平时用普通用户需要提权时用sudo每次都明确知道自己要以管理员身份执行哪一条命令。这个习惯帮我挡掉了不少低级事故。2. 命令行实操每天都会用到的核心命令体系2.1 文件与目录管理把这些命令变成肌肉记忆如果你问一个老运维最常用的命令是什么答案大概率还是那批最基础的文件操作命令。这些命令不需要查文档必须做到条件反射速度可以用。操作需求命令注意事项切换目录cdcd -可以回到上一次的目录查看目录内容ls建议直接用ls -lah显示隐藏文件和详细信息复制文件cp -a-a保留所有属性复制目录必须加-r移动/重命名mv跨文件系统时会先复制再删除速度慢删除文件rm删目录加-r删文件不需要递归查看文件内容cat、less大文件用lesscat会把内容一次性刷满屏幕查找文件find复杂条件查找效率极高创建目录mkdir -p-p可以递归创建目录不会报错有个细节值得单独说cp和rsync的区别。cp适合单机内、同文件系统的复制rsync适合大目录、跨机器同步它支持增量传输断点续传还能通过--delete参数让目标目录与源目录完全一致。我第一次做服务器数据备份时不知道rsync用cp复制了一个上百GB的目录中途断了只能从头再来白白浪费了几个小时。后来换了rsync备份效率提升了一大截。2.2 文本处理四件套grep、sed、awk、sort文本处理能力是Linux命令行的杀手级优势。很多你以为需要写程序处理的事情其实用这几条命令就能在几秒内完成。grep是文本搜索的主力。常规用法是grep 关键字 文件名但更常用的是配合管道处理命令输出。我排查服务异常时最常用的套路是tail -500 /var/log/syslog | grep -i error这样只显示最后500行日志中出现error的记录不区分大小写。grep -c可以统计匹配行数grep -v可以做反向匹配排除不需要的行。sed是流编辑器最典型的用途是批量替换文本。我的需求是批量修改配置文件里的端口号sed -i s/8080/9090/g /etc/nginx/conf.d/*.conf-i表示直接修改原文件。这条命令把当前目录下所有配置文件里的8080批量改成9090。要提醒一句用-i之前最好先备份原文件或者用sed -i.bak这样的写法让命令自动生成备份文件。我自己有过使用sed -i误改配置的教训从此凡是批量改文件前都先备份。awk是分列处理的利器默认按空格把每行拆成多个字段$1是第一列$2是第二列。假如我想查系统进程里nginx占用的内存ps aux | grep nginx | grep -v grep | awk {print $6}sort和uniq的组合专门对付统计需求。具体用法就是我前面提过的访问日志统计场景。uniq -c会在每行前面统计重复次数sort -nr按数值倒序排列。这几个工具配合管道基本可以处理运维中遇到的九成日志统计需求。2.3 进程与资源查看系统状态一网打尽系统变慢、服务挂了、CPU飙到百分之百这些排查都需要看进程和资源信息。top是最基础的实时进程监控工具按shift P按CPU排序按shift M按内存排序。不过我更推荐一个新一点的工具htop显示更友好支持鼠标操作但可能默认没有安装需要用包管理器装一下。free -h看内存注意这里的缓冲区buff/cache其实是可以被系统回收利用的实际可用内存要看available这一列而不是直接看free那列。很多新手看到free很小就紧张其实是在物理内存中缓存了文件页并不代表内存不够用。df -h看磁盘分区使用率du -sh看某个目录的占用总大小。进程管理方面杀进程的经典指令是kill -9 PID但-9意味着强制终止不给进程任何善后机会。能先用普通kill默认发SIGTERM信号就让进程主动退出的就别急着-9否则很可能留下异常状态的文件或锁。我见过有人对数据库进程直接kill -9结果数据库重启后出现数据文件不一致的报错修复起来极其麻烦。systemctl是CentOS 7和Ubuntu 16.04之后的主流服务管理工具。常用的几条systemctl start nginx systemctl enable nginx systemctl status nginx systemctl daemon-reload启动服务、设置开机自启、查看状态、重载配置全部靠这几条。不要再去背那些老旧的service nginx start方式了systemctl统一化了服务管理配置文件里有任何语法错误daemon-reload就会立刻告诉你答案。3. 系统与磁盘规划装系统之前就该想清楚的事3.1 分区方案根分区、swap、数据分区怎么切装系统时分区规划合理未来能省掉十倍麻烦。我见过太多因为分区规划不合理最后只能破坏性重装系统的案例。先说根分区/。这个分区决定了操作系统核心文件的存放空间必须预留足够大小。安装的软件、系统日志、缓存很多都默认写到/下面。我建议至少在60GB以上如果你要装各种开发环境、数据库、编译工具链100GB都不算多。再聊swap。swap是磁盘上模拟出来的内存空间当物理内存不够时系统会把不常访问的内存页换到swap里。过去内存小的年代swap对服务器的稳定性至关重要。我个人的经验是内存小于8GB时swap设置成内存的2倍内存超过16GB时swap给4到8GB就够了主要是为了应对突发的内存压力防止进程被直接杀死。数据分区要单独挂载。比如数据库数据存/var/lib/mysql网站文件存/www日志存/var/log。这样做的核心价值是隔离故障——如果日志或缓存把某个分区写满了不会拖垮整个系统其他方面的运行尤其是不会把数据库所在的分区连带撑爆。我自己管理的一台服务器就专门划了独立分区给日志某次日志量暴增几十GB其他业务完全没受影响。3.2 LVM逻辑卷管理硬盘不够时的扩容救星LVM完整解决的问题是电脑空间不够了要不要重装系统。传统分区方案下一个分区的大小是在装系统时就定死的后面想扩容非常痛苦。LVM把物理磁盘分成物理卷PV再聚合到卷组VG最后从卷组里划分逻辑卷LV。逻辑卷的大小可以随时调整还可以跨多块物理磁盘聚合。我举一个实际场景。某台服务器最初分配了100GB数据分区跑了不到一年发现快满了。用LVM的话只需要插入一块新硬盘或者把另一块闲置磁盘加进来pvcreate /dev/sdb vgextend 卷组名 /dev/sdb lvextend -L 200G /dev/卷组名/数据逻辑卷 resize2fs /dev/卷组名/数据逻辑卷前两步把新磁盘加入卷组第三步给逻辑卷增加200GB第四步让文件系统感知到变大的空间。全程在线操作不需要卸载、不需要重启服务。如果用的是传统分区这种扩容基本上只能靠停机迁移伤害性极大。不过LVM也不是没有缺点理论上多了一层抽象如果物理卷损坏恢复难度比普通分区稍高。所以在规划时我通常只对数据分区和根分区做LVM并且坚持把重要数据做备份不要把一切希望都寄托在某种技术上。3.3 文件系统选型ext4、XFS的背景差异格式化分区时有个选择文件系统类型。最常见的是ext4和XFS两者都是成熟的老牌文件系统日常使用差距不大但特性上有倾向性。ext4是Red Hat系和Debian系的默认选择稳定、兼容性好、对新手最友好支持在线扩容支持ext3直接升级。如果拿不准选什么ext4肯定不会错。XFS的强项是大文件、高并发的吞吐性能特别适合数据库的数据文件、虚拟化镜像这种大体积文件。XFS还支持更大容量的单个文件系统但XFS不能缩容只能扩容而且它原先不建议直接作为根分区使用后来新版系统才逐步放开限制。还有一个有趣的是btrfs它自带快照、压缩、校验功能但功能越复杂出问题的概率也越高。公有云、生产环境保守选择ext4或XFS就好btrfs之类的新玩意是折腾型玩家的玩具生产环境不要拿稳定性开玩笑。4. 权限与安全加固从入门到实用的完整路径4.1 权限位的逐位拆解权限管理是Linux安全模型的核心。一个文件或目录的权限用10个字符表示比如drwxr-xr--。第一个字符d表示这是个目录。后面三个字符一组依次是所有者权限、用户组权限、其他人权限r代表读、w代表写、x代表执行。我理解权限模型有个生活化的类比文件是房间所有者是房东用户组是一家人其他用户是路人。房东能做什么家人能做什么路人能做什么分别由三组权限位控制。调整权限的命令是chmod。最常用的写法是数字法r4、w2、x1把三个数字加起来。比如chmod 750表示所有者rwx、组rx、其他人无权限。这个数字法的好处是简洁chmod -R 755 目录就能递归设置整个目录树的权限。chown用来变更所有者和组chown -R nginx:nginx /www把自己创建的目录交给nginx用户管理这是一条非常常见的部署操作。实际运维中我踩过一个和权限有关的坑网站上传图片后打开显示404排查了半天发现是图片目录权限不对进程写不进文件。日志系统通常不会告诉你权限不足这种细节需要你用ls -l把所有者、用户组比对一遍才能定位问题。4.2 sudo策略最小化提权前面说过不要一直用root但真实业务场景总有需要管理员操作的时候sudo就是那个可控的提权通道。sudo的配置文件是/etc/sudoers官方推荐不要直接改这个文件而是用visudo命令编辑它会在保存时校验语法操作失误不会立刻破坏系统。给指定用户授权时不要一上来就user ALL(ALL) ALL这样的大宽泛权限尽量细化到命令级别某个普通用户 ALL(ALL) /bin/systemctl restart nginx这样的话这个用户只能通过sudo重启nginx服务其他任何管理员操作都执行不了权限收得很窄。这个思路来自最小权限原则每个用户应该只拥有完成他工作需要的最少权限。如果某个开发人员只需要重启应用服务、查看日志就只给他这些权限其他所有操作一律走正常审批流程。4.3 防火墙基础白名单思维一台Linux服务器放在公网上桌面系统常见的诱惑就像暴露在随时有人敲门的环境里。防火墙的核心思维是白名单默认拒绝一切外部连接只放行明确信任的流量。这个思维和物理世界的门禁系统很像。主流系统里管理防火墙的工具包括firewalldCentOS系和ufwUbuntu系。在CentOS上我习惯这样操作firewall-cmd --permanent --zonepublic --add-rich-rulerule familyipv4 source address192.168.1.0/24 port port22 protocoltcp accept firewall-cmd --reload这条命令只允许内网网段访问SSH的22端口公网IP一律进不来。数据库端口、管理端口用同样方式限制来源IP把端口暴露面控制住是成本最低的安全手段之一。有人觉得防火墙配置麻烦干脆关掉了事。这种图省事的做法等于把大门敞开被扫描到开放端口后接下来就是暴力破解、漏洞探测、勒索加密一条龙服务实际就是这么残酷。4.4 系统日志审计日志审计经常被忽略但在排查安全事件时日志是唯一能还原真相的证据来源。Linux系统有两个日志体系老的系统日志保存在/var/log/messages或/var/log/syslog。新版系统里更核心的是journalctl它是systemd统一的日志系统可以查询系统启动以来所有的服务日志。查询某个服务最近的报错直接journalctl -u nginx.service --since 1 hour ago --no-pager | grep -i error安全审查时我特别关注/var/log/secure或auth.log所有用户认证成功的记录都在里面。可以统计一下有没有人暴力破解你的SSH账号grep Failed password /var/log/secure | awk {print $11} | sort | uniq -c | sort -nr | head -10把来源IP按攻击次数排个序如果发现某个IP连续尝试几百次那就是明显的暴力破解迹象。我处理这种问题的方法简单粗暴先用防火墙封禁该IP再看有没有账号被攻破的痕迹最后建议启用密钥登录、关闭密码登录。这一套操作下来被暴力破解的风险能下降一个数量级。5. 日志与故障排查的一线经验5.1 journalctl日志排查实例我处理过一次服务偶尔性超时的疑难杂症。应用本身看起来没挂但请求响应时间长达几十秒非常影响体验。一开始怀疑网络问题检查了半天没问题又怀疑数据库连接池也看不出异常。后来想起看一下systemd日志里有没有报错执行journalctl -u 某应用服务 --since 3 hours ago --no-pager结果发现日志里反复出现进程堆内存溢出后自动重启的记录。这个信息没有在应用日志里体现却在systemd日志中留下了痕迹。原来应用的内存限制设置得太低流量稍微上来就触发了内存上限进程反复被杀重启。调整了内存限制和堆配置之后超时问题再没出现过。这个案例给了我一个深刻教训排查问题不要只盯着应用自己的日志系统层面的日志同样重要。journalctl -u 服务名能看到服务何时启动、何时停止、停止时有没有异常信号这些信息往往比应用日志更接近问题的根因。出现异常后还能配合时间戳反向追踪journalctl --since 2025-01-20 10:00:00 --until 2025-01-20 10:30:00精确查看某个时间窗口里到底发生了什么。5.2 磁盘写满的排查完整链路磁盘空间满了这是运维里最常见的故障之一可能性非常多。如果数据库突然写入失败、日志突然打不出来、网站突然500第一个念头就应该看看磁盘。完整的排查顺序是先确认整体情况再逐级缩小范围。第一步看磁盘整体使用率df -h出现/dev/mapper/root 100%这种输出时说明某个分区已经满了。第二步进入该分区的根目录找具体是哪个目录占用最大du -sh /* 2/dev/null | sort -hr | head -10du -sh /*算出根目录下每个一级目录的占用大小然后排序取前10。找到嫌疑目录后再逐层深入du -sh /var/log/* | sort -hr | head -10就这样一级一级往里追直到定位到占用最大的具体文件或目录。最常见的元凶是应用日志、数据库日志、缓存目录、临时文件。处理手段对应日志轮转、定时清理、把数据目录挪到独立大分区。有个小坑值得说用rm删掉了文件df -h还是显示100%。原因是进程还在持续写入这个文件。在Linux里rm文件只是删除了目录项的引用文件其实还占着磁盘空间直到打开它的所有进程关闭或者退出。解决办法是找出还在占用这个文件的进程并重启它或者用cat /dev/null 文件名把文件内容清空而不是删除文件cat /dev/null /var/log/某个被占用的日志.log这个操作保留了文件在磁盘上的索引节点所以进程不会丢失写入句柄同时又释放了空间。5.3 网络故障的排查顺序网络出了问题很多人第一反应是重启服务器或者重启网络服务。其实排查网络有明确的基本步骤按顺序走比瞎试高效得多。先看本机IP是否正常ip addr确认网卡有正确的IP地址。再看路由和网关ip route网关错了数据包根本发不出去。然后ping一下网关再ping一下外网地址区分是内网问题还是外网问题。ping通了说明链路和路由方面基本正常。接下来测试DNS解析nslookup 某个域名一个常见现象是IP能通但域名访问不了十有八九是DNS配置问题检查/etc/resolv.conf里的nameserver配置。如果以上都正常还是无法访问服务需要看端口是否在监听ss -lntp | grep 80这个命令能显示80端口有没有被进程监听。没监听就是服务没起来监听着但外部连不上再看防火墙有没有放行。这里的排查顺序是本机网络配置、网关路由、公网连通、DNS解析、端口监听、防火墙规则。掌握了这套顺序绝大多数网络问题十分钟内就能定位。6. Shell脚本与自动化把重复劳动变成定时任务6.1 从一条命令到一段脚本Linux命令行有一个水晶般的能力每一个你手动执行的操作都可以写成脚本再把它交给定时任务。运维里最宝贵的就是自动化思维。Shell脚本本质上就是把一批命令放进同一个文件按顺序执行。定义一个简单的备份脚本#!/bin/bash # 备份指定目录到备份目录保留最近7天 backup_dir/backup/mysql source_dir/var/lib/mysql date_str$(date %F) tar -czf $backup_dir/mysql_$date_str.tar.gz $source_dir find $backup_dir -name mysql_*.tar.gz -mtime 7 -exec rm {} \;这个脚本做的事情是把数据库文件打包成当天的带日期的压缩包然后删除7天前的备份。在Linux里学会写脚本只需要几周但带来的时间节省却是一辈子的。手动执行一条命令只要几秒钟但脚本可以挂上定时任务每天凌晨自动执行不需要有人惦记着这件事。写脚本有几个基本习惯很重要。脚本开头必须有#!/bin/bash声明解释器执行前先chmod x 脚本.sh变量加双引号以防包含空格的文件名导致意外date类命令能通过命令替换生成当天的结果。备份脚本由于涉及定时执行建议写完后先用bash -n 脚本.sh检查语法再手动跑一遍确认输出和清理行为都符合预期再挂到定时任务。6.2 日志清理脚本的完整实现日志清理是最典型的自动化需求。服务跑起来后日志文件会不断增长磁盘迟早被撑满光靠人肉删除不现实。我常用的日志清理策略是只保留最近N天的文件脚本如下#!/bin/bash log_root/data/logs keep_days30 find $log_root -mtime $keep_days -name *.log -delete这段脚本通过find查找超过30天的.log文件并直接删除。有人会担心-delete误删重要文件那就加上-type f只匹配普通文件先用不带-delete的命令查看匹配结果确认无误后再启用真正的清理。配合crontab -e设置定时任务每天凌晨3点执行0 3 * * * /root/scripts/clean_log.shcrontab的五个字段分别是分钟、小时、日期、月份、星期其中*代表任意值。调试cron任务时常见的坑是脚本手动执行正常定时执行却不生效。原因几乎都是环境变量问题——cron执行时用的是精简环境PATH里面可能没有脚本里用到的命令所在的路径。在脚本开头显式声明PATH/usr/local/bin:/usr/bin:/bin或者全部用绝对路径能解决一大批这类问题。有个更高级的日志管理方案是logrotate它是系统自带的日志轮转工具按天、按大小自动切割日志文件还能设定保留数量。配置在/etc/logrotate.d/下像这样的配置就表示每天切割某个日志/data/logs/business.log { daily rotate 7 compress missingok }如果你连脚本都不想写logrotate几乎就是开箱即食的方案。不过它只处理日志文件无法处理类似清理临时上传文件这类需求因此写自己的脚本仍然是必备技能。6.3 cron实战中的细节定时任务粒度方面cron的最小粒度是分钟如果你需要每隔30秒执行一次任务cron做不到需要在脚本里自己通过循环控制或者用systemd-timer。我自己遇到过一个场景监控脚本需要每20秒检查一次服务状态cron根本排不了那么密的任务最后是用sleep在脚本里做了循环。#!/bin/bash while true; do /root/scripts/check_service.sh sleep 20 done然后用cron每分钟启动这个脚本一次脚本自身通过sleep控制轮询频率。这种方法非常适合轻量级监控任务不过要注意脚本内部不能出现无法自动退出的逻辑否则会产生多个重复进程。7. 最后补几个新手最容易踩的坑7.1 常见坑盘点第一个坑是rm -rf配合通配符使用时不加检查。我见过有人写rm -rf /www/备份目录 /本意是删掉备份目录但手滑多打了个空格结果把根目录删了。这不是段子是真的会发生的低级事故。我的建议是执行任何删除操作前先用ls看路径是否正确rm尽量不要带-f让系统在删除前提示确认更保险的写法是每次删除前先cd到目标目录再相对路径删除减少绝对路径误删的几率。第二个坑是修改配置文件后不检查语法就重启服务。改错了语法不仅服务起不来还会影响线上业务。nginx改完配置先执行nginx -t检查语法systemd服务改完配置先systemctl daemon-reload再重启。第三个坑是权限配置过于宽泛最典型的就是chmod -R 777。一旦目录对所有人都开放写权限你就失去了日志可信度——攻击者可以篡改目录里的任意文件。我用777处理过临时开发环境的问题但生产环境一旦出现777我就会警惕是不是哪里配置不严谨。第四个坑是遇到问题先重启不分析根因。重启确实能临时恢复服务但如果是配置错误、磁盘写满、内存泄漏这类问题重启后过段时间又会复发。能通过日志定位到具体原因的一定要找到根因再行动不然就是在拖延故障。7.2 学习路径方面的个人建议Linux不适合像背课本一样硬啃最佳学习方式是带着问题学。如果完全没基础我最推荐的学习路径是先装一个Linux虚拟机或者直接买一台便宜云主机把日常操作全部切换过去。不用刻意背命令只要重复使用命令自然就记住了。遇到不会的操作先查文档了解原理再试验和总结经验。有基础后想提升核心做法是从会用命令升级到理解原理。比如你熟悉了ps可以进一步看进程是怎么管理调度的你熟悉了网络命令可以进一步看TCP握手挥手的状态变化。原理层面的理解不会直接反映在命令输入效率上但对问题排查会有决断性的帮助。最后一定不能少的是手动搭建一套完整环境。比如亲手装一个LNMP环境配置虚拟主机、数据库、日志轮转、防火墙规则再模拟几次故障演练排查。整个过程走一遍之后你对Linux的理解会从碎片化命令库转变为一个系统化操作系统后续无论维护哪台服务器、排查什么问题心里都会有一个底色。我个人在这条路上走下来的最大体会是Linux并没有多神秘它就是一套以文件、权限、进程、网络为核心要素的逻辑学会的关键在于多用、多踩坑、多总结。把每天的异常都当作一次学习机会一段时间下来你就能从新手变成一个遇到故障能稳住心态的老手。