运维常见考试试题及答案

运维常见考试试题及答案一、基础概念与理论1.问题：简述IT运维的核心目标及关键成功因素。答案：IT运维的核心目标是保障信息系统的稳定运行、提升资源使用效率、降低运维成本并支撑业务持续发展。关键成功因素包括：①建立标准化的运维流程（如变更管理、事件管理、问题管理）；②完善监控体系以实现故障预警和快速定位；③推动自动化运维减少人工干预；④构建高可用架构（如冗余部署、灾备方案）；⑤培养复合型运维团队（兼具技术深度与业务理解能力）；⑥持续优化资源配置（如服务器、网络、存储的动态调整）。2.问题：某系统SLA（服务级别协议）要求年度可用率不低于99.9%，计算该系统每年允许的最大停机时间（按365天计算）。答案：年度总时间=365天×24小时×60分钟=525600分钟。99.9%可用率对应的停机时间=525600×(1-99.9%)=525.6分钟≈8小时45.6分钟。因此，每年允许的最大停机时间不超过8小时46分钟（精确到分钟）。3.问题：CMDB（配置管理数据库）在运维中的核心作用是什么？列举至少5类常见的配置项（CI）。答案：CMDB的核心作用是记录IT基础设施的配置信息及其关联关系，为运维流程（如故障排查、变更影响分析）提供数据支撑，避免“信息孤岛”。常见配置项包括：服务器（物理机/虚拟机）、网络设备（交换机/路由器）、存储设备（磁盘阵列/云存储）、应用系统（Web服务/数据库）、IP地址（公网/内网）、域名、用户账号、软件版本、中间件（Tomcat/Nginx）、安全策略（防火墙规则/访问控制列表）。4.问题：简述ITIL框架中“事件管理”与“问题管理”的区别。答案：事件管理关注“已发生的故障或异常”的快速恢复（强调时效性），目标是最小化业务影响；问题管理关注“事件根本原因”的分析与解决（强调预防性），目标是通过消除根源减少同类事件重复发生。例如：服务器因内存耗尽宕机（事件管理需重启服务恢复业务），后续分析发现是应用内存泄漏（问题管理需修复代码或调整资源分配策略）。5.问题：简述运维自动化的三个发展阶段，并说明每个阶段的典型工具或技术。答案：①工具化阶段：使用单一工具解决特定问题（如用crontab定时任务、shell脚本执行备份）；②流程化阶段：通过工作流引擎串联多个工具（如用Jenkins实现“代码拉取-编译-部署-测试”流水线）；③智能化阶段：结合AI/机器学习实现自主决策（如用AIOps分析日志预测故障、自动调整资源）。二、Linux系统与操作6.问题：当前目录下有一个日志文件access.log，需要统计其中“2023-10-01”当天来自IP为00的访问次数，写出完整的命令组合。答案：grep"2023-10-01"access.log|grep"00"|wc-l。解析：第一步用grep过滤出当日日志，第二步进一步过滤目标IP，最后用wc-l统计行数（即访问次数）。7.问题：某服务进程占用CPU持续超过90%，需定位具体线程并分析原因，写出操作步骤及关键命令。答案：步骤①：用top命令查看进程PID（按P键按CPU排序）；步骤②：用top-H-p<PID>查看该进程下的所有线程（-H显示线程，-p指定进程），记录高CPU线程的TID；步骤③：将TID转换为十六进制（如TID=1234，转换为0x4d2）；步骤④：用jstack<PID>（Java进程）或gdb-p<PID>（C/C++进程）导出线程堆栈，搜索十六进制TID定位具体代码或函数；步骤⑤：结合代码逻辑分析是否存在死循环、资源竞争或低效算法。8.问题：将/opt/data目录的权限设置为“用户读写执行、组内用户读执行、其他用户无权限”，写出chmod命令及数字权限表示。答案：chmod750/opt/data。数字权限解释：用户（u）=rwx（7），组（g）=rx（5），其他（o）=（0）。9.问题：某服务器无法通过SSH连接（端口22），但能ping通，可能的原因有哪些？列出至少5项排查步骤。答案：可能原因：①SSH服务未启动（sshd进程崩溃）；②防火墙（iptables/ufw）阻止22端口；③SSH配置文件（/etc/ssh/sshd_config）修改后未重启服务；④服务器公网IP变化导致客户端连接目标错误；⑤SSH服务监听地址错误（如仅监听）；⑥客户端网络问题（如路由表错误、DNS解析异常）。排查步骤：①检查sshd进程状态（ps-ef|grepsshd或systemctlstatussshd）；②查看防火墙规则（iptables-L-n-v|grep22或ufwstatus）；③确认sshd_config中Port=22、ListenAddress=配置正确；④用telnet<IP>22测试端口是否可达；⑤检查服务器日志（/var/log/auth.log或/var/log/secure）是否有连接拒绝记录。10.问题：使用find命令查找/var/log目录下，7天前修改且大小超过100MB的日志文件，并将其压缩为.tar.gz格式，写出完整命令。答案：find/var/log-typef-mtime+7-size+100M-exectar-czvfold_logs.tar.gz{}+。解析：-typef限定普通文件，-mtime+7表示7天前修改（+7为超过7天，-7为7天内），-size+100M表示大于100MB，-exec执行tar命令，{}表示匹配的文件，+表示尽可能多的文件合并处理（相比;更高效）。三、监控与告警11.问题：在Zabbix中，如何配置一个触发器，监控某台Linux服务器的CPU使用率（平均值）超过80%持续5分钟后触发告警？写出关键配置步骤。答案：步骤①：确保服务器已安装ZabbixAgent，且配置了cpu.util（系统CPU利用率）监控项（类型为Zabbixagent，键值为system.cpu.util[,avg1]，收集1分钟平均值）；步骤②：进入“配置-主机-监控项”确认该监控项已正常获取数据；步骤③：创建触发器（“配置-触发器”），表达式设置为：{主机名:system.cpu.util[,avg1].avg(5m)}>80；步骤④：设置触发器严重程度（如“高”），并关联告警媒介（邮件/短信）；步骤⑤：测试：通过压力工具（如stress-c4）提升CPU使用率，验证是否在5分钟后触发告警。12.问题：Prometheus的Exporter有什么作用？列举3种常见Exporter及其监控对象。答案：Exporter是Prometheus的数据源适配器，负责将非Prometheus原生格式的指标（如Linux系统指标、数据库状态、中间件性能）转换为Prometheus可识别的文本格式（开放指标协议）。常见Exporter：①node_exporter（监控Linux/Windows服务器的CPU、内存、磁盘、网络）；②mysqld_exporter（监控MySQL的连接数、QPS、慢查询）；③redis_exporter（监控Redis的内存使用、客户端连接、持久化状态）；④blackbox_exporter（监控HTTP服务可用性、DNS解析时间、ICMP响应）。13.问题：某业务系统的监控图表显示内存使用率持续上升但未触发告警，可能的原因有哪些？答案：①告警阈值设置过高（如阈值为90%，当前使用率85%）；②监控指标采集周期过长（如每小时采集一次，未捕捉到峰值）；③内存泄漏导致使用率缓慢增长，未达到“持续时间”条件（如告警需持续10分钟，实际波动未满足）；④监控项配置错误（如采集的是“空闲内存”而非“使用内存”，导致图表显示反向）；⑤Exporter或Agent异常（如进程崩溃，数据未上报）；⑥Prometheus服务器时间与被监控主机不同步，导致数据聚合错误。14.问题：在Grafana中，如何基于Prometheus数据源创建一个“Nginx请求成功率”仪表盘？写出关键配置步骤。答案：步骤①：确认Prometheus已通过nginx-vts-exporter采集到指标（如nginx_vts_requests_total{status=~"2..|3.."}表示成功请求，status=~"4..|5.."}表示失败请求）；步骤②：在Grafana中添加Prometheus数据源；步骤③：新建仪表盘，添加图表（类型为“Timeseries”）；步骤④：在查询面板输入表达式：(sum(rate(nginx_vts_requests_total{status=~"2..|3.."}[5m]))/sum(rate(nginx_vts_requests_total[5m])))100；步骤⑤：设置Y轴单位为“百分比（%）”，添加阈值线（如99%为绿色，95%-99%为黄色，<95%为红色）；步骤⑥：配置图表标题（如“Nginx请求成功率（5分钟滚动）”），保存仪表盘。15.问题：简述日志集中管理的必要性，并说明ELK栈（Elasticsearch、Logstash、Kibana）各组件的作用。答案：必要性：分散的日志难以统一分析，集中管理可实现跨服务器/应用的关联查询、故障快速定位、安全审计及趋势分析。ELK组件作用：①Logstash：日志收集与处理（从文件、网络等来源采集日志，通过filter插件清洗、转换、丰富数据，如解析JSON、提取时间戳）；②Elasticsearch：分布式搜索引擎，存储结构化日志数据，支持快速查询与聚合分析；③Kibana：可视化工具，通过图表、仪表盘展示日志统计结果（如错误率趋势、TOP5慢接口）。四、故障排查与应急16.问题：用户反馈访问某电商网站首页缓慢（超过5秒），但后台管理系统访问正常，可能的故障原因有哪些？列出排查思路。答案：可能原因：①首页静态资源（图片、JS、CSS）未缓存或缓存失效，导致重复下载；②首页数据库查询复杂（如多表关联、缺少索引），响应时间长；③CDN节点故障，静态资源回源到源站，增加延迟；④首页引入第三方插件（如广告、统计代码）加载缓慢；⑤应用服务器（如Tomcat）线程池耗尽，无法及时处理请求；⑥首页对应的Nginx配置错误（如未开启gzip压缩、代理超时设置过短）。排查思路：①用ChromeDevTools（Network标签）分析首页加载各资源的耗时，定位慢资源；②检查数据库慢查询日志（如MySQL的slow_query_log），分析首页相关SQL是否需优化（加索引、拆分查询）；③登录CDN控制台查看节点健康状态及回源率；④禁用第三方插件后测试加载速度；⑤查看应用服务器日志（如catalina.out），检查是否有线程池满、内存溢出异常；⑥检查Nginx访问日志（记录$request_time），确认请求在Nginx层的处理时间。17.问题：某MySQL数据库主从同步中断，从库日志（relay-log）显示“Error1032:Can'tfindrecordintable”，可能的原因是什么？如何解决？答案：原因：主库执行了删除操作（DELETE），但从库对应记录已不存在（可能因从库误操作、主从数据不一致），导致从库无法应用二进制日志。解决步骤：①确认主从数据差异：在主库执行SELECTFROMtableWHEREid=XXX（XXX为报错中的记录ID），从库执行相同查询，确认是否存在记录；②临时跳过错误：在从库执行STOPSLAVE;SETGLOBALSQL_SLAVE_SKIP_COUNTER=1;STARTSLAVE;（仅适用于非关键操作，需谨慎）；③同步数据：若主库存在记录而从库不存在，从主库导出该记录（mysqldump-t-d--where="id=XXX"dbtable），在从库插入；④长期解决方案：检查主从数据一致性（用pt-table-checksum工具），避免从库手动修改数据，确保主库操作通过二进制日志同步。18.问题：某服务器突然无法访问外网（能ping通内网IP，但无法解析域名、无法访问80端口网站），可能的故障点有哪些？答案：①默认网关配置错误（route-n查看网关是否正确）；②DNS服务器不可用或配置错误（/etc/resolv.conf中的nameserver是否可达，用nslookup测试解析）；③防火墙规则阻止出站流量（iptables-L-n-v查看OUTPUT链是否有DROP规则）；④NAT表配置异常（iptables-tnat-L查看POSTROUTING链是否正常）；⑤网络接口状态异常（ifconfig或iplink查看网卡是否up，是否有丢包）；⑥运营商线路故障（通过traceroute查看跳点是否在某节点中断）；⑦病毒或恶意软件劫持网络连接（检查是否有异常进程占用网络端口）。19.问题：某K8s集群中，Pod持续处于“CrashLoopBackOff”状态，如何排查？答案：步骤①：查看Pod事件：kubectldescribepod<pod-name>，关注Events中的错误信息（如镜像拉取失败、容器启动命令错误）；步骤②：查看容器日志：kubectllogs<pod-name>（当前实例日志）或kubectllogs<pod-name>--previous（前一次崩溃日志）；步骤③：检查容器启动命令和参数：kubectlgetpod<pod-name>-oyaml，查看mand和args是否正确；步骤④：验证资源限制：检查spec.resources.limits（CPU/内存）是否过小导致OOMKilled（内存不足被杀死）；步骤⑤：测试容器健康检查：kubectlexec<pod-name>-<健康检查命令>（如curllocalhost:8080/health），确认是否返回200；步骤⑥：排查依赖服务：检查Pod是否依赖的ConfigMap、Secret未创建，或Service/Endpoint不可达（用nslookup<service-name>测试DNS解析）。20.问题：某Redis主节点宕机，哨兵（Sentinel）未自动切换到从节点，可能的原因有哪些？答案：①Sentinel配置错误：如sentinelmonitor<master-name><ip><port><quorum>中的quorum（法定人数）设置过大，导致无法达成故障转移共识；②Sentinel与主/从节点网络不通（用telnet测试Sentinel到主/从的端口是否可达）；③主节点宕机后，从节点未配置为可写（需确保从节点的slave-read-only=no，否则切换后无法接收写请求）；④Sentinel自身进程崩溃（ps-ef|grepsentinel检查是否存活）；⑤主节点假死（进程存在但无响应），Sentinel的down-after-milliseconds（判定主观下线的超时时间）设置过长，未及时触发客观下线；⑥从节点数据落后主节点过多（超过client-output-buffer-limit设置），Sentinel认为从节点不适合提升为主节点。五、云服务与自动化运维21.问题：阿里云ECS实例突然无法远程连接，控制台显示“实例运行中”，可能的原因有哪些？列出至少5项阿里云特有的排查点。答案：①安全组规则未放行远程端口（如SSH的22端口、RDP的3389端口）：检查实例所属安全组的入方向规则；②公网IP未绑定或EIP（弹性公网IP）释放：查看实例的公网IP是否存在，是否绑定了EIP；③NAT网关或EIP带宽超限：若通过NAT网关访问公网，检查网关的带宽是否耗尽；④实例被阿里云安全策略封禁（如触发DDoS攻击、恶意请求）：查看阿里云控制台的“安全中心”是否有拦截记录；⑤实例元数据服务（IMDS）配置错误：若依赖元数据获取认证信息，检查是否因配置错误导致服务异常；⑥VPC路由表配置错误：查看VPC的路由表是否有正确的默认路由指向Internet网关。22.问题：编写一个Ansible剧本（playbook），实现以下需求：在所有web服务器（组名为web_servers）上安装Nginx，配置自定义首页（内容为“WelcometoMySite”），并重启Nginx服务（确保开机自启）。答案：```yamlname:DeployNginxonwebservershosts:web_serversbecome:yes使用root权限tasks:name:InstallNginxpackage:name:nginxstate:present确保已安装name:Configurecustomindexpagecopy:content:"WelcometoMySite"dest:/usr/share/nginx/html/index.htmlmode:'0644'设置文件权限name:EnsureNginxisrunningandenabledservice:name:nginxstate:restarted重启服务使配置生效enabled:yes开机自启```解析：package模块根据系统自动选择yum/dpkg安装；copy模块直接提供首页文件（content指定内容，dest为目标路径）；service模块管理服务状态（state=restarted触发重启，enabled=yes设置开机启动）。23.问题：使用Docker部署一个SpringBoot应用（镜像名为myapp:v1），要求：①映射容器8080端口到主机80；②挂载主机/data/logs到容器/var/log/myapp；③限制容器CPU最大使用1核、内存512MB；④容器重启策略为“除非手动停止，否则始终重启”。写出完整的dockerrun命令。答案：dockerrun-d\--namemyapp\-p80:8080\-v/data/logs:/var/log/myapp\--cpus=1\--memory=512m\--restartunless-stopped\myapp:v1解析：-d后台运行；--name指定容器名；-p端口映射（主机80:容器8080）；-v卷挂载（主机路径:容器路径）；--cpus限制CPU核数；--memory限制内存大小；--restartunless-stopped设置重启策略。24.问题：在AWS中，如何实现EC2实例的高可用部署？列举关键步骤。答案：步骤①：创建VPC并划分多可用区（AZ）的子网（如us-east-1a、us-east-1b）；步骤②：创建自动扩展组（AutoScalingGroup，ASG），指定启动模板（包含EC2实例类型、AMI、安全组）；步骤③：配置ASG的扩展策略（如基于CPU使用率自动扩缩容），并设置最小/最大实例数（如最小2台，分布在不同AZ）；步骤④：创建弹性负载均衡器（ELB/ALB），将ASG关联到负载均衡器，实现流量分发；步骤⑤：配置健康检查（ALB定期检查实例状态，不健康实例自动替换）；步骤⑥：启用EBS卷快照或使用EFS（弹性文件系统）实现数据持久化，避免实例重建导致数据丢失。25.问题：简述GitLabC