运维或技术支持岗位招聘笔试题与参考答案(某大型央企)2025年

运维或技术支持岗位招聘笔试题与参考答案(某大型央企)2025年一、基础知识题（共30分）1.（5分）在Linux系统中，某业务进程CPU占用持续90%以上，但业务响应缓慢。请列出至少5种常用工具或命令，说明其在排查该问题中的作用。2.（5分）简述TCP三次握手与四次挥手的核心过程，并说明TIME_WAIT状态的作用及过多时的潜在风险。3.（5分）某MySQL数据库慢查询日志显示大量查询耗时超过2秒，日志中记录了SQL语句但未记录执行计划。请说明获取该SQL执行计划的方法及关键分析指标（至少3个）。4.（5分）使用Prometheus监控服务器时，若发现节点Exporter的disk_io指标缺失，可能的故障原因有哪些？请列出至少4种排查方向。5.（5分）某Nginx反向代理配置中，前端请求返回502BadGateway错误。请从Nginx配置、后端服务、网络连通性三个维度，列出可能的故障点（各维度至少2个）。6.（5分）简述容器化场景下（如Kubernetes）Pod的健康检查（LivenessProbe与ReadinessProbe）的区别及配置不当可能导致的问题。二、实操题（共40分）题目1（15分）：某生产环境CentOS7服务器突然无法远程登录（SSH连接超时），但本地控制台可登录。请基于以下信息完成排查与修复：服务器IP：192.168.10.50/24，网关192.168.10.1；本地执行`ping192.168.10.1`成功，`ping10.0.0.1`（公司总部IP）失败；`iptables-L`显示存在规则：`DROPall-192.168.10.0/2410.0.0.0/8`；`/var/log/secure`日志无异常SSH连接记录。要求：（1）写出排查步骤（至少5步）；（2）给出可能的故障原因及修复方法；（3）说明修复后需验证的内容。题目2（15分）：某微服务架构下，用户反馈调用`order-service`接口时偶发504GatewayTimeout错误，未出现规律性。现需通过日志与监控定位问题。已知：服务链路：用户→Nginx→API网关→order-service→mysql；监控指标：Nginx请求耗时（平均50ms）、API网关耗时（平均40ms）、order-service耗时（平均200ms，峰值1500ms）；日志：order-service的`application.log`中偶现`TimeoutException:Waitingfordatabaseconnection`。要求：（1）画出简要的故障排查逻辑图（文字描述即可）；（2）分析可能的根本原因（至少3个）；（3）提出临时缓解措施与长期优化建议。题目3（10分）：某央企数据中心需将业务从物理机迁移至私有云（OpenStack），要求迁移后业务中断时间≤30分钟。请设计迁移方案，包含以下关键点：迁移前准备（至少4项）；迁移实施步骤（至少5步）；迁移后验证（至少3项）。三、案例分析题（共20分）背景：某央企电商平台（日均PV5000万）即将迎来“双12”大促，运维团队需保障系统稳定性。大促前压测发现以下问题：1.主数据库（MySQL集群）QPS峰值达1.2万，慢查询占比5%，从库复制延迟最高3秒；2.商品详情页（前端静态资源+后端接口）加载耗时平均2.5秒，其中静态资源（图片、JS）占比60%；3.部分地区用户反馈打开页面时提示“网络错误”，但平台监控显示服务器可用性99.99%。问题：（1）针对数据库问题，提出优化策略（至少4条）；（2）针对前端加载耗时问题，给出具体优化方案（需结合CDN、缓存、资源压缩等技术）；（3）分析“部分地区用户网络错误”的可能原因（至少4个），并说明验证方法。四、综合题（共10分）某央企运维团队需制定《生产环境变更管理规范》，请列出该规范应包含的核心内容（至少8项），并说明每项内容的设计目的。参考答案一、基础知识题1.（5分）`top/htop`：实时查看进程CPU占用，定位高负载进程PID；`pidstat-t<PID>`：分析进程内线程CPU使用情况，定位具体线程；`strace-p<PID>`：追踪进程系统调用，识别是否存在I/O阻塞或资源竞争；`perftop`：分析CPU热点函数，定位代码层面性能瓶颈；`dstat`：综合监控CPU、内存、I/O等指标，判断是否为系统资源瓶颈。2.（5分）三次握手：客户端发送SYN=1，seq=x；服务端回复SYN=1，ACK=1，seq=y，ack=x+1；客户端发送ACK=1，seq=x+1，ack=y+1。四次挥手：客户端发送FIN=1，seq=u；服务端回复ACK=1，seq=v，ack=u+1；服务端发送FIN=1，ACK=1，seq=w，ack=u+1；客户端回复ACK=1，seq=u+1，ack=w+1。TIME_WAIT作用：确保最后一次ACK到达服务端，避免旧连接报文干扰新连接。风险：过多TIME_WAIT可能占满端口（默认65535），导致新连接无法建立。3.（5分）获取执行计划方法：在MySQL中执行`EXPLAIN[ANALYZE]+慢查询SQL`（需MySQL8.0+支持ANALYZE）。关键指标：`type`：访问类型（如const、ref、all），all表示全表扫描；`key`：实际使用的索引，无索引可能导致慢查询；`rows`：扫描的行数，数值越大性能越差；`Extra`：包含“Usingfilesort”（文件排序）或“Usingtemporary”（临时表）时需优化。4.（5分）可能原因：节点Exporter配置未启用disk_io采集（需检查`collectors.enabled`参数）；服务器内核未开启I/O统计功能（如`/sys/block`权限不足）；Exporter进程崩溃或端口被防火墙拦截（检查`netstat-tlnp`）；Prometheus服务器抓取配置错误（如IP、端口写错，或超时设置过短）；存储设备为虚拟盘（如云盘），底层不暴露disk_io指标。5.（5分）Nginx配置：`proxy_pass`指向的后端地址错误；`proxy_connect_timeout`设置过小；后端服务：后端进程崩溃（如JavaOOM）；后端端口未监听（`netstat-tlnp`无对应进程）；网络连通性：Nginx到后端的防火墙规则阻止（`telnet后端IP端口`失败）；路由表错误（`traceroute`跳数异常）。6.（5分）区别：LivenessProbe（存活检查）：判断Pod是否需要重启（如进程崩溃、死锁）；ReadinessProbe（就绪检查）：判断Pod是否可接收请求（如应用初始化未完成）。配置不当问题：Liveness超时或阈值过低：可能导致健康Pod被误重启，影响服务可用性；Readiness延迟配置过短：应用未完成初始化即接收请求，导致请求失败；探针接口未优化：高频调用可能增加应用负载，反向导致性能问题。二、实操题题目1（15分）（1）排查步骤：①检查服务器网络配置：`ipaddr`确认IP、子网掩码正确；`iproute`查看路由表是否包含到10.0.0.0/8的路由；②验证本地到外网的连通性：`ping8.8.8.8`判断是否为全局网络问题；③分析iptables规则：`iptables-L-n-v`查看DROP规则的匹配次数，确认是否为近期新增；④检查SSH服务状态：`systemctlstatussshd`确认服务是否运行；`ss-tlnp|grepsshd`确认22端口监听；⑤查看防火墙（firewalld）配置：`firewall-cmdlist-all`确认是否启用了额外的端口限制。（2）故障原因及修复：核心原因：iptables中存在DROP规则，阻止了192.168.10.0/24网段到10.0.0.0/8的流量（包括SSH连接可能通过该路由）；修复方法：临时删除规则`iptables-DINPUT-s192.168.10.0/24-d10.0.0.0/8-jDROP`；长期通过`iptables-save`持久化规则或迁移至firewalld管理。（3）验证内容：远程SSH登录是否恢复（从另一台192.168.10.0/24主机测试）；`ping10.0.0.1`是否成功；检查`/var/log/secure`是否记录新的SSH连接日志；确认iptables规则未自动恢复（重启服务器后验证）。题目2（15分）（1）排查逻辑图：用户504错误→检查Nginx日志（确认超时发生在哪个阶段）→API网关耗时正常→聚焦order-service耗时异常→结合order-service日志（数据库连接超时）→分析数据库连接池配置→检查MySQL负载（连接数、慢查询）→验证网络延迟（order-service到MySQL）。（2）可能原因：数据库连接池配置过小（如max_active=10），高并发时无可用连接；MySQL慢查询导致连接占用时间过长（如事务未及时提交）；数据库网络延迟高（如跨机房链路丢包），连接建立耗时增加；order-service代码中存在未关闭的数据库连接（连接泄漏），导致池耗尽。（3）临时缓解措施与长期优化：临时：调大数据库连接池参数（如max_active=50），设置连接超时时间（`connectionTimeout=3000ms`）；长期：优化慢查询（添加索引、拆分大事务）；引入连接池监控（如HikariCP的`metrics`）；对数据库进行读写分离，减少主库压力。题目3（10分）迁移方案：（1）迁移前准备：业务评估：梳理业务依赖（如数据库、缓存）、流量峰值、存储容量；环境适配：私有云网络（VPC、安全组）与物理机网络对齐；测试云主机性能（CPU、I/O）是否满足业务要求；备份与回滚：全量备份物理机数据（`rsync`或快照），准备回滚脚本（切换DNS指向原物理机）；停机窗口申请：与业务部门确认30分钟停机时间，通知用户维护计划。（2）迁移实施步骤：①业务停机：关闭物理机业务进程，确认无活跃连接（`netstat-ant|grep业务端口`）；②数据迁移：通过`scp`或云存储（如Swift）迁移应用代码、配置文件；数据库通过`mysqldump`或物理备份（如PerconaXtraBackup）迁移；③云主机部署：在OpenStack中启动云主机，安装依赖（JDK、Docker等），部署应用并配置相同IP（通过浮动IP绑定）；④连通性测试：验证云主机到数据库、缓存的网络连通性（`telnet`、`ping`）；⑤业务启动：启动云主机业务进程，检查日志无异常（如`tail-f/var/log/app.log`）。（3）迁移后验证：功能验证：通过冒烟测试（如下单、支付）确认业务功能正常；性能验证：压测工具（JMeter）模拟10%流量，确认响应时间与物理机一致；监控接入：将云主机纳入Prometheus监控，确认CPU、内存、磁盘指标正常；回滚验证：模拟回滚操作（切换DNS），确认30分钟内可恢复物理机业务。三、案例分析题（1）数据库优化策略：慢查询治理：通过`pt-query-digest`分析慢查询日志，为高频查询添加索引（如商品表`user_id`+`create_time`联合索引）；从库优化：增加从库数量（一主多从），分担读压力；调整`innodb_flush_log_at_trx_commit=2`（牺牲部分一致性提升性能）；复制延迟优化：启用并行复制（`slave_parallel_workers=8`），确保主从服务器配置一致（CPU、内存）；分库分表：对订单表按`user_id`哈希分库，降低单库数据量；引入缓存：高频读数据（如商品详情）通过Redis缓存，减少数据库访问。（2）前端加载优化方案：CDN加速：将静态资源（图片、JS、CSS）上传至CDN，配置边缘节点缓存（TTL=24h）；资源压缩：图片采用WebP格式（比JPG体积小25%），JS/CSS通过UglifyJS、CSSNano压缩；按需加载：非首屏资源（如底部广告JS）使用`async`或`defer`属性延迟加载；缓存策略：设置`Cache-Control:max-age=31536000`（1年）对静态资源强缓存，通过文件名哈希（如`app.abc123.js`）解决更新问题；服务端渲染（SSR）：对商品详情页采用SSR，减少前端JS渲染时间。（3）部分地区用户网络错误原因及验证：原因1：运营商链路故障（如某省IDC出口路由器宕机）；验证：通过`traceroute`工具从该地区用户机器测试到平台IP的路径；原因2：DNS解析异常（递归DNS返回错误IP）；验证：要求用户执行`n