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远高于正常值比如机械盘超过100msSSD超过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_range1024 65535。但更重要的是找根因——为什么会有这么多短连接是连接池配置不合理还是上游服务的keep-alive没生效客户端没有复用连接每次请求都新建TCP这才是病根。2.3 排查方法论的沉淀做完这两道题你会发现它们都有一个共同点题目本身不难难的是你的排查路径是否清晰。我在实际带人时反复强调一个观点——排障不要跳步。有些人凭感觉直接重启服务运气好恢复了但下次还会踩同样的坑而按链路一步步排查虽然慢一点但每次都能沉淀出真正的根因。这里分享一个我常用的排障口诀先看资源再看进程然后日志最后代码。资源是CPU、内存、磁盘I/O、网络进程是谁在消耗资源日志是系统和业务的直接输出代码是最终兜底的根因所在。大多数问题走到日志这一步就能定位真正需要翻代码的其实不多。3. 服务部署与容器化从Systemd到Kubernetes的一组进阶题3.1 Systemd管理服务的隐藏考点传统运维向云原生转型的过程中Systemd依然是每台机器上最后一道防线。我经常拿这道题来考题目你写了一个systemd service单元执行systemctl start demo后提示失败systemctl status demo显示codeexited, status1/FAILURE。请描述你的排查流程。如果只会systemctl restart然后反复试这道题就丢了。正确做法是journalctl -u demo -n 50 --no-pager看服务日志这是最直接的线索。确认ExecStart里的命令路径是否正确很多时候是脚本里的相对路径在当前工作目录下找不到文件导致启动失败。所以systemd里最好用绝对路径必要时设置WorkingDirectory。检查User和Group指定的运行用户是否有对应目录和文件的权限。注意Type的设置——如果服务是forking类型但主进程没有正确fork并退出systemd会一直等不到通知而判定超时失败。有一回我排查一个Java服务的启动失败journalctl里没有任何Java报错折腾了半天才发现是LimitNOFILE65535没设置进程启动时文件描述符不够消息直接打到系统日志里去了。这种问题没有排查链路的话很容易卡住。3.2 Kubernetes与containerd从原理到调用的实体链路容器编排是热度非常高的运维方向。关于Kubernetes如何调用containerd很多人只停留在“Kubelet通过CRI调用containerd”这句话上但面试时往往需要你讲得更实。我在日常运维中用一张链路图去理解这件事kube-apiserver → kubelet → CRI插件containerd的cri插件→ containerd → runckubelet通过gRPC调用containerd的CRIContainer 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设置restartalways策略容器启动后从宿主机访问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) THRESHOLD80 REPORT/tmp/disk_check_report.txt $REPORT for SERVER in ${SERVERS[]}; do echo $SERVER $REPORT ssh $SERVER df -h | awk NR1 || \$50 $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: namenginx statepresent - name: 分发配置文件 template: srcnginx.conf.j2 dest/etc/nginx/nginx.conf notify: reload nginx - name: 启动Nginx并设置开机自启 service: namenginx statestarted enabledyes handlers: - name: reload nginx service: namenginx statereloadedAnsible的核心价值在于“声明式”——你描述最终状态工具负责幂等执行。这跟写脚本“一步一步怎么做”的思路完全不同。我见过不少从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%”最后沉淀经验教训。这样写出来的项目总结才是一个资深工程师的水平而不是流水账。写在最后的体会做运维这些年一个很深的感受是这行没有“学完”的那天。Linux内核在变容器编排在变监控体系在变今天掌握的技能明天可能就成了基础课。所以这份“综合练习卷二”与其说是一份考卷不如说是一个自我检视的镜子——你哪一块薄弱哪一块熟练一测便知。我个人的经验是每半年给自己出一次这样的综合练习题题目不一定要多难但一定要贴近实际工作场景。做完之后把错题整理成笔记下次再翻看你会发现自己是真的在成长。运维这条路很长但基本功扎实的人走到哪里都不会慌。
运维工程师能力自测：从Linux排障到Kubernetes高可用架构
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远高于正常值比如机械盘超过100msSSD超过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_range1024 65535。但更重要的是找根因——为什么会有这么多短连接是连接池配置不合理还是上游服务的keep-alive没生效客户端没有复用连接每次请求都新建TCP这才是病根。2.3 排查方法论的沉淀做完这两道题你会发现它们都有一个共同点题目本身不难难的是你的排查路径是否清晰。我在实际带人时反复强调一个观点——排障不要跳步。有些人凭感觉直接重启服务运气好恢复了但下次还会踩同样的坑而按链路一步步排查虽然慢一点但每次都能沉淀出真正的根因。这里分享一个我常用的排障口诀先看资源再看进程然后日志最后代码。资源是CPU、内存、磁盘I/O、网络进程是谁在消耗资源日志是系统和业务的直接输出代码是最终兜底的根因所在。大多数问题走到日志这一步就能定位真正需要翻代码的其实不多。3. 服务部署与容器化从Systemd到Kubernetes的一组进阶题3.1 Systemd管理服务的隐藏考点传统运维向云原生转型的过程中Systemd依然是每台机器上最后一道防线。我经常拿这道题来考题目你写了一个systemd service单元执行systemctl start demo后提示失败systemctl status demo显示codeexited, status1/FAILURE。请描述你的排查流程。如果只会systemctl restart然后反复试这道题就丢了。正确做法是journalctl -u demo -n 50 --no-pager看服务日志这是最直接的线索。确认ExecStart里的命令路径是否正确很多时候是脚本里的相对路径在当前工作目录下找不到文件导致启动失败。所以systemd里最好用绝对路径必要时设置WorkingDirectory。检查User和Group指定的运行用户是否有对应目录和文件的权限。注意Type的设置——如果服务是forking类型但主进程没有正确fork并退出systemd会一直等不到通知而判定超时失败。有一回我排查一个Java服务的启动失败journalctl里没有任何Java报错折腾了半天才发现是LimitNOFILE65535没设置进程启动时文件描述符不够消息直接打到系统日志里去了。这种问题没有排查链路的话很容易卡住。3.2 Kubernetes与containerd从原理到调用的实体链路容器编排是热度非常高的运维方向。关于Kubernetes如何调用containerd很多人只停留在“Kubelet通过CRI调用containerd”这句话上但面试时往往需要你讲得更实。我在日常运维中用一张链路图去理解这件事kube-apiserver → kubelet → CRI插件containerd的cri插件→ containerd → runckubelet通过gRPC调用containerd的CRIContainer 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设置restartalways策略容器启动后从宿主机访问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) THRESHOLD80 REPORT/tmp/disk_check_report.txt $REPORT for SERVER in ${SERVERS[]}; do echo $SERVER $REPORT ssh $SERVER df -h | awk NR1 || \$50 $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: namenginx statepresent - name: 分发配置文件 template: srcnginx.conf.j2 dest/etc/nginx/nginx.conf notify: reload nginx - name: 启动Nginx并设置开机自启 service: namenginx statestarted enabledyes handlers: - name: reload nginx service: namenginx statereloadedAnsible的核心价值在于“声明式”——你描述最终状态工具负责幂等执行。这跟写脚本“一步一步怎么做”的思路完全不同。我见过不少从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%”最后沉淀经验教训。这样写出来的项目总结才是一个资深工程师的水平而不是流水账。写在最后的体会做运维这些年一个很深的感受是这行没有“学完”的那天。Linux内核在变容器编排在变监控体系在变今天掌握的技能明天可能就成了基础课。所以这份“综合练习卷二”与其说是一份考卷不如说是一个自我检视的镜子——你哪一块薄弱哪一块熟练一测便知。我个人的经验是每半年给自己出一次这样的综合练习题题目不一定要多难但一定要贴近实际工作场景。做完之后把错题整理成笔记下次再翻看你会发现自己是真的在成长。运维这条路很长但基本功扎实的人走到哪里都不会慌。