运维实习第一阶段练什么？基础认知、操作规范与排查意识-平芜编程栈

1. 运维实习第一阶段到底在练什么

很多人对运维实习的想象还停留在“装系统、拉网线、重启服务器”这个层面，我带过几批实习生之后发现，真正拉开差距的从来不是谁会敲几条命令，而是第一阶段有没有把基础认知、操作规范、排查意识这三样东西扎下根。运维实习第一阶段，说白了就是从“会用电脑的人”往“能对线上环境负责的人”过渡的那段时间，通常集中在入职后的前两到四周。这个阶段你不会接触到特别核心的生产变更，但你会大量接触日常巡检、日志查看、服务状态确认、简单故障响应这些看似琐碎却极其关键的环节。

我之所以强调这个阶段重要，是因为运维这个工种有个很特殊的地方：它的能力曲线不是线性的。前期你学的东西看起来零散，Linux 命令、网络基础、脚本、监控指标，好像各管各的，但到了某个节点这些碎片会突然连成一张网，你就能独立判断“这台机器现在到底哪里不对劲”。而第一阶段的任务，就是尽可能多地把这张网的节点铺开，同时养成不闯祸的习惯。适合看这篇内容的人有三类：刚入行的运维实习生、准备转行做运维的开发者、以及带实习生但不知道怎么系统安排第一阶段任务的负责人。

先把结论摆在这儿：第一阶段的核心目标不是“学会多少工具”，而是建立三样东西——对环境的敬畏心、对现象的观察力、对操作的记录习惯。工具会过时，命令会忘，但这三样东西会跟着你整个职业生涯。下面我按实际带人的顺序，把这一阶段拆开讲透，包括每一步为什么这么做、怎么做、容易踩什么坑。

2. 第一阶段的能力地图与目标拆解

2.1 为什么先练“看”而不是先练“改”

新手最容易犯的毛病就是手痒，看到问题就想立刻动手改配置、重启服务。我见过一个实习生，发现某个服务响应慢，第一反应是直接重启，结果重启之后问题暂时消失，但根因被掩盖，第二天高峰期又炸了，而且这次连现场日志都被覆盖了。所以第一阶段我通常要求实习生先练“看”：看监控面板、看日志、看进程状态、看资源占用，把“描述现象”这件事做扎实。

“看”的本质是建立基线。你得先知道一个健康的系统长什么样，才能在它出问题的时候第一时间察觉。就像老中医看病，他脑子里有无数正常脉象的样本，一搭手就知道哪里不对。运维也一样，CPU 平时跑多少、内存水位线在哪、磁盘 IO 的日常波动范围是多少，这些基线数据必须刻进脑子里。第一阶段我会让实习生连续一周每天记录同一批机器的关键指标，不是为了记录而记录，而是让身体记住“正常”的感觉。

2.2 第一阶段该覆盖的四个能力块

把第一阶段拆开，我一般分成四块，按优先级排：

能力块	核心内容	达标标准	建议投入时间占比
系统基础	Linux 常用命令、文件权限、进程管理	能独立定位一个进程的完整信息	30%
网络基础	IP、端口、DNS、连通性排查	能用工具判断“通不通、慢不慢、卡在哪”	25%
监控与日志	指标含义、日志检索、告警识别	能读懂一条告警并说出可能原因	25%
操作规范	变更流程、记录习惯、回滚意识	每次操作前知道“改坏了怎么退”	20%

这个配比不是拍脑袋定的。系统基础和网络基础是地基，没有它们后面全是空中楼阁；监控和日志是运维的眼睛，第一阶段必须睁开；操作规范看着虚，但它决定了你未来会不会成为“事故制造机”。我特别把操作规范单独列出来，就是因为太多技术不错的新人栽在这上面——技术能力可以慢慢补，但一次不规范的操作可能直接让你失去接触生产环境的资格。

2.3 一个容易被忽略的目标：建立“求助边界”

第一阶段还有个隐性目标，就是搞清楚什么问题该自己扛、什么问题必须立刻上报。新手常走两个极端：要么什么都问，把导师当搜索引擎；要么什么都自己憋着，憋到问题扩大才说。我的建议是给自己划一条线：影响范围只涉及自己测试环境的，自己折腾；一旦涉及共享资源、生产环境、或者你判断不出影响范围的，立刻上报，同时带上你已经掌握的信息和你的初步判断。

这条线怎么划？我通常告诉实习生一个简单原则：只要你的操作可能影响到别人，就先说一声。这不是能力问题，是职业素养问题。第一阶段把这条边界感建立起来，后面带你的老同事会省心很多，也更愿意教你真东西。

3. 系统基础：从“会用”到“看得懂”

3.1 Linux 命令不在多，在于组合排查

