运维工程师能力自测：从Linux排障到Kubernetes高可用架构-Seo优化-塔城地区网站建设公司

1. 这份卷子的命题逻辑：运维工程师的核心能力模型

不少刚入行的朋友问我：“运维到底考什么？”说实话，这个问题比“怎么学运维”更难回答。因为运维岗位的覆盖面太宽了——从机房里的服务器硬件，到操作系统层面的调优，再到网络协议栈、容器编排、监控告警、自动化脚本，甚至项目汇报和文档沉淀，都在运维的工作半径之内。这也是为什么各家公司在招运维时，笔试题和面试题总有一种“什么都想考一点”的倾向。

这套“运维工程师综合练习卷二”，本质上不是一份标准答案集，而是一套能力自测框架。它的目标不是让你背会某几个命令，而是帮你检验自己面对真实生产环境时，能不能把“现象”翻译成“原因”，再把“原因”转化成“动作”。我见过太多简历写得很漂亮的人，一问到“系统负载高了你第一步做什么”就卡壳；也见过平时不显山不露水的同事，遇到故障时能冷静地按链路一步步把问题圈定。区别不在于谁记得的命令多，而在于谁脑子里有一套完整的排查模型。

如果给运维能力做一个分层，我的理解大致是这样的：

能力层次	核心内容	对应练习重点
L1 操作层	命令熟练度、工具使用、常规操作	能快速完成任务，不返工
L2 原理层	Linux/网络/存储等底层原理	知道命令背后发生了什么
L3 排障层	故障定位方法论、日志分析、链路追踪	面对未知问题有系统性思路
L4 架构层	高可用、容量规划、成本优化	能从全局视角设计运维方案

这套练习卷的题目设计，就是围绕这四个层次展开的。L1和L2是基础盘，考的是你的基本功扎不扎实；L3是分水岭，决定了你能不能独立扛事；L4则是从“运维工程师”向“高级运维/运维架构师”迈进的关键。

所以，如果你准备拿这份卷子自测，我的建议是：别急着看答案，先限时独立完成，再对照解析逐条检查。那些让你犹豫、卡顿、需要查资料的题目，才是你真正需要补的短板。

2. Linux系统与网络排障：绕不开的基础大题

2.1 从一条命令暴露出来的基本功

练习卷一上来，我通常先出这样一道题：

题目：生产服务器出现load average持续偏高（如 8.5, 7.9, 8.2），但CPU使用率只有30%，请问你的排查思路是什么？

这不是一道“背命令”的题，而是一道考察排查顺序的题。很多人的第一反应是top看一下，然后发现CPU不高就懵了。实际上，load average高的原因远不止CPU——它包含了CPU可运行队列和不可中断睡眠（D状态）进程的总和。也就是说，当进程在等待磁盘I/O、网络I/O或者锁的时候，同样会拉高load。

我的排查链路是这样的：

先跑top或uptime确认load值，然后按CPU排序看哪些进程在消耗资源。
重点查看D状态的进程——这是不可中断睡眠，通常是阻塞在I/O上。
用iostat -x 1看磁盘的%util和await，如果await远高于正常值（比如机械盘超过100ms，SSD超过20ms就该警惕），基本可以锁定磁盘瓶颈。
再用pidstat -d 1定位具体是哪个进程在做大量I/O。
如果是NFS或者网络存储，还要检查网络延迟和挂载参数。

这道题的“坑”在于：很多人盯住CPU不放，而忽略了I/O等待。实际上在真实生产环境里，磁盘I/O导致的load虚高，比CPU跑满更常见。

2.2 TCP连接状态异常：一次经典的网络排障模拟

再来看一道网络相关的题：

题目：业务反馈“系统变慢”，你登录服务器用ss -s看到大量TIME_WAIT连接，同时业务侧报“连接超时”。请分析可能的原因并给出处理方案。

这道题考的是对TCP连接状态机的理解。TIME_WAIT本身不是故障，它是TCP四次挥手后主动关闭方进入的状态，作用是确保最后一个ACK能够可靠到达。但大量TIME_WAIT累积，会导致本地端口被占用，连接数达到上限后，新连接就建立不起来了。

处理方向上，我一般分几步：

