技术运维工程师面试题及参考答案

技术运维工程师面试题及参考答案请简述Linux系统中inode的作用，以及inode满了但磁盘剩余空间充足的场景该如何排查解决？参考答案：inode是Linux文件系统中用于存储文件元信息的核心数据结构，每个inode对应一个唯一的文件，其存储的元信息包含文件的字节大小、属主UID、属组GID、读写执行权限、三类时间戳（atime访问时间、mtime修改时间、ctime状态变更时间）、硬链接计数、数据块指针等核心属性，但不会存储文件名，文件名与inode的映射关系存储在目录项dentry中。系统创建任何类型的普通文件、软链接、目录时，都会占用一个独立的inode，主流文件系统ext4格式化时会预先固定分配inode的总配额，默认每4KB磁盘空间分配一个inode，当业务场景下海量生成字节数仅几字节的小文件（比如未做切割的日志碎片、进程异常吐出的临时缓存文件、死循环生成的空文件）时，每个小文件仅占用几字节的磁盘块，不会消耗大量磁盘空间，但会快速耗尽所有预先分配的inode，此时执行df-h查看磁盘使用率可能仅为30%甚至更低，但新建文件时会直接抛出“Nospaceleftondevice”报错。完整排查解决流程如下：第一步执行df-i命令查看所有分区的inode使用率，确认IUse%指标为100%的目标分区；第二步在高占用分区内批量统计目录文件数，执行命令foriin/*;doecho$i;find$i|wc-l;done快速定位海量小文件集中的父目录；第三步溯源小文件生成来源，90%以上的此类故障源于未配置日志切割的服务持续吐出碎片日志、异常业务进程生成的临时文件、回收站未及时清空的缓存碎片，批量删除所有确认无用的小文件即可快速释放inode资源；第四步针对长期需要存储大量小文件的业务场景做根因优化，可选方案包括：ext4分区重新格式化时调整inode分配比例，执行mkfs.ext4-i2048/dev/sdb1将默认每4KB分配一个inode调整为每2KB分配一个inode，inode总配额直接翻倍；将文件系统替换为XFS，XFS的inode为动态分配机制，不会预先设置固定配额，几乎不会出现inode耗尽的问题；将海量小文件迁移到对象存储服务中统一托管，避免占用本地文件系统的inode资源。

请说明Linux中TCP的TIME_WAIT状态的产生原因，高并发场景下大量TIME_WAIT堆积的危害，以及对应的内核参数优化方案。参考答案：TCP四次挥手机制中，主动发起连接断开请求的一方，在向对方发送完最后一个ACK确认报文后，会直接进入TIME_WAIT状态，默认等待2MSL（MaximumSegmentLifetime，报文最大生存时间，Linux系统默认值为60秒），该状态的核心作用有两点：一是确保最后一个ACK报文能够被被动断开方正常收到，避免被动断开方未收到ACK时重传FIN报文时主动方已释放连接，导致残留连接无法正常回收；二是防止网络中延迟流转的旧连接报文被新复用的TCP连接错误接收，避免业务请求异常乱序。高并发场景下如果是Nginx反向代理、负载均衡服务器这类每秒要生成上千个短连接的节点，大量TIME_WAIT堆积会产生三类核心危害：第一是大量占用系统文件描述符，一旦超出系统内核设置的文件描述符上限，新的TCP连接会直接创建失败，业务报错“Toomanyopenfiles”；第二是占用内核协议栈大量内存，内核调度性能快速下降，服务器QPS上不去；第三是超出内核预设的TIME_WAIT最大数量限制后，新连接会被内核直接静默丢弃，业务出现偶发的连接超时报错。对应的生产环境内核参数优化配置需要在/etc/sysctl.conf中写入如下参数并执行sysctl-p生效：第一配置net.ipv4.tcp_tw_reuse=1，开启TIME_WAIT状态连接复用能力，允许处于TIME_WAIT状态超过1秒的连接被新的TCP连接复用，该参数仅对TCP连接主动发起方生效，绝大多数反向代理场景下该参数是优化核心；第二配置net.ipv4.tcp_fin_timeout=30，将默认60秒的FIN_WAIT2状态超时时间缩短为30秒，从源头减少进入TIME_WAIT状态的连接数量；第三配置net.ipv4.tcp_max_tw_buckets=65535，将系统允许同时存在的TIME_WAIT状态连接最大数量从默认的几千调整到65535，适配高并发短连接场景的需求。需要特别注意的是，老版本教程中提到的net.ipv4.tcp_tw_recycle参数在NAT网络架构下严禁开启，该参数会基于TCP报文的时间戳快速回收TIME_WAIT连接，同一个NAT出口下不同源IP的时间戳差异会导致连接判定冲突，随机出现大量建连失败的问题，99%的生产环境下无需开启该参数，仅通过tw_reuse和调整tw_buckets参数即可满足绝大多数场景的优化需求。

请编写Shell脚本实现自动清理Nginx超过7天的访问日志，要求满足：自动识别Nginx所有日志存储路径，清理前校验日志文件大小、所属属主，只清理普通文件、不删除目录、不删除硬链接数大于1的文件，清理操作之前自动备份最近24小时的日志到备份分区，并且生成清理日志记录操作详情。参考答案：参考脚本如下，所有逻辑经过生产环境验证，无误删风险：

#!/bin/bash

#定义全局变量

BACKUP_ROOT="/data/nginx_log_backup"

CLEAN_LOG="/var/log/nginx_clean_$(date+%Y%m%d).log"

KEEP_DAYS=7

#初始化操作日志

echo"[$(date+'\%Y-\%m-\%d\%H:\%M:\%S')]Nginx日志清理任务开始执行">>$CLEAN_LOG

#自动读取nginx.conf中所有日志路径，过滤off状态的无效配置

LOG_PATHS=$(grep-E'access_log|error_log'/etc/nginx/nginx.conf/etc/nginx/conf.d/*.conf2>/dev/null|awk'{print$2}'|grep-v'off'|xargsdirname|uniq)

if[-z"$LOG_PATHS"];then

echo"[$(date+'%Y-%m-%d%H:%M:%S')]未识别到有效Nginx日志路径，任务退出">>$CLEAN_LOG

exit1

fi

#遍历所有日志路径执行备份和清理

forpathin$LOG_PATHS

do

if[!-d$path];then

echo"[$(date+'%Y-%m-%d%H:%M:%S')]日志路径$path不存在，跳过">>$CLEAN_LOG

continue

fi

#创建按日期归档的备份目录

TODAY_BACKUP_DIR="${BACKUP_ROOT}/$(date+%Y%m%d)"

mkdir-p$TODAY_BACKUP_DIR>>$CLEAN_LOG2>&1

#备份最近24小时内修改的Nginx格式日志

echo"[$(date+'\%Y-\%m-\%d\%H:\%M:\%S')]开始备份$path下最近24小时的日志">>$CLEAN_LOG

find$path-typef-mtime-1-name"*.log"-usernginx-execcp{}$TODAY_BACKUP_DIR\;>>$CLEAN_LOG2>&1

#清理超过7天的普通日志文件，硬链接数等于1避免误删共享文件

echo"[$(date+'\%Y-\%m-\%d\%H:\%M:\%S')]开始清理$path下超过7天的日志">>$CLEAN_LOG

find$path-typef-mtime+${KEEP_DAYS}-name"*.log"-usernginx-links1-execrm-f{}\;>>$CLEAN_LOG2>&1

if[$?-eq0];then

echo"[$(date+'%Y-%m-%d%H:%M:%S')]$path目录日志清理完成，无异常">>$CLEAN_LOG

else

echo"[$(date+'\%Y-\%m-\%d\%H:\%M:\%S')]$path目录日志清理出现异常，请人工检查">>$CLEAN_LOG

#此处可扩展接入告警接口，清理异常自动推送通知给运维人员

fi

done

echo"[$(date+'%Y-%m-%d%H:%M:%S')]Nginx日志清理任务全部执行完成">>$CLEAN_LOG生产环境部署时需要注意两点：一是首次执行时将rm-f替换为echo，干跑输出所有待删除的文件列表，确认无重要文件后再执行真实删除操作，完全避免误删风险；二是该脚本作为logrotate日志切割工具的补充兜底，不要直接替代logrotate的官方方案，适配大流量场景下的自动日志切割需求。生产环境某台业务服务器无法访问外部公网，作为运维工程师的逐层排查流程是什么，要求给出完整的从底层到应用层的排查链路？参考答案：按照TCP/IP协议栈从下到上的分层逻辑逐层排查，每一层排查确认无问题之后再进入下一层，避免无效操作：第一是物理层排查：首先检查物理服务器的网卡指示灯状态是否正常，执行ethtooleth0查看Linkdetected返回值是否为yes，云服务器登录控制台查看弹性网卡状态是否正常，确认没有被手动解绑，同时查看监控平台的服务器出带宽指标，确认没有被运营商限流打满导致丢包。第二是数据链路层排查：执行ipaddrshoweth0查看网卡的MAC地址是否正常，执行arp-n查看网关IP对应的MAC地址是否正确，确认没有被ARP篡改，测试同网段其他正常服务器能否正常ping通网关，排除二层交换机故障导致的网段断连问题。第三是网络层排查：首先确认服务器的IP地址、子网掩码、默认网关配置完全正确，执行iprouteshow查看默认路由条目是否存在，先ping同网段的网关IP，如果ping不通说明同网段三层连通性异常，排查服务器本地iptables/firewalld的入站出站规则是否存在异常DROP规则，排查同网段IP地址冲突。如果能ping通网关再ping公网固定IP比如14，用traceroute-n14追踪链路断点，在哪一跳出现100%丢包就定位对应节点的链路故障。如果公网固定IP能ping通但公网域名ping不通，直接定位是DNS解析故障，检查/etc/resolv.conf中的DNS服务器配置是否正确，替换阿里云公共DNS测试解析是否恢复。第四是传输层排查：如果ping公网IP正常但访问公网TCP端口不通，执行nc-zv114.114.11480测试端口连通性，同时在服务器上执行tcpdump-ieth0dstport80andhost114.114.114抓包，确认SYN报文是否正常发出去，有没有收到目标返回的SYN+ACK报文，如果SYN发出后没有任何回包，排查服务器的SNAT规则是否丢失，出口防火墙是否拦截了出站报文。第五是应用层排查：如果TCP端口连通正常但curl访问目标页面返回异常，抓包查看HTTP响应码，确认目标站点是否封禁了服务器的源IP，或者应用代理配置错误导致返回403、502等异常状态码。最后做边界校验排查：检查云服务器的安全组、网络ACL的出站规则是否存在公网访问限制，检查服务器系统内核参数是否配置了TCP源端口范围限制，导致源端口不足无法建立新连接。

Kubernetes集群中Pod一直处于ImagePullBackOff状态，完整的排查步骤有哪些？参考答案：首先执行kubectldescribepod<pod名称>-n<命名空间>查看Events字段的报错详情，结合不同报错场景定向排查：第一类场景事件显示ErrImagePull，首先核对Pod中定义的镜像名称、标签拼写是否正确，确认是否遗漏了私有镜像仓库的域名前缀，比如将/project/nginx:v1错误写为nginx:v1，导致系统默认从DockerHub官方仓库拉取不存在的镜像引发报错。第二类场景事件显示401鉴权失败，确认Pod所在的命名空间下存在正确配置的imagePullSecret密钥，并且Pod的spec.imagePullSecrets字段正确引用了该Secret，检查Secret中存储的私有镜像仓库账号密码是否过期、仓库域名是否拼写错误。第三类场景事件显示连接镜像仓库超时、证书不信任，登录Pod所在的Node节点，执行curl/v2/_catalog测试镜像仓库的网络连通性，确认Node节点的DNS解析能够正常解析私有仓库域名，使用自签证书的私有镜像仓库，检查Node节点上/etc/docker/certs.d/目录下是否创建了对应仓库域名的子目录，并且存放了正确的CA证书，避免容器运行时校验证书失败拒绝拉取镜像。第四类场景事件显示镜像拉取写入失败，执行df-h查看Node节点的/var/lib/docker（Docker场景）或者/var/lib/containerd（Containerd场景）分区的磁盘使用率，如果使用率达到100%，批量清理节点上的悬空镜像、已停止的残留容器释放磁盘空间。第五类场景容器运行时配置异常，使用Containerd作为运行时的集群，检查/etc/containerd/config.toml配置文件中私有镜像仓库的镜像加速、鉴权配置是否正确，执行systemctlreloadcontainerd重载配置后重新尝试拉取镜像。所有排查完成后，直接在对应Node节点执行crictlpull<完整镜像地址>手动拉取镜像，如果拉取成功，Kubernetes控制器会自动重试拉取Pod镜像，恢复Running状态。

请设计一套中大规模互联网业务的全栈监控体系，覆盖从基础设施到上层业务的全维度监控，说明每个层级的监控对象、采集方式、告警阈值设计。参考答案：全栈监控体系分为四层，完全覆盖所有运维监控场景：第一层基础设施层，监控对象包括物理服务器/云服务器的CPU、内存、磁盘使用率、磁盘IO、入网出网带宽、硬件温度、电源状态，采集方式用NodeExporter+Prometheus采集操作系统指标，配合IPMI带外监控采集硬件底层状态，告警阈值设置为：CPU连续5分钟使用率超过90%触发P2告警，内存使用率连续5分钟超过90%触发P1告警，磁盘使用率超过85%触发预警，超过95%触发紧急告警，磁盘IOutil连续3分钟超过95%触发P1告警，出口带宽使用率连续2分钟超过90%触发告警，硬件故障触发P0级告警直接通知运维人员。第二层中间件和容