网上那些“运维必会 100 个命令”的清单，看看就行，别当真去背。第一阶段真正要掌握的命令其实就二三十个，但要求是能组合起来解决一个具体问题。比如“这台机器 CPU 高”，你需要的是这样一条链路：

# 先看整体负载 top -bn1 | head -20 # 找到占用高的进程 PID 后，看它的详细信息 ps -ef | grep <PID> # 看这个进程打开了哪些文件 lsof -p <PID> # 看它的线程情况 top -H -p <PID>

这一套下来，你就能说清楚“是哪个进程、哪个线程、在干什么导致 CPU 高”。这比背一百个命令有用得多。我见过实习生能默写awk的各种用法，但真给他一台 CPU 飙高的机器，他愣是不知道从哪下手。原因就是他把命令当知识点背，而不是当工具用。

这里有个实操心得：每学一个新命令，就逼自己用它回答一个真实问题。学netstat就去看当前机器有哪些连接；学df就去查磁盘为什么满；学journalctl就去翻最近一次服务重启的日志。带着问题学，记忆深度完全不一样。

3.2 文件权限：别等出事才重视

权限这块，第一阶段必须搞明白三件事：属主属组、读写执行、以及特殊权限位。很多线上事故的根源就是权限给错了——要么该只读的给了写权限，要么脚本用了过高的权限运行。我让实习生做的第一个练习通常是：创建一个目录，让 A 用户能读写、B 用户只能读、其他人完全不能访问，然后用不同身份去验证。

# 创建测试目录 mkdir /tmp/perm_test # 设置属主和属组 chown userA:groupA /tmp/perm_test # 设置权限：属主读写执行，属组读执行，其他人无权限 chmod 750 /tmp/perm_test # 验证 ls -ld /tmp/perm_test

看起来简单，但真到线上环境，一个chmod 777就可能把敏感文件暴露出去。我个人的经验是：永远不要用 777，除非你在自己的临时测试目录里，而且用完立刻删掉。这条规矩我从入行守到现在，帮我避开了至少两次潜在的安全问题。

3.3 进程管理：理解“服务”到底是什么

新手对“服务”这个词往往很模糊。其实在 Linux 里，一个服务本质上就是一个长期运行的后台进程，加上一套管理它的机制。第一阶段要搞清楚的是：这个进程是谁启动的、以什么身份运行、它的配置文件在哪、日志输出到哪、怎么优雅地停掉它。

以常见的服务管理为例，你需要能回答：

这个服务的进程 ID 是多少，父进程是谁
它的启动参数是什么（ps -ef或cat /proc/<PID>/cmdline）
它监听了哪些端口（ss -tlnp）
它的日志在哪（通常在配置里指定，或者journalctl -u）
停止它应该用什么方式（信号量、管理命令、还是直接 kill）

我特别强调“优雅停止”这个概念。直接kill -9是最后手段，因为它不给进程清理现场的机会，可能导致数据损坏或状态不一致。第一阶段就要养成习惯：先尝试正常停止，观察日志确认它干净退出了，实在不行再考虑强制手段。

4. 网络基础：把“通不通”这件事说清楚

4.1 从一次“网站打不开”说起

假设有人报“网站打不开”，你怎么排查？第一阶段的目标就是能把这个问题拆成一条清晰的链路，然后逐段验证。这条链路大致是：客户端 → DNS 解析 → 网络连通 → 端口可达 → 服务响应 → 应用逻辑。

每一段都有对应的工具：

环节	工具	判断依据
DNS 解析	`dig`/`nslookup`	能否解析出正确 IP
网络连通	`ping`/`traceroute`	能否到达目标主机
端口可达	`telnet`/`nc`	目标端口是否开放
服务响应	`curl -v`	HTTP 状态码和响应头
应用逻辑	看服务日志	应用层报错信息

我让实习生做的经典练习是：故意把某个测试服务的端口改掉，然后让他从“打不开”这个现象出发，一步步定位到是端口变了。这个过程走一遍，比看十篇教程都管用。因为你会真实地感受到“每一层验证通过之后，问题范围就缩小一圈”的那种收敛感。

4.2 端口和防火墙：最容易背锅的两个点

端口不通是运维日常最高频的问题之一。第一阶段要建立的概念是：端口开放不等于服务在监听，服务在监听不等于防火墙放行。这三件事是独立的，要分别确认。

# 确认服务是否在监听 ss -tlnp | grep <端口> # 确认本机防火墙规则 iptables -L -n | grep <端口> # 从另一台机器测试连通性 nc -zv <目标IP> <端口>