先确认TIME_WAIT的具体数量和系统限制：cat /proc/sys/net/ipv4/ip_local_port_range查看可用端口范围，ss -s看统计。
如果确认端口耗尽，最直接的措施是开启net.ipv4.tcp_tw_reuse（注意：tcp_tw_recycle已经因为NAT场景下的问题被废弃了，别再用了），让内核在安全条件下复用TIME_WAIT连接。
同时调大端口范围：sysctl -w net.ipv4.ip_local_port_range="1024 65535"。
但更重要的是找根因——为什么会有这么多短连接？是连接池配置不合理？还是上游服务的keep-alive没生效？客户端没有复用连接，每次请求都新建TCP，这才是病根。

2.3 排查方法论的沉淀

做完这两道题，你会发现它们都有一个共同点：题目本身不难，难的是你的排查路径是否清晰。我在实际带人时反复强调一个观点——排障不要跳步。有些人凭感觉直接重启服务，运气好恢复了，但下次还会踩同样的坑；而按链路一步步排查，虽然慢一点，但每次都能沉淀出真正的根因。

这里分享一个我常用的排障口诀：先看资源，再看进程，然后日志，最后代码。资源是CPU、内存、磁盘I/O、网络；进程是谁在消耗资源；日志是系统和业务的直接输出；代码是最终兜底的根因所在。大多数问题走到日志这一步就能定位，真正需要翻代码的其实不多。

3. 服务部署与容器化：从Systemd到Kubernetes的一组进阶题

3.1 Systemd管理服务的隐藏考点

传统运维向云原生转型的过程中，Systemd依然是每台机器上最后一道防线。我经常拿这道题来考：

题目：你写了一个systemd service单元，执行systemctl start demo后提示失败，systemctl status demo显示code=exited, status=1/FAILURE。请描述你的排查流程。

如果只会systemctl restart然后反复试，这道题就丢了。正确做法是：

journalctl -u demo -n 50 --no-pager看服务日志，这是最直接的线索。
确认ExecStart里的命令路径是否正确，很多时候是脚本里的相对路径在当前工作目录下找不到文件，导致启动失败。所以systemd里最好用绝对路径，必要时设置WorkingDirectory=。
检查User=和Group=指定的运行用户是否有对应目录和文件的权限。
注意Type=的设置——如果服务是forking类型，但主进程没有正确fork并退出，systemd会一直等不到通知而判定超时失败。

有一回我排查一个Java服务的启动失败，journalctl里没有任何Java报错，折腾了半天才发现是LimitNOFILE=65535没设置，进程启动时文件描述符不够，消息直接打到系统日志里去了。这种问题，没有排查链路的话很容易卡住。

3.2 Kubernetes与containerd：从原理到调用的实体链路

容器编排是热度非常高的运维方向。关于Kubernetes如何调用containerd，很多人只停留在“Kubelet通过CRI调用containerd”这句话上，但面试时往往需要你讲得更实。

我在日常运维中，用一张链路图去理解这件事：

kube-apiserver → kubelet → CRI插件（containerd的cri插件）→ containerd → runc

kubelet通过gRPC调用containerd的CRI（Container Runtime Interface）服务，containerd内部再通过runc来真正创建和运行容器。你要是用crictl ps、crictl logs这些命令来操作容器，其实就是在和containerd的CRI接口对话。

实际运维中，最常碰到的问题是：kubectl get nodes显示NotReady，或者Pod一直处于ContainerCreating。这时候别慌，拿crictl ps -a和journalctl -u kubelet -f两条命令去定位，基本都能找到原因。常见的情况有：

containerd服务挂了：systemctl status containerd直接看服务状态。
containerd的sandbox镜像拉不下来：Pod创建时第一步要先拉起pause容器，如果pause镜像拉取失败，Pod会一直卡在ContainerCreating。处理办法是提前把镜像导入到节点上，或者配置好镜像加速器。
CRI接口超时：检查kubelet和containerd之间的gRPC连接，有时候是磁盘I/O太慢导致镜像解包超时。

3.3 一组完整的部署实操题

下面这道题综合了服务部署、容器化和故障排查，适合作为卷二的实践压轴：

题目：请用Docker部署一个Nginx容器，要求：

