运维工程师(服务器运维)岗位面试问题及答案.docxVIP

运维工程师(服务器运维)岗位面试问题及答案

Q1：请详细描述你排查Linux服务器CPU使用率持续90%以上的完整过程，需要说明具体工具、操作步骤及可能的根因分析方向。

A1：首先使用top命令观察整体CPU负载，重点关注%us（用户态）、%sy（内核态）、%wa（I/O等待）占比。若%us高，切换到线程视图（top-H）定位具体线程PID，通过pstack[PID]获取线程栈信息，结合应用日志分析是否存在死循环或低效算法；若%sy高，使用perftop分析内核态调用热点，可能是系统调用频繁（如大量短连接导致的socket操作）或驱动程序问题；%wa高时用iostat-x1查看磁盘I/O等待队列（await）和响应时间（svctm），通过iotop定位高I/O进程，检查是否有大量磁盘读写或未优化的数据库查询。

进一步用pidstat-u15监控进程CPU使用率变化，确认是否为周期性负载（如定时任务）。若进程为Java应用，使用jstack[PID]生成线程快照，结合JVM工具（如VisualVM）分析是否存在锁竞争或GC频繁（通过jstat-gcutil观察老年代回收频率）。对于C/C++程序，可用gdbattach[PID]查看运行上下文，或通过strace跟踪系统调用是否有阻塞。

根因可能包括：业务代码逻辑缺陷（如未正确关闭资源导致的文件句柄泄漏）、第三方组件配置不当（如Nginxworker_processes超过CPU核心数导致进程竞争）、数据库索引缺失引发全表扫描、缓存击穿导致大量请求穿透到数据库。曾处理过某电商大促期间CPU飙高问题，最终定位为Redis连接池配置过小，大量线程阻塞在连接等待，通过调大连接池并优化连接复用后恢复正常。

Q2：在生产环境中，发现Nginx反向代理的应用服务器响应延迟突然增加500ms，且错误日志出现502BadGateway，你会如何系统性排查？

A2：首先确认Nginx自身状态：通过nginx-t检查配置文件是否有语法错误（近期是否有配置变更）；使用netstat-anp|grepnginx查看连接数是否接近worker_connections上限；观察error.log中是否有upstreamtimedout或connectionrefused等具体错误。

其次分析上游应用服务器：通过ping/traceroute检查Nginx与应用服务器间网络连通性，使用mtr工具监控丢包和延迟；登录应用服务器查看负载（uptime/top）、内存使用（free-h）、网络流量（iftop），确认是否因应用服务器资源耗尽导致响应慢。若应用为Tomcat，检查catalina.out日志是否有OOM异常或线程池满（maxThreads配置）；若为PHP-FPM，查看www.log是否有reachedpm.max_children报错，导致无法创建新进程处理请求。

然后排查网络层面：使用tcpdump在Nginx和应用服务器两端抓包（tcpdump-ieth0port80-wdump.pcap），分析请求耗时（Wireshark中使用tcp.stream分析），确认延迟是发生在请求发送还是响应接收阶段。若发现大量重传包，可能是网络丢包或MTU不匹配（通过ping-Mdo-s1472测试MTU）。

最后检查负载均衡策略：若Nginx配置了ip_hash或least_conn，确认是否有后端节点异常（通过upstream模块的server状态监控，或访问Nginxstatus页面）。曾遇到过因应用服务器时间不同步导致SSL握手失败，Nginx反复重连上游服务器，最终通过ntpdate同步时间并配置自动校时解决。

Q3：请对比Ansible、Puppet、SaltStack在自动化运维中的适用场景，并说明你在实际项目中如何选择工具。

A3：三者均为配置管理工具，但实现机制和适用场景差异明显：

Ansible基于SSH协议，无代理模式（仅需目标节点安装Python），适合小规模、多异构环境（混合云/物理机）的临时任务执行或简单配置管理。其Playbook采用YAML语法，学习成本低，适合需要快速编写脚本的场景（如上线前的环境初始化）。

Puppet使用C/S架构，基于自定义DSL语言，强调声明式配置（描述最终状态），适合大规模同构环境（如数据中心内成百上千台标准化服务器）的持续配置管理。其强大的资源依赖管理和校验机制（如检查文件md5），适合对配置一致性要求高的场景（如数据库集群参数统一）。

SaltStack同样采用C/S架构，但支持Masterless模式，通信基于ZeroMQ消息队列，性能优于Puppet（尤其是批量操作时）。其支