我踩过的一个坑是：服务明明在监听，本机curl也通，但外部就是连不上，最后发现是中间还有一层安全组规则没放行。所以排查端口问题，一定要从两端同时看，不能只在一台机器上折腾。这个经验我后来总结成一句话：网络问题永远是“两端的事”，只盯一端等于没查。

4.3 DNS：那个让你“时好时坏”的隐形杀手

DNS 问题最恶心的地方在于它的间歇性。有时候能解析，有时候不能，有时候解析到旧 IP。第一阶段要理解的是：DNS 有缓存、有 TTL、有多个解析层级。你本地看到的解析结果，可能来自本地缓存、可能来自内网 DNS、也可能来自上游。

排查 DNS 问题的基本动作：

# 看本地解析配置 cat /etc/resolv.conf # 直接向指定 DNS 查询，绕过本地缓存 dig @<DNS服务器> <域名> # 看解析的完整链路 dig +trace <域名>

我的经验是：遇到“时好时坏”的解析问题，先怀疑缓存，再怀疑 TTL 设置，最后才怀疑 DNS 服务器本身。因为缓存问题最常见，也最容易验证——换个 DNS 直接查一次，结果不一样就说明是缓存的事。

5. 监控与日志：睁开运维的眼睛

5.1 读懂监控指标背后的“故事”

监控面板上的曲线不是装饰，每一条都在讲故事。第一阶段要能看懂四类核心指标：CPU、内存、磁盘、网络。但光看数字没用，要能说出“这个数字意味着什么”。

比如 CPU 使用率高，可能是计算密集、可能是等待 IO、也可能是被中断拖累。这时候要看更细的指标：

us（用户态）高：应用在算东西
sy（内核态）高：系统调用频繁，可能是 IO 或网络
wa（等待 IO）高：磁盘是瓶颈
si/hi（软硬中断）高：硬件或驱动层面有问题

我让实习生做的练习是：给一张 CPU 指标图，让他判断“这台机器在忙什么”。一开始大家都答不上来，练几次之后就能条件反射地说出“这是 IO 瓶颈”或者“这是应用在跑批处理”。这种判断力就是第一阶段最该练出来的东西。

5.2 日志检索：从“大海捞针”到“精准定位”

日志量大的时候，不会检索等于没有日志。第一阶段要掌握的核心是：按时间、按关键字、按上下文三个维度去捞。

# 按时间范围看日志 sed -n '/2024-01-01 10:00/,/2024-01-01 10:05/p' app.log # 按关键字过滤并显示上下文 grep -C 5 "ERROR" app.log # 统计错误出现的频率 grep "ERROR" app.log | awk '{print $4}' | sort | uniq -c | sort -rn

这里有个特别实用的技巧：先统计再细看。不要一上来就grep然后一行行读，先用统计命令看看错误集中在哪个时间段、哪类错误最多，然后再针对性地看上下文。这样效率能提高好几倍。我带人的时候，谁先学会这个思路，谁就能更快独立处理问题。

5.3 告警响应：第一反应决定后续走向

收到告警之后的第一反应，往往决定了这个问题是十分钟解决还是拖成事故。第一阶段要养成的习惯是：先确认告警真实性，再判断影响范围，最后才动手。

具体动作顺序：

看告警内容，确认是哪个指标、哪台机器、什么阈值
快速看一眼监控，确认是持续异常还是瞬时抖动
判断影响范围：单机还是集群、核心业务还是边缘服务
如果影响面大，立刻同步给相关人，不要自己闷头查
记录你看到的现象和你的判断，方便后续复盘

我见过太多新人收到告警就慌，上来就重启，结果把现场破坏了。其实很多告警是瞬时抖动，你观察两分钟它自己就恢复了。第一阶段练的就是这种“先稳住、再判断”的定力。

6. 操作规范：那些没人明说但极其重要的规矩

6.1 变更三问：改什么、影响谁、怎么退

任何一次操作之前，先问自己三个问题：

改什么：具体改哪个文件、哪个配置项、改成什么值
影响谁：这个改动会影响哪些服务、哪些用户、哪些上下游
怎么退：如果改坏了，怎么在最短时间内恢复原状

这三个问题答不上来，就不要动手。我个人的习惯是，哪怕只是改一个测试环境的配置，也会先把原文件备份一份，命名带上时间戳。这个习惯看着笨，但关键时刻能救命。

# 改配置前的标准动作 cp app.conf app.conf.bak.$(date +%Y%m%d%H%M%S) # 改完之后验证语法（如果支持） app --check-config # 再重启服务

6.2 记录习惯：写给未来的自己和同事

运维的操作记录不是形式主义。第一阶段我会要求实习生每次操作都记三样东西：做了什么、为什么做、结果如何。不用写得很正式，哪怕就是一段话，但必须写。

