服务器运维面试题库
生成时间：2026-05-22 22:17
【面试题】1. Nginx的upstream健康检查有哪几种方式？生产环境怎么选？
【标准答案】Nginx原生支持被动健康检查：max_fails设失败次数，fail_timeout设判定时间窗口，比如max_fails=3 fail_timeout=30s，30秒内连续3次失败就摘掉节点，30秒后再试。主动健康检查需要第三方模块nginx_upstream_check_module，可以配置check interval=3000 rise=2 fall=3 timeout=1000 type=http，每3秒主动探测，连续2次成功恢复、3次失败摘除。生产环境建议两者结合：被动检查兜底、主动检查快速感知。如果用商业版Nginx Plus，原生自带主动健康检查，配置health_check指令即可。另外也可以在应用层做：每个后端服务暴露/health接口，配合K8s的liveness/readiness probe或Consul的健康检查来做服务发现级别的摘除。
【面试题】2. Tomcat的NIO、APR、NIO2三种Connector线程模型有什么区别？怎么选？
【标准答案】BIO是传统模型一个请求一个线程，已淘汰。NIO基于Java NIO，用Poller线程轮询事件，少量线程处理大量连接，适合一般Web应用，是Tomcat 8.5+默认。APR用本地C库实现，通过JNI调用操作系统epoll，性能最高但需要安装APR库和tomcat-native，适合高并发生产环境。NIO2是Java 7的异步IO，回调驱动，理论上性能好但实际比NIO提升有限，适合IO密集场景。选型建议：普通应用用NIO够用；追求极致性能且能装APR就用APR；一般不推荐NIO2，收益不大还增加复杂度。配置方式就是在server.xml的Connector上设protocol="org.apache.coyote.http11.Http11NioProtocol"或Http11AprProtocol。
【面试题】3. Linux系统load average三个数分别代表什么？什么值算高？
【标准答案】load average三个数分别是1分钟、5分钟、15分钟内的平均负载，包含正在运行的进程+等待CPU的进程+等待IO的进程。关键点：它不是CPU使用率，而是系统队列长度。判断标准：单核CPU下load=1是满载，>1说明有进程在排队；多核CPU比如8核，load=8是满载。所以要看load值/CPU核数：低于0.7正常，0.7-1.0要关注，>1.0就有问题了。另外如果三个数呈递增趋势（1分钟>5分钟>15分钟），说明负载在上升；反过来在下降。load高但CPU idle也高，说明是IO瓶颈而非CPU瓶颈，这时候要查磁盘IO而不是CPU。排查用top看wa（IO wait）和vmstat看b列（阻塞进程数）。
【面试题】4. 如何排查Nginx 502 Bad Gateway错误？完整的排查思路是什么？
【标准答案】502说明Nginx作为代理收到了无效的上游响应。排查步骤：第一步看Nginx error.log，确认具体报错是connection refused还是upstream timeout还是empty response。第二步如果是connection refused，检查后端服务是否存活：curl直接访问后端端口，systemctl status看服务状态，netstat/ss看端口是否在监听。第三步如果后端活着但Nginx还是502，检查upstream配置的地址端口是否正确，proxy_pass是否指向了正确的upstream。第四步如果是upstream prematurely closed connection，可能是后端处理超时被kill了，查后端日志看OOM或超时。第五步检查Nginx和后端之间的防火墙/SELinux是否阻断。第六步如果是偶发502，可能是后端连接池满了，调大后端的连接数和Nginx的proxy_connect_timeout。预防层面：配置upstream健康检查做自动摘除，配置proxy_next_upstream让请求自动重试其他节点。
【面试题】5. Keepalived+Nginx高可用方案的工作原理是什么？脑裂问题怎么解决？
【标准答案】Keepalived基于VRRP协议实现VIP漂移。主节点持续发VRRP广播包，备节点监听，如果收不到就认为主挂了，备节点接管VIP。配合Nginx：主备都装Nginx+Keepalived，共享一个VIP对外服务，主节点挂了VIP漂到备节点，用户无感知。关键配置：vrrp_instance设state MASTER/BACKUP、priority主高于备、virtual_ipaddress设VIP，还要配vrrp_script检测Nginx进程，Nginx挂了就主动降低priority让出VIP。脑裂问题：主备之间网络不通但都活着，两边都持有VIP，造成IP冲突。解决方案：一是用仲裁机制，引入第三台机器或网关做仲裁；二是使用多播+单播混合模式，配置多个vrrp_instance做双主互为主备；三是配合监控脚本，检测到脑裂时自动shutdown一端的Keepalived；四是通过交换机层面做ARP限制。生产上最实用的是vrrp_script+Nginx检测+多网卡多通道冗余。
【面试题】6. iptables和firewalld有什么区别？生产环境用哪个？
【标准答案】iptables是传统的内核netfilter前端工具，直接操作四表五链（filter/nat/mangle/raw，INPUT/OUTPUT/FORWARD等），规则按顺序匹配，性能好但规则多了管理复杂。firewalld是CentOS 7+默认防火墙，底层还是netfilter，但引入了zone（区域）和service（服务）的概念，用XML配置，支持动态更新不用重载所有规则，用firewall-cmd管理。核心区别：iptables是静态规则，改了要iptables-restore整个重载；firewalld是动态的，运行时修改立即生效且不影响已有连接。firewalld还支持rich rule做更精细的控制。生产建议：新系统用firewalld，管理方便且动态生效；老系统或对性能极致要求的场景用iptables；Docker/K8s环境底层都走iptables，即使装了firewalld也要注意兼容性，Docker会直接操作iptables链。两者不要混用，systemctl stop firewalld后才能用iptables。
【面试题】7. Prometheus+Grafana监控体系中，如何设计告警规则避免告警风暴？
【标准答案】告警风暴是同一时间大量告警涌出，导致告警疲劳和遗漏。设计原则：第一，分级告警，P0紧急/P1重要/P2一般/P3提示，不同级别走不同通知渠道（P0电话、P1企微、P2邮件）。第二，for子句设持续时间，比如rate(http_errors[5m]) > 0.1 for 5m，连续5分钟才告警，避免毛刺误报。第三，分组group_by，按alertname或cluster分组，同组告警合并通知。第四，抑制inhibit_rules，节点down了就抑制该节点上的所有服务告警。第五，静默silences，维护期间提前设置静默窗口。第六，路由route做分级分发，不同业务/环境走不同接收者。第七，设置合理的重复间隔repeat_interval，已触发的告警不要频繁重复通知。第八，用阈值阶梯：warning和critical两级，warning走低优先级渠道，critical走高优先级。第九，配置sender告警聚合，一个通知里包含相关告警摘要。最后要定期review告警历史，删掉长期没人处理的噪音告警。
【面试题】8. Docker容器资源限制怎么配？OOM了怎么排查？
【标准答案】Docker通过cgroups限制容器资源：内存用-m或--memory，比如-m 512m限制最大512M；CPU用--cpus设核数或--cpu-shares设权重；磁盘IO可以用--device-write-bps限速。推荐用docker-compose的deploy.resources配置：limits设上限、reservations设保底。OOM排查步骤：第一步docker inspect看容器的OOMKilled字段是否为true。第二步docker logs看容器退出前的日志，通常会有java.lang.OutOfMemoryError或Cannot allocate memory。第三步docker stats看实时的内存使用趋势。第四步如果是Java应用，看JVM堆内存配置是否超过了容器内存限制，这是最常见的坑——JVM默认堆大小可能超过容器-m的限制，被系统OOM Kill。解决方案是JVM用-XX:MaxRAMPercentage=75.0代替-Xms/-Xmx硬编码。第五步docker events | grep oom查OOM事件记录。第六步进容器用top/ps看哪个进程内存异常。预防：设置--memory-swap等于--memory禁用swap，配合--oom-kill-disable=false（默认），让容器被OOM Kill而不是拖垮宿主机。
【面试题】9. 服务器遭遇DDoS攻击时，应急处理流程是什么？
【标准答案】DDoS应急分为发现、缓解、恢复三步。发现阶段：监控告警（流量突增、CPU飙升、连接数暴增）、Nginx日志出现大量相同IP或UA、系统load飙升但业务请求正常量不大。缓解阶段：第一，启用Nginx限流：limit_req_zone按IP限速，limit_conn_zone限制并发连接数。第二，封禁攻击源IP：通过日志分析提取TOP攻击IP，用iptables -A INPUT -s x.x.x.x -j DROP批量封禁，或写进Nginx的deny配置。第三，如果是大流量攻击，本机扛不住，立即联系云厂商启用DDoS高防（阿里云DDoS高防、腾讯云大禹），引流到清洗中心。第四，启用CDN做流量卸载，把静态资源请求挡在CDN层。第五，配置WAF规则拦截恶意请求特征。恢复阶段：攻击减弱后逐步解封正常IP，观察流量是否回落；事后分析攻击特征更新防护规则。长期防护：部署WAF+CDN+高防的纵深防御体系，Nginx层配置连接数限制和请求速率限制，启用fail2ban自动封禁异常IP，做DNS解析多地容灾。
【面试题】10. 动静分离架构怎么设计？Nginx怎么配置实现？
【标准答案】动静分离核心思想：静态资源（图片/CSS/JS/字体）由Nginx直接处理或CDN分发，动态请求转发给后端应用服务器。好处：减少应用服务器压力、静态资源可以充分利用CDN和浏览器缓存、动态请求和静态资源独立扩缩容。Nginx配置实现：第一，location用正则或前缀匹配静态文件后缀，比如location ~* .(jpg|png|css|js|woff2)$ { root /data/static; expires 30d; add_header Cache-Control "public, immutable"; }，静态文件直接从本地磁盘返回并设置长期缓存。第二，动态请求location / { proxy_pass http://backend; }，转发给Tomcat/Node等应用。第三，静态资源部署CDN：域名用static.example.com，DNS CNAME到CDN，Nginx做回源站。第四，进一步可以把静态资源放到对象存储（OSS/COS），Nginx通过proxy_pass回源到对象存储，或者直接CDN回源到OSS，完全不经过Nginx。第五，文件上传场景：用户上传走动态接口到应用服务器，应用处理完后存到OSS，返回CDN访问URL。第六，注意跨域配置：动静域名不同需要配CORS，Nginx加add_header Access-Control-Allow-Origin。生产上动静分离+CDN+OSS是标配方案，Nginx只做动态请求代理和静态资源的回源入口。