将宿主机的80端口映射到容器的8080端口；
挂载宿主机/opt/www目录到容器/usr/share/nginx/html；
设置restart=always策略；
容器启动后，从宿主机访问http://localhost能看到自定义页面。

看似简单，但涉及到几个关键点。第一是端口映射方向别搞反了，-p 宿主机端口:容器端口，所以这里应该是-p 80:8080。第二是Nginx容器默认监听80端口，如果要把容器端口设为8080，需要改Nginx配置或者指定其他方式，实际上更常见的做法是-p 80:80，因为容器内的Nginx监听的是80。所以这道题如果想按原样实现，得在镜像里改配置，这考的就是你对容器端口和宿主机端口映射关系的理解。

我在考这道题时，真正想看的不是命令背得熟不熟，而是遇到“容器起来了但访问不通”时，能不能按这个顺序排查：

先在宿主机上curl localhost，如果通，说明容器和宿主机的链路没问题。
再进容器内部curl localhost，如果容器内不通，说明Nginx配置有问题。
如果容器内通、宿主机不通，检查端口映射和防火墙。
如果宿主机通、外部不通，查云安全组或者硬件防火墙。

这套“由内向外、逐层缩小范围”的思路，比任何一个具体命令都值钱。

4. 监控与高可用：用一道架构题检验全局视野

4.1 监控指标设计：你会怎么选监控项？

高可用不是靠口号喊出来的，而是靠监控发现苗头、靠预案快速响应。练习卷里我通常会给一题设计题：

题目：请为一个由Nginx + MySQL + 业务Java服务组成的三层架构，设计一套最小化的监控指标体系。

很多人的第一反应是“CPU、内存、磁盘、网络”——这没错，但太基础了。真正有价值的监控指标，要能从“它能帮你发现什么故障”的角度去反向推导：

组件	关键指标	为什么重要
Nginx	活跃连接数、5xx状态码比例、upstream响应时间	直接反映入口流量和服务健康度
Java服务	JVM堆内存使用率、GC暂停时间、线程池活跃线程数	很多故障在CPU飙高之前，GC和线程池就已经异常了
MySQL	慢查询数、连接数、InnoDB缓冲池命中率	数据库往往是整个系统里最先出问题的环节
宿主机	CPU负载、磁盘I/O等待、文件系统使用率	底层资源是服务稳定的前提

这里我想特别强调一点：监控不是越多越好。我曾经见过一个团队，接了上千个监控项，告警风暴每天轰炸，到最后大家直接把通知群屏蔽了。这是典型的“监控过载”导致“监控失效”。核心指标宁可少而精，每个指标都要能直接关联到一个明确的故障场景。

4.2 告警规则设计的“避免狼来了”原则

设计完监控项，下一步就是告警。练习卷里我常让学员继续回答：

问题：你设置了CPU使用率超过90%就告警，结果每天都收到几十条告警，但业务并没有受影响。你会怎么调整？

这就是典型的需要动态调整阈值的场景。我的做法是：

先看这个告警的“有效命中率”——触发告警的事件里，真正导致业务受损的比例有多大。如果小于10%，说明阈值定得太敏感了。
调整思路不是简单地把阈值从90%改成95%，而是引入“持续时间”的条件。比如CPU超过90%持续5分钟才告警，这样就能过滤掉短时抖动。
还要区分“工作负载型高CPU”和“异常型高CPU”。像计算密集型的业务，CPU长时间在85%以上运行可能是常态，这时候要告警的是“达到100%并且持续不降”，而不是“超过90%”。

告警规则是运维工作里最需要“动态迭代”的部分，没有一套规则能一劳永逸，需要在每次故障后复盘，不断校准。

4.3 高可用方案的设计思路

最后是一道开放性的大题：

题目：业务要求实现99.9%的可用性，请简述你的高可用架构设计思路。

这道题没有标准答案，但考察的逻辑链条很清晰。99.9%的可用性意味着一年不可用时间约8.76小时，这其实并不算特别苛刻的要求，但也不能靠“保证不出故障”来实现，而是靠“出故障后能快速恢复”来实现。

我的答题框架是三层：

