2025年運維測試題與參考答案一、選擇題（每題2分，共30分）1.以下哪個Linux命令可以實時監(jiān)控進程的CPU和內(nèi)存占用情況？A.topB.ps-efC.free-hD.df-h答案：A2.某MySQL數(shù)據(jù)庫出現(xiàn)慢查詢，執(zhí)行`SHOWFULLPROCESSLIST`后發(fā)現(xiàn)大量狀態(tài)為`Sortingresult`的線程，最可能的原因是？A.鎖等待B.缺少索引導(dǎo)致全表掃描后排序C.事務(wù)未提交D.連接數(shù)超過最大值答案：B3.在Kubernetes集群中，用于管理Pod生命周期并確保指定數(shù)量Pod運行的控制器是？A.DeploymentB.StatefulSetC.DaemonSetD.Job答案：A4.以下哪個工具常用于Linux系統(tǒng)的網(wǎng)絡(luò)流量抓包分析？A.netstatB.tcpdumpC.ifconfigD.iptables答案：B5.某服務(wù)器SSH連接突然中斷，無法遠程登錄，排查時首先應(yīng)檢查？A.防火墻是否攔截22端口B./etc/ssh/sshd_config配置是否修改C.SSH服務(wù)進程是否存活（ps-ef|grepsshd）D.服務(wù)器是否宕機（ping測試）答案：D6.關(guān)于Prometheus的監(jiān)控指標(biāo)類型，以下描述錯誤的是？A.Counter（計數(shù)器）適用于累計值，如請求總數(shù)B.Gauge（儀表盤）適用于可增可減的指標(biāo)，如內(nèi)存使用率C.Histogram（直方圖）用于統(tǒng)計區(qū)間分布，如請求耗時D.Summary（摘要）無法直接計算分位數(shù)答案：D7.某Nginx服務(wù)器配置了反向代理，訪問前端頁面時樣式丟失，檢查日志發(fā)現(xiàn)CSS文件返回404，可能的原因是？A.Nginxworker_processes配置過小B.代理配置中未正確設(shè)置`root`或`alias`路徑C.防火墻攔截了80端口D.Nginx未啟用gzip壓縮答案：B8.以下哪個是etcd的典型應(yīng)用場景？A.關(guān)系型數(shù)據(jù)庫存儲B.分布式系統(tǒng)配置中心C.大數(shù)據(jù)實時計算D.日志聚合存儲答案：B9.某Redis實例內(nèi)存持續(xù)增長，執(zhí)行`INFOmemory`發(fā)現(xiàn)`used_memory_peak`遠高于當(dāng)前`used_memory`，但`maxmemory-policy`設(shè)置為`noeviction`，最合理的處理措施是？A.重啟Redis服務(wù)釋放內(nèi)存B.手動刪除過期鍵（`redis-cli--scan--pattern''|xargsredis-cliunlink`）C.修改`maxmemory-policy`為`allkeys-lru`D.擴容Redis實例內(nèi)存答案：C10.在Linux系統(tǒng)中，查看當(dāng)前用戶的所有已激活的SELinux策略的命令是？A.sestatusB.getsebool-aC.semanageboolean-lD.setenforce0答案：A11.某Docker容器無法訪問外部網(wǎng)絡(luò)，執(zhí)行`dockerexec-itcontainerping`失敗，但宿主機可以正常ping通，可能的故障點是？A.容器內(nèi)DNS配置錯誤B.宿主機iptables規(guī)則禁止容器網(wǎng)絡(luò)轉(zhuǎn)發(fā)C.容器鏡像缺少ping工具D.宿主機網(wǎng)絡(luò)接口（如docker0）故障答案：B12.以下哪個是ZooKeeper的核心特性？A.高吞吐量的實時消息隊列B.分布式協(xié)調(diào)與一致性保證C.列式存儲的大數(shù)據(jù)倉庫D.內(nèi)存數(shù)據(jù)庫的持久化存儲答案：B13.某公司生產(chǎn)環(huán)境要求數(shù)據(jù)庫備份恢復(fù)時間目標(biāo)（RTO）≤30分鐘，恢復(fù)點目標(biāo)（RPO）≤15分鐘，以下備份策略最合理的是？A.每日全量備份+每小時增量備份B.每周全量備份+每日差異備份C.實時事務(wù)日志備份+每4小時全量備份D.每月全量備份+每周增量備份答案：C14.在Kubernetes中，Pod的`ReadinessProbe`失敗會導(dǎo)致？A.Pod被重啟B.流量不再路由到該PodC.節(jié)點被標(biāo)記為不可調(diào)度D.服務(wù)（Service）被刪除答案：B15.以下哪個工具可用于Linux文件系統(tǒng)的完整性檢查和修復(fù)？A.fsckB.lsofC.duD.dd答案：A二、填空題（每題2分，共20分）1.Linux系統(tǒng)中，查看當(dāng)前開放端口及對應(yīng)進程的命令是______（需顯示PID）。答案：netstat-tunlp或ss-tunlp2.MySQL中，用于查看當(dāng)前事務(wù)隔離級別的全局變量是______。答案：tx_isolation（或transaction_isolation，取決于版本）3.Kubernetes集群中，存儲Pod調(diào)度策略的組件是______。答案：kube-scheduler4.Prometheus默認(rèn)通過______協(xié)議拉取被監(jiān)控目標(biāo)的指標(biāo)數(shù)據(jù)。答案：HTTP5.Nginx配置文件的默認(rèn)全局主配置路徑是______。答案：/etc/nginx/nginx.conf6.Redis持久化機制中，AOF日志的默認(rèn)文件名為______。答案：appendonly.aof7.Docker容器的網(wǎng)絡(luò)模式中，與宿主機共享網(wǎng)絡(luò)命名空間的模式是______。答案：host8.Linux系統(tǒng)中，用戶密碼存儲在______文件中（需寫完整路徑）。答案：/etc/shadow9.某服務(wù)器時區(qū)錯誤，需將時區(qū)設(shè)置為“Asia/Shanghai”，應(yīng)修改______文件或使用______命令（寫出任一方法）。答案：/etc/localtime或timedatectlset-timezoneAsia/Shanghai10.用于管理Kubernetes集群的命令行工具是______。答案：kubectl三、判斷題（每題1分，共10分）1.Linux系統(tǒng)中，`chmod755file`表示文件所有者擁有讀、寫、執(zhí)行權(quán)限，其他用戶擁有讀、執(zhí)行權(quán)限。（）答案：×（755是所有者rwx，組用戶rx，其他用戶rx）2.MySQL的InnoDB引擎支持行級鎖，而MyISAM引擎僅支持表級鎖。（）答案：√3.Kubernetes的Pod被刪除后，其關(guān)聯(lián)的PersistentVolume會被自動刪除。（）答案：×（取決于PersistentVolumeClaim的回收策略）4.Prometheus的Alertmanager負(fù)責(zé)指標(biāo)的收集和存儲。（）答案：×（Alertmanager負(fù)責(zé)告警處理，指標(biāo)存儲由PrometheusServer完成）5.Docker鏡像的構(gòu)建過程基于Dockerfile中的指令，每層指令都會提供一個新的鏡像層。（）答案：√6.Linux的`crontab`任務(wù)中，“”表示每分鐘執(zhí)行一次任務(wù)。（）答案：√7.Redis的`KEYS`命令在生產(chǎn)環(huán)境中可以安全使用，不會阻塞服務(wù)。（）答案：×（KEYS命令會遍歷所有鍵，大集群中可能導(dǎo)致阻塞）8.Nginx的`upstream`模塊可用于配置負(fù)載均衡，支持輪詢、加權(quán)輪詢、IP哈希等算法。（）答案：√9.服務(wù)器磁盤空間不足時，`df-h`顯示的可用空間為0，但`du-sh/`統(tǒng)計的總大小小于磁盤容量，可能是因為存在未釋放的刪除文件（被進程占用）。（）答案：√10.在Kubernetes中，HorizontalPodAutoscaler（HPA）可以根據(jù)CPU使用率自動調(diào)整Pod數(shù)量，但無法基于自定義指標(biāo)（如QPS）擴縮容。（）答案：×（HPA支持自定義指標(biāo)，需配合PrometheusAdapter等工具）四、簡答題（每題6分，共30分）1.簡述Linux服務(wù)器CPU使用率過高的排查步驟。答案：（1）使用`top`或`htop`查看進程CPU占用，定位高負(fù)載進程；（2）對目標(biāo)進程，使用`ps-mpPID-oTHREAD,tid,time`查看線程級CPU占用，確定具體線程；（3）通過`strace-pTID`分析線程系統(tǒng)調(diào)用，或使用`perftop`分析函數(shù)調(diào)用棧，定位耗時操作；（4）檢查是否存在死循環(huán)、大量計算任務(wù)或IO密集型操作；（5）結(jié)合應(yīng)用日志（如GC日志、慢查詢?nèi)罩荆┓治鍪欠裼蓱?yīng)用邏輯問題導(dǎo)致；（6）確認(rèn)是否為周期性負(fù)載（如定時任務(wù)），調(diào)整任務(wù)執(zhí)行時間或資源分配。2.說明Kubernetes中Service與Ingress的區(qū)別及各自用途。答案：Service是Kubernetes內(nèi)部的負(fù)載均衡抽象，通過ClusterIP、NodePort、LoadBalancer等類型，為一組Pod提供穩(wěn)定的網(wǎng)絡(luò)訪問入口（四層負(fù)載均衡），主要解決集群內(nèi)部Pod的發(fā)現(xiàn)與通信問題；Ingress是七層負(fù)載均衡控制器（如NginxIngress），基于HTTP/HTTPS協(xié)議，支持域名路由、路徑匹配、TLS終止等高級功能，用于將集群外部流量路由到內(nèi)部Service，通常作為集群的入口網(wǎng)關(guān)。3.某MySQL主從復(fù)制中斷，錯誤日志顯示“SlaveI/O:errorconnectingtomaster'repl@master_ip:3306'-retry-time:60retries:10”，可能的原因有哪些？如何排查？答案：可能原因：（1）主庫的復(fù)制用戶（repl）權(quán)限不足（如未授權(quán)`REPLICATIONSLAVE`權(quán)限）；（2）主庫的bind-address綁定了非通配地址（如），從庫無法連接；（3）主庫或從庫的防火墻攔截了3306端口；（4）主庫的`server-id`與從庫重復(fù)；（5）主庫的二進制日志（binlog）格式或版本與從庫不兼容；排查步驟：（1）檢查主庫`mysql.user`表，確認(rèn)復(fù)制用戶的`Host`字段是否允許從庫IP連接，且擁有`REPLICATIONSLAVE`權(quán)限；（2）查看主庫`f`配置，確認(rèn)`bind-address=`（或允許從庫訪問的IP），`server-id`唯一；（3）使用`telnetmaster_ip3306`測試從庫到主庫的網(wǎng)絡(luò)連通性；（4）檢查主庫`showglobalvariableslike'log_bin'`確認(rèn)binlog已啟用，`showmasterstatus`查看binlog文件及位置是否正常；（5）從庫執(zhí)行`showslavestatus\G`，查看`Last_IO_Error`具體錯誤信息，針對性修復(fù)。4.簡述自動化運維平臺設(shè)計的核心要點（至少列出5點）。答案：（1）標(biāo)準(zhǔn)化：基礎(chǔ)設(shè)施、配置、流程的標(biāo)準(zhǔn)化，確保操作可重復(fù)；（2）冪等性：操作設(shè)計需支持多次執(zhí)行不影響最終狀態(tài)（如使用idempotent的配置管理工具）；（3）可觀測性：集成監(jiān)控、日志、追蹤系統(tǒng)，實時反饋操作結(jié)果及影響；（4）權(quán)限控制：細(xì)粒度的角色權(quán)限管理（RBAC），避免越權(quán)操作；（5）流程審批：關(guān)鍵操作（如刪庫、重啟）需通過審批流程，降低人為失誤；（6）故障自愈：結(jié)合監(jiān)控告警，自動觸發(fā)修復(fù)動作（如自動擴縮容、重啟異常服務(wù)）；（7）兼容性：支持多環(huán)境（物理機、虛擬機、云主機、容器）、多技術(shù)棧（Java、Python、Go）的統(tǒng)一管理；（8）文檔化：操作記錄、變更日志可追溯，便于問題排查與經(jīng)驗沉淀。5.如何設(shè)計一個高可用的Nginx負(fù)載均衡架構(gòu)？需考慮哪些關(guān)鍵因素？答案：架構(gòu)設(shè)計：（1）采用主備或雙活模式部署Nginx節(jié)點，通過Keepalived或Haproxy實現(xiàn)虛擬IP（VIP）漂移，避免單點故障；（2）后端應(yīng)用服務(wù)器部署多實例，分布在不同可用區(qū)或物理機，通過Nginx的`upstream`配置負(fù)載均衡算法（如加權(quán)輪詢、最少連接）；（3）啟用健康檢查（`check`模塊或`ngx_http_upstream_hc_module`），自動剔除故障的后端節(jié)點；（4）配置靜態(tài)資源緩存（`expires`指令）或集成CDN，減輕后端壓力；（5）啟用TLS終止（SSLPassthrough或直接處理HTTPS請求），卸載后端服務(wù)器的加密計算壓力；關(guān)鍵因素：-網(wǎng)絡(luò)延遲：Nginx節(jié)點與后端服務(wù)器的網(wǎng)絡(luò)延遲需低，避免影響響應(yīng)速度；-會話保持：若應(yīng)用依賴Session，需配置`ip_hash`或使用分布式Session（如Redis）；-流量限制：通過`limit_req`、`limit_conn`防止DDoS或惡意請求；-日志與監(jiān)控：記錄訪問日志，集成Prometheus+Grafana監(jiān)控QPS、響應(yīng)時間、錯誤率等指標(biāo)；-配置熱加載：使用`nginx-sreload`實現(xiàn)配置更新不中斷服務(wù)；-災(zāi)備切換：當(dāng)主Nginx集群故障時，可快速切換至備用集群（如通過DNSTTL設(shè)置）。五、綜合題（每題10分，共30分）1.某電商平臺大促期間，用戶反饋下單接口響應(yīng)緩慢（平均耗時從200ms上升至2s），作為運維工程師，請設(shè)計排查與解決流程。答案：排查流程：（1）確認(rèn)整體負(fù)載：通過監(jiān)控平臺（如Prometheus）查看應(yīng)用服務(wù)器CPU、內(nèi)存、磁盤IO、網(wǎng)絡(luò)帶寬是否達到瓶頸；（2）定位耗時環(huán)節(jié)：-應(yīng)用層：使用APM工具（如Skywalking、Pinpoint）追蹤請求鏈路，確認(rèn)是數(shù)據(jù)庫、緩存、第三方接口還是業(yè)務(wù)邏輯耗時；-數(shù)據(jù)庫層：檢查MySQL慢查詢?nèi)罩荆╜slow_query_log`），確認(rèn)是否存在未命中索引的查詢，或鎖等待（`SHOWENGINEINNODBSTATUS`查看鎖信息）；-緩存層：檢查Redis的`INFOstats`，確認(rèn)是否存在緩存擊穿（大量請求穿透到數(shù)據(jù)庫）、緩存雪崩（批量緩存失效），或緩存命中率下降；-網(wǎng)絡(luò)層：使用`tcpdump`抓包，檢查應(yīng)用服務(wù)器與數(shù)據(jù)庫/緩存之間的網(wǎng)絡(luò)延遲或丟包；（3）分析日志：查看應(yīng)用錯誤日志、Nginx訪問日志（關(guān)注`upstream_response_time`），確認(rèn)是否有大量5xx錯誤或超時；解決措施：-若數(shù)據(jù)庫慢查詢導(dǎo)致：為查詢語句添加索引，或優(yōu)化SQL（如拆分復(fù)雜查詢、減少JOIN操作）；-若緩存問題導(dǎo)致：調(diào)整緩存過期時間（隨機化避免雪崩），增加熱點數(shù)據(jù)預(yù)加載，或使用本地緩存（如Caffeine）減輕Redis壓力；-若應(yīng)用服務(wù)器負(fù)載過高：橫向擴容應(yīng)用實例，或調(diào)整JVM參數(shù)（如堆內(nèi)存、GC策略）減少FullGC頻率；-若網(wǎng)絡(luò)延遲導(dǎo)致：檢查防火墻規(guī)則、路由配置，或遷移數(shù)據(jù)庫/緩存至同可用區(qū)降低延遲；-臨時方案：啟用降級（如關(guān)閉非核心功能）、限流（如Nginx`limit_req`），確保核心業(yè)務(wù)可用。2.某公司采用Kubernetes部署微服務(wù)，某天發(fā)現(xiàn)集群中大量Pod處于`CrashLoopBackOff`狀態(tài)，需快速定位原因并修復(fù)。請寫出具體步驟。答案：步驟1：確認(rèn)Pod狀態(tài)詳情執(zhí)行`kubectlgetpods-owide`查看Pod所在節(jié)點、重啟次數(shù)；執(zhí)行`kubectldescribepod<pod-name>`查看事件（Events），重點關(guān)注`FailedCreatePodSandBox`、`FailedStartContainer`等錯誤。步驟2：查看容器日志執(zhí)行`kubectllogs<pod-name>`（當(dāng)前日志）或`kubectllogs<pod-name>--previous`（上一次重啟前的日志），定位應(yīng)用崩潰原因（如OOMKilled、啟動參數(shù)錯誤、依賴服務(wù)不可達）。步驟3：檢查容器運行時登錄Pod所在節(jié)點，執(zhí)行`dockerps-a|grep<pod-id>`（或`crictlps-a`）查看容器退出狀態(tài)碼（如137表示內(nèi)存溢出）；執(zhí)行`dockerinspect<container-id>`查看容器詳細(xì)信息，確認(rèn)資源限制（`memory.limit`、`cpu.limit`）是否被觸發(fā)。步驟4：排查依賴問題-檢查配置是否正確：`kubectlgetconfigmap<cm-name>-oyaml`、`kubectlgetsecret<secret-name>-oyaml`確認(rèn)掛載的配置或密鑰是否正確；-檢查服務(wù)發(fā)現(xiàn)：`kubectlgetsvc<service-name>`確認(rèn)ServiceIP、端口是否正常，`nslookup<service-name>.<namespace>.svc.cluster.local`測試DNS解析；-檢查存儲卷：`kubectldescribepvc<pvc-name>`確認(rèn)PersistentVolume是否綁定，路徑是否可讀寫（`kubectlexec<pod-name>--ls<mount-path>`）。步驟5：驗證鏡像問題執(zhí)行`dockerpull<image-name>`測試鏡像是否可正常拉?。ㄅ懦R像倉庫網(wǎng)絡(luò)問題）；本地啟動鏡像（`dockerrun--rm<image-name>`），觀察是否能正常啟動，確認(rèn)是否為鏡像本身缺陷（如缺失依賴庫、啟動腳本錯誤）。步驟6：修復(fù)與驗證-若為應(yīng)用代碼錯誤：聯(lián)系開發(fā)團隊修復(fù)代碼并重新構(gòu)建鏡像；-若為資源限制不足：調(diào)整Pod的`resources.limits`（如增加內(nèi)存限制）；-若為配置錯誤：修正ConfigMap/Secret并滾動更新Deployment（`kubectlrolloutrestartdeployment<deploy-name>`）；-若為節(jié)點問題：標(biāo)記節(jié)點為不可調(diào)度（`kubectlcordon<node-name>`），驅(qū)逐Pod（`kubectldrain<node-name>`），修復(fù)節(jié)點后重新加入集群。3.某金融機構(gòu)要求對生產(chǎn)環(huán)境服務(wù)器進行定期安全加固，需制定加固方案。請列出關(guān)鍵加固措施（至少10項）。答案：（1）系統(tǒng)補丁管理：定期安裝操作系統(tǒng)（如CentOS的`yumupdate`）、中間件（如Nginx、MySQL）的安全補丁，啟用自動更新或設(shè)置更新計劃；（2）用戶權(quán)限最小化：刪除冗余用戶（`cat/etc/passwd`檢查），禁用默認(rèn)用戶（如`guest`），為管理員分配獨立賬號，使用`usermod-L`鎖定非活躍賬號；（3）密碼策略強化：通過`/etc/security/pwquality.conf`設(shè)置密碼復(fù)雜度（長度≥12位，包含大小寫、數(shù)字、特殊字符），`/etc/shadow`設(shè)置密碼過期時間（≤90天）；（4）SSH安全配置：修改默認(rèn)22端口（`Port自定義端口`），禁用root直接登錄（`PermitRootLoginno`），啟用公鑰認(rèn)證（`PubkeyAuthenticationyes`），禁用