一、运维这个岗位到底在维护什么表面上看运维维护的是服务器、是业务、是系统的稳定性。但往深了说运维维护的是对操作系统底层的掌控力。云原生、容器化、自动化运维工具层出不穷但无论上层怎么变落到最后还是一台台运行着Linux内核的服务器。工具可以帮你屏蔽掉很多底层细节但不能帮你理解那些细节。一旦工具失效、自动化失灵、常规手段用尽的时候能依靠的就只有对Linux本身的理解。这种理解不是会敲几个命令而是懂它为什么这样运行。二、几个典型的基础不牢现场内存报警真的缺内存吗监控系统频繁报警内存使用率超过95%。常见的处理方式是直接扩容。但在Linux的内存管理机制中空闲内存会被用来做文件缓存page cache目的是提高磁盘I/O性能。free -m命令输出中的buff/cache列往往占了很大比例。真正可用的内存要看available列。如果available还够用buff/cache又很高说明系统只是在利用空闲内存做缓存并不存在真正的内存压力。如果这时直接扩容是在为不存在的资源瓶颈买单。如果不清除这个认知盲区扩多少内存都解决不了问题还平白增加了成本。进程杀不掉问题出在哪kill -9是运维人员的最后一招。但有时候会发现kill -9都杀不掉的进程。用ps查看进程状态如果进程处于D状态不可中断睡眠意味着它正在等待I/O操作完成。这种状态下进程不响应任何信号kill -9也无能为力。根本原因通常是底层存储出了问题——NFS服务不可用、存储设备响应超时、磁盘硬件故障等。不解决存储层面的问题杀进程没有意义。而如果连D状态的含义都不清楚就会在为什么杀不掉这个问题上浪费大量时间。端口耗尽代码问题还是系统问题高并发场景下应用突然报错Cannot assign requested address。不懂网络协议栈的人会去查代码逻辑怀疑连接池泄漏。但问题可能出在TCP的TIME_WAIT状态上——大量短连接频繁建立和关闭导致本地端口被占用耗尽。这时候调整几个内核参数就能解决调整内核参数即可解决net.ipv4.ip_local_port_range 1024 65000 net.ipv4.tcp_tw_reuse 1 net.ipv4.tcp_fin_timeout 30但如果不懂TCP状态迁移、不懂端口范围限制、不懂TIME_WAIT的设计初衷根本不敢动这些参数也不知道动完之后会不会引发其他问题。文件句柄超限改配置就够了吗Too many open files是高频故障。网上查到的解决方案高度一致修改ulimit -n。照着做了重启了过几天又复现。再改大再重启再复现。问题在于Linux系统的文件描述符限制分多个层级系统级、进程级、用户级。Systemd管理的服务和直接在终端启动的进程读取配置的路径也不同。/etc/security/limits.conf对systemd服务无效必须在service文件中指定LimitNOFILE。只改一个地方解决不了问题。不搞清楚配置层级和加载顺序这个问题会反复出现。三、Linux基础的核心构成所谓基础不是命令列表而是三个层面的认知第一了解关键内核数据结构。/proc目录是了解Linux内核运行状态的窗口。ps读取的是/proc/[pid]/statfree读取的是/proc/meminfonetstat读取的是/proc/net/下的各类文件。知道了数据从哪里来就知道命令输出的每一列代表什么含义。第二理解四大核心模块的运行机理。进程管理进程状态模型运行、睡眠、停止、僵尸、调度策略、fork/exec机制内存管理虚拟地址空间、分页与分段、页缓存、swap、OOM Killer文件系统inode与文件名、软硬链接、文件描述符与引用计数、VFS抽象层网络子系统TCP/IP协议栈、socket编程接口、核心参数含义第三建立系统化的排障方法论。遇到故障时不急于重启遵循现象确认→信息收集→定位根因→修复验证的路径推进。每个步骤依赖的都是对操作系统行为的预判能力这种预判能力来自对上述机理的掌握。四、内核参数调优基础的外在体现内核参数调优是Linux基础最直接的试金石。/etc/sysctl.conf中的每一行配置背后都对应一个内核参数。调优不是网上有人这么配的复制粘贴而是建立在对业务特征和系统行为理解之上的决策vm.swappiness设置为多少取决于对内存与swap交换行为的认知net.core.somaxconn调大需要先理解SYN队列和Accept队列的工作方式kernel.pid_max的修改要对进程ID分配机制有概念不懂基础的调优是碰运气懂基础的调优是解决问题。五、对运维从业者的几点建议命令要学但不要止步于命令。每个命令都值得深挖一层——它读取了哪个文件输出了什么数据这些数据的单位是什么极限值受什么限制。多问几个为什么比多背十个命令有价值。经典书籍值得反复翻阅。《深入理解Linux内核》《Unix环境高级编程》《Linux系统编程》这些书不需要一次读完。每遇到一个问题去书里找对应章节读一遍带着问题读的效果远好于通读。重视每一次故障的根因分析。重启解决了和找到了根本原因解决了的区别在短期看差不多长期看是两种职业成长速度。记录故障、复盘根因、补充知识盲区是最好的学习路径。写在最后运维工作的本质是在复杂系统的混沌边缘维持秩序。要做到这一点工具和脚本是必要的辅助但底层操作系统才是真正的战场。容器可以屏蔽环境差异编排平台可以简化部署流程但这些上层建筑能稳定运行的前提是运维人员对地基有足够的了解。Linux基础从来不只是入门知识它是运维职业上限的决定因素。云原生时代基础的价值没有变低只是被重新强调了。容器归根结底是Linux进程加了隔离Kubernetes调度的是Linux节点上的资源服务网格依赖的是网络代理和系统调用。根基越深能处理的问题就越多能触碰的边界就越远。共勉。