第一层：消除单点。应用层至少部署两个实例，通过负载均衡分发流量；数据库做主从复制，或者使用云上的托管数据库。
第二层：故障自动转移。负载均衡要配置健康检查，发现后端不可用时能自动摘除；数据库主库故障时，切换脚本或中间件要能自动完成主从切换。
第三层：可观测性和预案。就算前两层都做了，还是要预留故障演练和应急预案，把“人肉操作”也变成流程的一部分。

这里最常犯的错误是只关注“架构高可用”，忽略了“人”的因素。比如半夜数据库宕机，从发现到切换，中间隔着告警通知、电话找人、登录确认、执行切换这几个环节，每个环节都可能耗时几分钟甚至更长。所以，真正的高可用一定要把“人的响应时间”也算进去。

5. 自动化与效率工具：把重复工作交给脚本是一门必修课

5.1 Shell脚本实操题：一键采集系统信息

自动化能力是运维工程师和“高级打杂”之间的分水岭。练习卷二里，我通常会出一道Shell编程题：

题目：写一个脚本，批量检查10台服务器的磁盘使用率，当某台服务器某个分区的使用率超过80%时，输出告警信息，并汇总到一份报告中。

这道题考察的知识点包括：远程命令执行（ssh）、循环、条件判断和文本处理。我的参考实现思路：

#!/bin/bash # 检查远端服务器磁盘使用率并汇总报告 SERVERS=("192.168.1.10" "192.168.1.11" "192.168.1.12") THRESHOLD=80 REPORT="/tmp/disk_check_report.txt" > "$REPORT" for SERVER in "${SERVERS[@]}"; do echo "===== $SERVER =====" >> "$REPORT" ssh "$SERVER" "df -h | awk 'NR==1 || \$5+0 >= $THRESHOLD {print \$0}'" >> "$REPORT" done cat "$REPORT"

这里有个细节容易踩坑：awk里引用Shell变量时，需要用\$5转义，否则本地Shell会先展开$5（在脚本里通常是空值），导致远程端拿到的条件判断错乱。我第一次写这个脚本时就被这个坑绊了一下，后来学会了把阈值作为变量传进去，用单引号包住awk命令体，再在需要的地方用'"$THRESHOLD"'方式拼接。

5.2 用Ansible替代脚本：从命令到编排

当服务器规模到几十台以上，纯Shell脚本的维护成本就会快速上升。这时候我会推荐用Ansible这类自动化工具。练习卷里会要求：

题目：使用Ansible编写一个Playbook，在10台Web服务器上完成Nginx的安装、配置、启动，并确保配置修改后能自动reload。

一个基础的Playbook大概是这样的思路：

- hosts: web_servers become: yes tasks: - name: 安装Nginx yum: name=nginx state=present - name: 分发配置文件 template: src=nginx.conf.j2 dest=/etc/nginx/nginx.conf notify: reload nginx - name: 启动Nginx并设置开机自启 service: name=nginx state=started enabled=yes handlers: - name: reload nginx service: name=nginx state=reloaded

Ansible的核心价值在于“声明式”——你描述最终状态，工具负责幂等执行。这跟写脚本“一步一步怎么做”的思路完全不同。我见过不少从Shell转Ansible的人，刚开始总想着在一个task里干好几件事，结果playbook写得跟shell脚本一样啰嗦。实际上，Ansible的每个task应该只做一件事，这样复用、排错、扩展都更容易。

5.3 日常运维效率工具清单

除了自动化框架，我整理了一份日常用得最多的效率工具清单，分享给备考的朋友参考：

批量操作：pssh / pdsh，比写for循环ssh更高效，支持并发。
日志排查：tail、grep、awk是老三样，补充一个jq，排查JSON格式日志时的效率立竿见影。
文本对比：diff、vimdiff，改配置文件前后对比，防止改错。
网络诊断：telnet测端口通不通，curl -v看HTTP交互细节，tcpdump做深度抓包分析。
压力测试：wrk测HTTP接口，ab做基础压测，sysbench测数据库性能。

我想强调的是：工具不在多，重要的是你能不能在问题现场想起来用哪个，以及用完之后能不能读懂输出。比如tcpdump抓包后，除了看IP和端口，你还要能看出TCP的握手有没有异常、重传多不多。工具只是眼睛，分析能力才是大脑。

6. 安全基线、备份恢复与文档沉淀：运维的“收尾能力”

