运维工程师笔试试题

运维工程师笔试试题请回答：b)`location/static/`块的作用是什么？`expires30d`指令的含义是什么？3.故障排查思路假设你负责维护的一个Web应用（部署在Linux服务器，使用Nginx+Tomcat架构，后端数据库为MySQL）突然出现访问缓慢的情况。请详细描述你的排查步骤和可能的解决方向。---四、综合应用题1.自动化运维场景设计假设你需要为公司内部的50台Linux服务器设计一套基础的自动化运维方案，主要目标包括：a)批量执行命令（如检查磁盘空间、内存使用情况）。b)批量部署和配置软件（如Nginx、Java）。c)监控服务器的关键指标（如CPU、内存、磁盘I/O、网络流量），并在指标异常时发送告警。请你：1)选择合适的自动化工具（可以是一种或多种工具组合），并说明选择理由。2)简述该方案的核心实现思路或架构。3)指出在实施过程中可能遇到的主要挑战及应对思路。---参考答案与评分标准（供考官参考）一、选择题1.B(top命令实时显示进程资源占用)2.C(IP协议负责路由选择)3.C(tee命令将输出同时定向到文件和标准输出)4.D(数据库查询优化主要是数据库管理员或开发人员的工作)5.C(Ansible是无代理架构)二、简答题(根据回答的完整性和准确性酌情给分)2.磁盘空间排查思路：*确认告警真实性，使用`df-h`查看整体磁盘使用率。*使用`du-sh/*`逐级排查大目录，定位到占用空间较大的具体目录或文件。*检查是否有大日志文件未轮转（`ls-lh/var/log/`）。*检查是否有临时文件未清理（`ls-lh/tmp/`）。*查看是否有被删除但仍被进程占用的文件（`lsof|grepdeleted`），此类文件需重启进程释放空间。*确认大文件是否为必要数据，若是日志或临时文件，可考虑安全删除或归档；若为业务数据，评估是否需要扩容。3.TCP三次握手：*第一次握手(SYN)：客户端发送一个SYN报文段（SYN=1，序列号seq=x）给服务器，请求建立连接。*第二次握手(SYN+ACK)：服务器收到SYN报文后，发送SYN+ACK报文段（SYN=1，ACK=1，序列号seq=y，确认号ack=x+1）进行确认。*第三次握手(ACK)：客户端收到SYN+ACK报文后，发送ACK报文段（ACK=1，序列号seq=x+1，确认号ack=y+1），服务器收到后连接建立。*主要目的：确保双方的发送和接收能力均正常，并协商初始序列号，为可靠的数据传输做准备，防止过期的连接请求报文段被服务端接收而建立错误的连接。4.无状态应用与有状态应用：*无状态应用：应用本身不存储会话数据或业务数据，每次请求都是独立的，不依赖于之前的请求。例如静态网站、API服务（如RESTfulAPI，不使用Session）。*有状态应用：应用需要存储会话数据或业务数据，后续请求依赖于之前的请求状态。例如使用Session的Web应用、数据库服务。*容器化部署数据持久化考量：*无状态应用：容器本身可以随时创建和销毁，数据通常存储在外部服务（如数据库、对象存储）。容器只需保证配置正确，无需特别的数据持久化措施（除非有临时缓存，可使用emptyDir）。*有状态应用：容器内产生的数据（如数据库数据文件、用户上传文件）需要持久化到宿主机或外部存储系统（如Docker的volume，Kubernetes的PersistentVolume），以防止容器重启或删除后数据丢失。同时需要考虑数据一致性、备份和恢复策略。5.Docker-v参数：*作用：用于将宿主机的目录或文件挂载到容器内部，实现宿主机与容器之间的数据共享和持久化存储。*举例：`dockerrun-d-v/host/path:/container/path--namemycontainernginx`此命令将宿主机的`/host/path`目录挂载到容器内的`/container/path`目录。三、分析与操作题(根据回答的完整性、准确性和思路清晰度酌情给分)1.Shell脚本分析与编写a)`grep-c'"404'access.log`或`awk'$9==404{count++}END{printcount}'access.log`b)`awk'{print$1}'access.log|sort|uniq-c|sort-nr|head-3`2.Nginx配置分析`expires30d`指令设置浏览器对该location下静态资源的缓存过期时间为30天，用于减少重复请求，提高访问速度和减轻服务器压力。3.故障排查思路(思路清晰、步骤合理即可)*初步判断：确认是普遍现象还是个别用户/区域问题（排除网络运营商或客户端问题）。*服务器基础状态检查：*CPU：`top`/`htop`/`mpstat`，是否有进程CPU占用过高。*内存：`free-m`/`vmstat`，是否内存不足导致频繁Swap。*磁盘I/O：`iostat`/`iotop`，检查磁盘读写是否繁忙，是否有大量随机IO。*网络：`iftop`/`netstat`/`ss`，检查网络带宽使用、连接数是否异常（如SYNFlood）。*应用服务层检查：*Nginx：检查`access.log`和`error.log`，是否有大量慢请求、错误日志；检查Nginx配置是否合理（如worker_processes,worker_connections）；`nginx-t`确认配置无语法错误。*Tomcat：检查Tomcat日志（catalina.out,localhost.log）是否有异常堆栈、OOM等；检查JVM参数配置（堆内存大小）是否合理；使用`jstack`/`jmap`等工具分析JVM线程状态和内存使用情况，看是否有线程阻塞、死锁或内存泄漏。*数据库层检查：*连接数：`showprocesslist;`查看是否有大量连接，是否有慢查询、锁等待。*慢查询日志：开启并分析慢查询日志，优化耗时SQL。*数据库性能：`explain`分析SQL执行计划；检查索引使用情况；表空间增长情况。*系统资源瓶颈定位：根据以上检查结果，确定瓶颈所在（CPU/内存/磁盘I/O/网络/应用代码/数据库）。*可能的解决方向：*资源瓶颈：升级硬件、增加服务器、优化资源分配。*应用问题：优化代码、调整JVM参数、重启服务。*数据库问题：优化SQL、添加索引、分库分表、读写分离。*配置问题：调整Nginx、Tomcat配置参数。*外部攻击：如DDoS，启用防火墙、CDN等防护。四、综合应用题(根据方案的合理性、可行性、技术选型的先进性和对挑战的认知程度酌情给分)1.自动化运维场景设计(方案合理、逻辑清晰即可)1)工具选择与理由：*批量执行与配置管理：Ansible。理由：无代理架构，部署简单；使用SSH协议，安全性高；基于YAML的Playbook易于编写和维护；模块丰富，社区活跃；支持幂等性操作。*监控与告警：Prometheus+Grafana。理由：Prometheus擅长时序数据收集和处理，适合监控指标；Grafana可视化能力强，可自定义仪表盘；支持丰富的告警规则；开源免费，易于扩展。*（可选）日志管理：ELKStack(Elasticsearch,Logstash,Kibana)或Loki+Grafana，用于集中收集和分析日志，辅助故障排查。2)核心实现思路/架构：*Ansible控制节点：部署Ansible，编写Playbooks和Roles，通过SSH连接到50台被管理节点。*批量执行命令：使用`ansible`ad-hoc命令或编写简单Playbook。*批量部署配置：通过Playbooks定义软件安装、配置文件模板、服务启停等步骤，实现标准化部署。*监控系统：*在各被管理节点部署PrometheusNodeExporter（或其他exporter）收集主机指标。*PrometheusServer定期从exporters拉取数据并存储。*Grafana连接Prometheus数据源，创建监控仪表盘。*配置PrometheusAlertmanager，设置告警规则（如CPU>80%，内存>90%），并通过邮件、短信或企业IM工具（如钉钉、Slack）发送告警。3)可能遇到的挑战及应对思路：*挑战1：服务器环境不一致（如操作系统版本、现有软件差异）。*应对：推行标准化操作系统镜像；在AnsiblePlaybook中做好条件判断和兼容性处理；对新纳入的服务器进行初始化标准化配置。*挑战2：权限与安全控制。*应对：Ansible使用SSH密钥认证，避免密码明文；为Ansible控制节点和被管理节点的SSH访问设置严格的防火墙策略；使用AnsibleVault加密敏感信息（如密码、密钥）；遵循最小权限原则分配执行账户权限。*挑战3：监控指标设计与告警阈值设定。*应对：结合业务特点和服务器性能基线，设计关键监控指标；告警阈值不宜过松或过紧，可逐步调整优化，避免告警风暴；设置多级告警和告警升级机制。*挑战4：工具学习曲线与团队接受度。*应对：提供内部培训和文档；从小规模试点开始，逐步推广；鼓励团队成员参与到Playbook和监控规则的编写中。*