为什么这么强调记录？因为运维工作有很强的“上下文依赖”。你今天排查了一个问题，三天后同样的问题再出现，如果你当时记了，三分钟就能定位；如果没记，可能又要从头查一遍。而且记录还有一个隐性好处：它会逼你把思路理清楚。很多时候你写着写着就发现“咦，我好像漏了一步”。

我推荐一个简单的记录模板：

时间：2024-01-01 10:30 操作：重启了订单服务的测试实例 原因：日志显示连接池耗尽，怀疑是连接泄漏 结果：重启后恢复正常，但根因未定位，已记录待查 后续：明天看连接池监控，确认是否再次耗尽

6.3 回滚意识：永远给自己留后路

回滚不是失败，是专业。第一阶段就要建立“任何变更都要有回滚方案”的意识。回滚方案要具体到可执行，不能是“到时候再说”。

常见的回滚手段：

配置文件：备份原文件，改坏了直接覆盖回去
代码发布：保留上一个版本的包，随时可以切回
数据变更：操作前先备份数据，或者用事务保证可回退
服务重启：确认重启命令和停止命令都可用

我个人的经验是：回滚方案要在动手之前就想好，而不是出事之后才想。因为出事的时候人是慌的，慌的时候想出来的方案往往不靠谱。提前想好，写下来，出事的时候照着做就行。

7. 常见问题与排查技巧实录

7.1 第一阶段高频问题速查表

现象	可能原因	排查动作	避坑提示
服务起不来	端口被占、配置错误、权限不足	看启动日志、查端口、查权限	别急着重启，先看日志
磁盘满了	日志堆积、临时文件、大文件	`df -h`找分区，`du`找目录	别直接删，先确认文件用途
内存持续涨	内存泄漏、缓存未释放	看进程内存趋势、看缓存占用	别急着杀进程，先留现场
网络时通时断	DNS 缓存、网络抖动、连接数满	分段排查、看连接数	从两端同时看
告警误报	阈值不合理、瞬时抖动	看历史趋势、确认持续时间	先观察再动手

7.2 三个我踩过的坑，你别再踩

第一个坑：不看日志就重启。刚入行的时候，服务有问题我第一反应就是重启，觉得“重启能解决 90% 的问题”。后来有一次重启之后问题复现，但日志被覆盖了，查了半天查不出来。从那以后我养成了习惯：重启之前先把日志备份或者截图，哪怕问题暂时解决了，也要留证据。

第二个坑：在生产环境用rm -rf。这个不用多说，血的教训太多了。我的规矩是：任何删除操作，先把命令写出来，确认路径没错，再执行。而且能用mv到临时目录代替删除的，就不用rm。多占一点空间，换一份安心。

第三个坑：改配置不备份。有一次改一个服务的配置，改错了导致服务起不来，又没有备份，最后只能凭记忆恢复，折腾了一个多小时。从那以后，改任何配置文件之前，cp一份带时间戳的备份成了肌肉记忆。

7.3 排查问题的通用思路：从现象到根因

第一阶段最该掌握的排查方法论，我总结成四步：

描述现象：用一句话说清楚“什么时间、什么对象、什么表现”
缩小范围：通过分段验证，把问题锁定在某个环节
验证假设：针对怀疑的点，设计一个能证实或证伪的动作
记录结论：把根因和解决方式记下来，形成自己的知识库

这四步看着简单，但真正养成习惯需要刻意练习。我建议第一阶段每处理一个问题，都按这个框架写一遍复盘，哪怕只有几行字。坚持一个月，你的排查速度会有明显提升。

8. 第一阶段结束时的自检清单

带过几批实习生之后，我整理了一份第一阶段结束时的自检清单，你可以对照看看自己是否达标：

能独立登录一台 Linux 机器，完成基本的文件和进程操作
能说清楚一个服务从启动到提供服务的完整链路
能用工具判断“网络通不通、慢不慢、卡在哪”
能读懂常见监控指标，并说出异常时的可能原因
能从日志中定位到一次错误的关键上下文
每次操作前会问自己“改什么、影响谁、怎么退”
有记录操作和复盘的习惯
知道什么问题该自己处理、什么问题必须上报

这份清单不是考试，而是帮你查漏补缺。哪一项心里没底，就回去补哪一项。第一阶段不需要你成为专家，但需要你把地基打牢。

最后分享一个我个人的体会：运维这个工种，前期进步慢是正常的，因为你在积累的是“判断力”而不是“知识点”。知识点可以突击，判断力只能靠一次次真实场景的浸泡。第一阶段你可能觉得自己每天都在做琐碎的事，但正是这些琐碎的事在悄悄塑造你的职业直觉。等到某一天你面对一个从没见过的问题，却能凭直觉说出“先看这里”，你就知道第一阶段没白过。