6.1 安全基线检查：等保视角下的最小操作集

我这里说的安全，不是让你去做渗透测试，而是一名运维工程师必须做好的基础安全运维。练习卷里会考：

题目：你接手了一套生产环境，请列出你第一时间要检查的5项安全配置。

我的参考答案是：

SSH安全配置：是否允许root直接登录（建议禁用）、是否允许密码登录（建议改为密钥登录）、SSH端口是否被恶意扫描。最直接的操作：修改/etc/ssh/sshd_config，设置PermitRootLogin no和PasswordAuthentication no，同时配置防火墙只放行办公网IP连SSH。
防火墙规则：云平台安全组和系统层firewalld/iptables是否只开放了业务端口，数据库（3306、5432）和中间件端口是否有内网白名单限制。
服务运行用户：Nginx、MySQL、Java服务是否用独立低权限用户运行，而不是一把梭用root。
关键文件权限：/etc/shadow、配置文件里的数据库密码、证书私钥，权限是否收紧到了600或640。
更新与补丁：系统包更新策略是什么，是否有已知的高危漏洞需要紧急修复。

如果这套环境是公司要过等保测评的，那么还要补充：日志留存策略（至少6个月）、账号权限审计、密码复杂度策略等。但作为一个运维的“最小操作集”，上面5项是最基本的。

6.2 备份恢复演练：用演练找到备份方案的漏洞

备份这件事，没出故障时大家都觉得“备份了就行”，真到要恢复时才发现备份是坏的、恢复流程是断的，这种情况太常见了。所以练习卷二里我会出一道实操题：

题目：设计一套MySQL数据库的全量+增量备份方案，并要求说明恢复时如何操作。

一个务实的方案可以这么做：

全量备份：每天凌晨2点用mysqldump或xtrabackup做全量备份，备份文件保留7天。
增量备份：开启MySQL的binlog，通过解析binlog实现增量恢复，binlog保留至少3天。
备份验证：每天备份完成后，自动将备份文件恢复到一台测试实例上，执行几条查询确认数据可用。

恢复操作大概是：先把最近一次全量备份恢复到临时实例，再依次应用全量备份之后的binlog日志，直到恢复到故障前的时间点。

这里我想强调一个容易被忽略的点：备份一定要定期做恢复演练。我见过不止一次，备份文件是有了，但是因为磁盘空间不足、备份目录权限被改、或者mysqldump版本不匹配，恢复时根本跑不起来。最稳妥的办法是每月或每季度做一次完整的恢复演练，把恢复时间也记录下来，这样真到故障时，你心里是有底的。

6.3 运维文档：写不清楚=没做过

最后一个经常被忽略但重要的主题——文档。

我经常在项目总结的时候看到两类人：一类人项目做了很多事，但总结文档写不出来，东一块西一块，最后领导和同事都感受不到他的价值；另一类人文档写得条理清晰，问题背景、处理过程、最终结果、经验教训一目了然。

对运维来说，文档沉淀能力可以直接卡住你的职业发展。试想：半年后一个线上故障又出现了，你是翻历史聊天记录找解决方案，还是打开一份结构清晰的故障报告直接定位？

我的文档习惯是这样的：

维护手册：每一套系统都必须有一份维护手册，包含系统架构图、部署路径、配置文件清单、常用操作命令、监控看板入口、紧急联系人。
故障报告：每次P1/P2级故障都要写一份简要报告，包含故障现象、时间线、根因、处理措施、后续改进项。注意，故障报告的价值不在于“追责”，而在于让下次遇到类似问题时能快速处理。
变更记录：每次变更操作都要记录：变更时间、变更人、变更内容、回滚方案、验证结果。变更记录是排查“为什么线上突然变了”的第一手依据。

回到项目总结的场景。运维在项目总结里描述项目时，我建议的框架是：先交代项目背景和业务价值（比如“支撑XX业务上线”），再列关键工作内容（不要只写“运维保障”，要具体到“完成了XX套系统的架构升级”），然后用数据量化效果（比如“可用性从99.5%提升到99.95%”、“故障恢复时间缩短了60%”），最后沉淀经验教训。这样写出来的项目总结，才是一个资深工程师的水平，而不是流水账。