運(yùn)維常見考試試題及答案一、基礎(chǔ)概念與理論1.問題：簡(jiǎn)述IT運(yùn)維的核心目標(biāo)及關(guān)鍵成功因素。答案：IT運(yùn)維的核心目標(biāo)是保障信息系統(tǒng)的穩(wěn)定運(yùn)行、提升資源使用效率、降低運(yùn)維成本并支撐業(yè)務(wù)持續(xù)發(fā)展。關(guān)鍵成功因素包括：①建立標(biāo)準(zhǔn)化的運(yùn)維流程（如變更管理、事件管理、問題管理）；②完善監(jiān)控體系以實(shí)現(xiàn)故障預(yù)警和快速定位；③推動(dòng)自動(dòng)化運(yùn)維減少人工干預(yù)；④構(gòu)建高可用架構(gòu)（如冗余部署、災(zāi)備方案）；⑤培養(yǎng)復(fù)合型運(yùn)維團(tuán)隊(duì)（兼具技術(shù)深度與業(yè)務(wù)理解能力）；⑥持續(xù)優(yōu)化資源配置（如服務(wù)器、網(wǎng)絡(luò)、存儲(chǔ)的動(dòng)態(tài)調(diào)整）。2.問題：某系統(tǒng)SLA（服務(wù)級(jí)別協(xié)議）要求年度可用率不低于99.9%，計(jì)算該系統(tǒng)每年允許的最大停機(jī)時(shí)間（按365天計(jì)算）。答案：年度總時(shí)間=365天×24小時(shí)×60分鐘=525600分鐘。99.9%可用率對(duì)應(yīng)的停機(jī)時(shí)間=525600×(1-99.9%)=525.6分鐘≈8小時(shí)45.6分鐘。因此，每年允許的最大停機(jī)時(shí)間不超過8小時(shí)46分鐘（精確到分鐘）。3.問題：CMDB（配置管理數(shù)據(jù)庫）在運(yùn)維中的核心作用是什么？列舉至少5類常見的配置項(xiàng)（CI）。答案：CMDB的核心作用是記錄IT基礎(chǔ)設(shè)施的配置信息及其關(guān)聯(lián)關(guān)系，為運(yùn)維流程（如故障排查、變更影響分析）提供數(shù)據(jù)支撐，避免“信息孤島”。常見配置項(xiàng)包括：服務(wù)器（物理機(jī)/虛擬機(jī)）、網(wǎng)絡(luò)設(shè)備（交換機(jī)/路由器）、存儲(chǔ)設(shè)備（磁盤陣列/云存儲(chǔ)）、應(yīng)用系統(tǒng)（Web服務(wù)/數(shù)據(jù)庫）、IP地址（公網(wǎng)/內(nèi)網(wǎng)）、域名、用戶賬號(hào)、軟件版本、中間件（Tomcat/Nginx）、安全策略（防火墻規(guī)則/訪問控制列表）。4.問題：簡(jiǎn)述ITIL框架中“事件管理”與“問題管理”的區(qū)別。答案：事件管理關(guān)注“已發(fā)生的故障或異常”的快速恢復(fù)（強(qiáng)調(diào)時(shí)效性），目標(biāo)是最小化業(yè)務(wù)影響；問題管理關(guān)注“事件根本原因”的分析與解決（強(qiáng)調(diào)預(yù)防性），目標(biāo)是通過消除根源減少同類事件重復(fù)發(fā)生。例如：服務(wù)器因內(nèi)存耗盡宕機(jī)（事件管理需重啟服務(wù)恢復(fù)業(yè)務(wù)），后續(xù)分析發(fā)現(xiàn)是應(yīng)用內(nèi)存泄漏（問題管理需修復(fù)代碼或調(diào)整資源分配策略）。5.問題：簡(jiǎn)述運(yùn)維自動(dòng)化的三個(gè)發(fā)展階段，并說明每個(gè)階段的典型工具或技術(shù)。答案：①工具化階段：使用單一工具解決特定問題（如用crontab定時(shí)任務(wù)、shell腳本執(zhí)行備份）；②流程化階段：通過工作流引擎串聯(lián)多個(gè)工具（如用Jenkins實(shí)現(xiàn)“代碼拉取-編譯-部署-測(cè)試”流水線）；③智能化階段：結(jié)合AI/機(jī)器學(xué)習(xí)實(shí)現(xiàn)自主決策（如用AIOps分析日志預(yù)測(cè)故障、自動(dòng)調(diào)整資源）。二、Linux系統(tǒng)與操作6.問題：當(dāng)前目錄下有一個(gè)日志文件access.log，需要統(tǒng)計(jì)其中“2023-10-01”當(dāng)天來自IP為00的訪問次數(shù)，寫出完整的命令組合。答案：grep"2023-10-01"access.log|grep"00"|wc-l。解析：第一步用grep過濾出當(dāng)日日志，第二步進(jìn)一步過濾目標(biāo)IP，最后用wc-l統(tǒng)計(jì)行數(shù)（即訪問次數(shù)）。7.問題：某服務(wù)進(jìn)程占用CPU持續(xù)超過90%，需定位具體線程并分析原因，寫出操作步驟及關(guān)鍵命令。答案：步驟①：用top命令查看進(jìn)程PID（按P鍵按CPU排序）；步驟②：用top-H-p<PID>查看該進(jìn)程下的所有線程（-H顯示線程，-p指定進(jìn)程），記錄高CPU線程的TID；步驟③：將TID轉(zhuǎn)換為十六進(jìn)制（如TID=1234，轉(zhuǎn)換為0x4d2）；步驟④：用jstack<PID>（Java進(jìn)程）或gdb-p<PID>（C/C++進(jìn)程）導(dǎo)出線程堆棧，搜索十六進(jìn)制TID定位具體代碼或函數(shù)；步驟⑤：結(jié)合代碼邏輯分析是否存在死循環(huán)、資源競(jìng)爭(zhēng)或低效算法。8.問題：將/opt/data目錄的權(quán)限設(shè)置為“用戶讀寫執(zhí)行、組內(nèi)用戶讀執(zhí)行、其他用戶無權(quán)限”，寫出chmod命令及數(shù)字權(quán)限表示。答案：chmod750/opt/data。數(shù)字權(quán)限解釋：用戶（u）=rwx（7），組（g）=rx（5），其他（o）=（0）。9.問題：某服務(wù)器無法通過SSH連接（端口22），但能ping通，可能的原因有哪些？列出至少5項(xiàng)排查步驟。答案：可能原因：①SSH服務(wù)未啟動(dòng)（sshd進(jìn)程崩潰）；②防火墻（iptables/ufw）阻止22端口；③SSH配置文件（/etc/ssh/sshd_config）修改后未重啟服務(wù)；④服務(wù)器公網(wǎng)IP變化導(dǎo)致客戶端連接目標(biāo)錯(cuò)誤；⑤SSH服務(wù)監(jiān)聽地址錯(cuò)誤（如僅監(jiān)聽）；⑥客戶端網(wǎng)絡(luò)問題（如路由表錯(cuò)誤、DNS解析異常）。排查步驟：①檢查sshd進(jìn)程狀態(tài)（ps-ef|grepsshd或systemctlstatussshd）；②查看防火墻規(guī)則（iptables-L-n-v|grep22或ufwstatus）；③確認(rèn)sshd_config中Port=22、ListenAddress=配置正確；④用telnet<IP>22測(cè)試端口是否可達(dá)；⑤檢查服務(wù)器日志（/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天內(nèi)），-size+100M表示大于100MB，-exec執(zhí)行tar命令，{}表示匹配的文件，+表示盡可能多的文件合并處理（相比;更高效）。三、監(jiān)控與告警11.問題：在Zabbix中，如何配置一個(gè)觸發(fā)器，監(jiān)控某臺(tái)Linux服務(wù)器的CPU使用率（平均值）超過80%持續(xù)5分鐘后觸發(fā)告警？寫出關(guān)鍵配置步驟。答案：步驟①：確保服務(wù)器已安裝ZabbixAgent，且配置了cpu.util（系統(tǒng)CPU利用率）監(jiān)控項(xiàng)（類型為Zabbixagent，鍵值為system.cpu.util[,avg1]，收集1分鐘平均值）；步驟②：進(jìn)入“配置-主機(jī)-監(jiān)控項(xiàng)”確認(rèn)該監(jiān)控項(xiàng)已正常獲取數(shù)據(jù)；步驟③：創(chuàng)建觸發(fā)器（“配置-觸發(fā)器”），表達(dá)式設(shè)置為：{主機(jī)名:system.cpu.util[,avg1].avg(5m)}>80；步驟④：設(shè)置觸發(fā)器嚴(yán)重程度（如“高”），并關(guān)聯(lián)告警媒介（郵件/短信）；步驟⑤：測(cè)試：通過壓力工具（如stress-c4）提升CPU使用率，驗(yàn)證是否在5分鐘后觸發(fā)告警。12.問題：Prometheus的Exporter有什么作用？列舉3種常見Exporter及其監(jiān)控對(duì)象。答案：Exporter是Prometheus的數(shù)據(jù)源適配器，負(fù)責(zé)將非Prometheus原生格式的指標(biāo)（如Linux系統(tǒng)指標(biāo)、數(shù)據(jù)庫狀態(tài)、中間件性能）轉(zhuǎn)換為Prometheus可識(shí)別的文本格式（開放指標(biāo)協(xié)議）。常見Exporter：①node_exporter（監(jiān)控Linux/Windows服務(wù)器的CPU、內(nèi)存、磁盤、網(wǎng)絡(luò)）；②mysqld_exporter（監(jiān)控MySQL的連接數(shù)、QPS、慢查詢）；③redis_exporter（監(jiān)控Redis的內(nèi)存使用、客戶端連接、持久化狀態(tài)）；④blackbox_exporter（監(jiān)控HTTP服務(wù)可用性、DNS解析時(shí)間、ICMP響應(yīng)）。13.問題：某業(yè)務(wù)系統(tǒng)的監(jiān)控圖表顯示內(nèi)存使用率持續(xù)上升但未觸發(fā)告警，可能的原因有哪些？答案：①告警閾值設(shè)置過高（如閾值為90%，當(dāng)前使用率85%）；②監(jiān)控指標(biāo)采集周期過長(zhǎng)（如每小時(shí)采集一次，未捕捉到峰值）；③內(nèi)存泄漏導(dǎo)致使用率緩慢增長(zhǎng)，未達(dá)到“持續(xù)時(shí)間”條件（如告警需持續(xù)10分鐘，實(shí)際波動(dòng)未滿足）；④監(jiān)控項(xiàng)配置錯(cuò)誤（如采集的是“空閑內(nèi)存”而非“使用內(nèi)存”，導(dǎo)致圖表顯示反向）；⑤Exporter或Agent異常（如進(jìn)程崩潰，數(shù)據(jù)未上報(bào)）；⑥Prometheus服務(wù)器時(shí)間與被監(jiān)控主機(jī)不同步，導(dǎo)致數(shù)據(jù)聚合錯(cuò)誤。14.問題：在Grafana中，如何基于Prometheus數(shù)據(jù)源創(chuàng)建一個(gè)“Nginx請(qǐng)求成功率”儀表盤？寫出關(guān)鍵配置步驟。答案：步驟①：確認(rèn)Prometheus已通過nginx-vts-exporter采集到指標(biāo)（如nginx_vts_requests_total{status=~"2..|3.."}表示成功請(qǐng)求，status=~"4..|5.."}表示失敗請(qǐng)求）；步驟②：在Grafana中添加Prometheus數(shù)據(jù)源；步驟③：新建儀表盤，添加圖表（類型為“Timeseries”）；步驟④：在查詢面板輸入表達(dá)式：(sum(rate(nginx_vts_requests_total{status=~"2..|3.."}[5m]))/sum(rate(nginx_vts_requests_total[5m])))100；步驟⑤：設(shè)置Y軸單位為“百分比（%）”，添加閾值線（如99%為綠色，95%-99%為黃色，<95%為紅色）；步驟⑥：配置圖表標(biāo)題（如“Nginx請(qǐng)求成功率（5分鐘滾動(dòng)）”），保存儀表盤。15.問題：簡(jiǎn)述日志集中管理的必要性，并說明ELK棧（Elasticsearch、Logstash、Kibana）各組件的作用。答案：必要性：分散的日志難以統(tǒng)一分析，集中管理可實(shí)現(xiàn)跨服務(wù)器/應(yīng)用的關(guān)聯(lián)查詢、故障快速定位、安全審計(jì)及趨勢(shì)分析。ELK組件作用：①Logstash：日志收集與處理（從文件、網(wǎng)絡(luò)等來源采集日志，通過filter插件清洗、轉(zhuǎn)換、豐富數(shù)據(jù)，如解析JSON、提取時(shí)間戳）；②Elasticsearch：分布式搜索引擎，存儲(chǔ)結(jié)構(gòu)化日志數(shù)據(jù)，支持快速查詢與聚合分析；③Kibana：可視化工具，通過圖表、儀表盤展示日志統(tǒng)計(jì)結(jié)果（如錯(cuò)誤率趨勢(shì)、TOP5慢接口）。四、故障排查與應(yīng)急16.問題：用戶反饋訪問某電商網(wǎng)站首頁緩慢（超過5秒），但后臺(tái)管理系統(tǒng)訪問正常，可能的故障原因有哪些？列出排查思路。答案：可能原因：①首頁靜態(tài)資源（圖片、JS、CSS）未緩存或緩存失效，導(dǎo)致重復(fù)下載；②首頁數(shù)據(jù)庫查詢復(fù)雜（如多表關(guān)聯(lián)、缺少索引），響應(yīng)時(shí)間長(zhǎng)；③CDN節(jié)點(diǎn)故障，靜態(tài)資源回源到源站，增加延遲；④首頁引入第三方插件（如廣告、統(tǒng)計(jì)代碼）加載緩慢；⑤應(yīng)用服務(wù)器（如Tomcat）線程池耗盡，無法及時(shí)處理請(qǐng)求；⑥首頁對(duì)應(yīng)的Nginx配置錯(cuò)誤（如未開啟gzip壓縮、代理超時(shí)設(shè)置過短）。排查思路：①用ChromeDevTools（Network標(biāo)簽）分析首頁加載各資源的耗時(shí)，定位慢資源；②檢查數(shù)據(jù)庫慢查詢?nèi)罩荆ㄈ鏜ySQL的slow_query_log），分析首頁相關(guān)SQL是否需優(yōu)化（加索引、拆分查詢）；③登錄CDN控制臺(tái)查看節(jié)點(diǎn)健康狀態(tài)及回源率；④禁用第三方插件后測(cè)試加載速度；⑤查看應(yīng)用服務(wù)器日志（如catalina.out），檢查是否有線程池滿、內(nèi)存溢出異常；⑥檢查Nginx訪問日志（記錄$request_time），確認(rèn)請(qǐng)求在Nginx層的處理時(shí)間。17.問題：某MySQL數(shù)據(jù)庫主從同步中斷，從庫日志（relay-log）顯示“Error1032:Can'tfindrecordintable”，可能的原因是什么？如何解決？答案：原因：主庫執(zhí)行了刪除操作（DELETE），但從庫對(duì)應(yīng)記錄已不存在（可能因從庫誤操作、主從數(shù)據(jù)不一致），導(dǎo)致從庫無法應(yīng)用二進(jìn)制日志。解決步驟：①確認(rèn)主從數(shù)據(jù)差異：在主庫執(zhí)行SELECTFROMtableWHEREid=XXX（XXX為報(bào)錯(cuò)中的記錄ID），從庫執(zhí)行相同查詢，確認(rèn)是否存在記錄；②臨時(shí)跳過錯(cuò)誤：在從庫執(zhí)行STOPSLAVE;SETGLOBALSQL_SLAVE_SKIP_COUNTER=1;STARTSLAVE;（僅適用于非關(guān)鍵操作，需謹(jǐn)慎）；③同步數(shù)據(jù)：若主庫存在記錄而從庫不存在，從主庫導(dǎo)出該記錄（mysqldump-t-d--where="id=XXX"dbtable），在從庫插入；④長(zhǎng)期解決方案：檢查主從數(shù)據(jù)一致性（用pt-table-checksum工具），避免從庫手動(dòng)修改數(shù)據(jù)，確保主庫操作通過二進(jìn)制日志同步。18.問題：某服務(wù)器突然無法訪問外網(wǎng)（能ping通內(nèi)網(wǎng)IP，但無法解析域名、無法訪問80端口網(wǎng)站），可能的故障點(diǎn)有哪些？答案：①默認(rèn)網(wǎng)關(guān)配置錯(cuò)誤（route-n查看網(wǎng)關(guān)是否正確）；②DNS服務(wù)器不可用或配置錯(cuò)誤（/etc/resolv.conf中的nameserver是否可達(dá)，用nslookup測(cè)試解析）；③防火墻規(guī)則阻止出站流量（iptables-L-n-v查看OUTPUT鏈?zhǔn)欠裼蠨ROP規(guī)則）；④NAT表配置異常（iptables-tnat-L查看POSTROUTING鏈?zhǔn)欠裾＃?；⑤網(wǎng)絡(luò)接口狀態(tài)異常（ifconfig或iplink查看網(wǎng)卡是否up，是否有丟包）；⑥運(yùn)營(yíng)商線路故障（通過traceroute查看跳點(diǎn)是否在某節(jié)點(diǎn)中斷）；⑦病毒或惡意軟件劫持網(wǎng)絡(luò)連接（檢查是否有異常進(jìn)程占用網(wǎng)絡(luò)端口）。19.問題：某K8s集群中，Pod持續(xù)處于“CrashLoopBackOff”狀態(tài)，如何排查？答案：步驟①：查看Pod事件：kubectldescribepod<pod-name>，關(guān)注Events中的錯(cuò)誤信息（如鏡像拉取失敗、容器啟動(dòng)命令錯(cuò)誤）；步驟②：查看容器日志：kubectllogs<pod-name>（當(dāng)前實(shí)例日志）或kubectllogs<pod-name>--previous（前一次崩潰日志）；步驟③：檢查容器啟動(dòng)命令和參數(shù)：kubectlgetpod<pod-name>-oyaml，查看mand和args是否正確；步驟④：驗(yàn)證資源限制：檢查spec.resources.limits（CPU/內(nèi)存）是否過小導(dǎo)致OOMKilled（內(nèi)存不足被殺死）；步驟⑤：測(cè)試容器健康檢查：kubectlexec<pod-name>-<健康檢查命令>（如curllocalhost:8080/health），確認(rèn)是否返回200；步驟⑥：排查依賴服務(wù)：檢查Pod是否依賴的ConfigMap、Secret未創(chuàng)建，或Service/Endpoint不可達(dá)（用nslookup<service-name>測(cè)試DNS解析）。20.問題：某Redis主節(jié)點(diǎn)宕機(jī)，哨兵（Sentinel）未自動(dòng)切換到從節(jié)點(diǎn)，可能的原因有哪些？答案：①Sentinel配置錯(cuò)誤：如sentinelmonitor<master-name><ip><port><quorum>中的quorum（法定人數(shù)）設(shè)置過大，導(dǎo)致無法達(dá)成故障轉(zhuǎn)移共識(shí)；②Sentinel與主/從節(jié)點(diǎn)網(wǎng)絡(luò)不通（用telnet測(cè)試Sentinel到主/從的端口是否可達(dá)）；③主節(jié)點(diǎn)宕機(jī)后，從節(jié)點(diǎn)未配置為可寫（需確保從節(jié)點(diǎn)的slave-read-only=no，否則切換后無法接收寫請(qǐng)求）；④Sentinel自身進(jìn)程崩潰（ps-ef|grepsentinel檢查是否存活）；⑤主節(jié)點(diǎn)假死（進(jìn)程存在但無響應(yīng)），Sentinel的down-after-milliseconds（判定主觀下線的超時(shí)時(shí)間）設(shè)置過長(zhǎng)，未及時(shí)觸發(fā)客觀下線；⑥從節(jié)點(diǎn)數(shù)據(jù)落后主節(jié)點(diǎn)過多（超過client-output-buffer-limit設(shè)置），Sentinel認(rèn)為從節(jié)點(diǎn)不適合提升為主節(jié)點(diǎn)。五、云服務(wù)與自動(dòng)化運(yùn)維21.問題：阿里云ECS實(shí)例突然無法遠(yuǎn)程連接，控制臺(tái)顯示“實(shí)例運(yùn)行中”，可能的原因有哪些？列出至少5項(xiàng)阿里云特有的排查點(diǎn)。答案：①安全組規(guī)則未放行遠(yuǎn)程端口（如SSH的22端口、RDP的3389端口）：檢查實(shí)例所屬安全組的入方向規(guī)則；②公網(wǎng)IP未綁定或EIP（彈性公網(wǎng)IP）釋放：查看實(shí)例的公網(wǎng)IP是否存在，是否綁定了EIP；③NAT網(wǎng)關(guān)或EIP帶寬超限：若通過NAT網(wǎng)關(guān)訪問公網(wǎng)，檢查網(wǎng)關(guān)的帶寬是否耗盡；④實(shí)例被阿里云安全策略封禁（如觸發(fā)DDoS攻擊、惡意請(qǐng)求）：查看阿里云控制臺(tái)的“安全中心”是否有攔截記錄；⑤實(shí)例元數(shù)據(jù)服務(wù)（IMDS）配置錯(cuò)誤：若依賴元數(shù)據(jù)獲取認(rèn)證信息，檢查是否因配置錯(cuò)誤導(dǎo)致服務(wù)異常；⑥VPC路由表配置錯(cuò)誤：查看VPC的路由表是否有正確的默認(rèn)路由指向Internet網(wǎng)關(guān)。22.問題：編寫一個(gè)Ansible劇本（playbook），實(shí)現(xiàn)以下需求：在所有web服務(wù)器（組名為web_servers）上安裝Nginx，配置自定義首頁（內(nèi)容為“WelcometoMySite”），并重啟Nginx服務(wù)（確保開機(jī)自啟）。答案：```yamlname:DeployNginxonwebservershosts:web_serversbecome:yes使用root權(quán)限tasks:name:InstallNginxpackage:name:nginxstate:present確保已安裝name:Configurecustomindexpagecopy:content:"WelcometoMySite"dest:/usr/share/nginx/html/index.htmlmode:'0644'設(shè)置文件權(quán)限name:EnsureNginxisrunningandenabledservice:name:nginxstate:restarted重啟服務(wù)使配置生效enabled:yes開機(jī)自啟```解析：package模塊根據(jù)系統(tǒng)自動(dòng)選擇yum/dpkg安裝；copy模塊直接提供首頁文件（content指定內(nèi)容，dest為目標(biāo)路徑）；service模塊管理服務(wù)狀態(tài)（state=restarted觸發(fā)重啟，enabled=yes設(shè)置開機(jī)啟動(dòng)）。23.問題：使用Docker部署一個(gè)SpringBoot應(yīng)用（鏡像名為myapp:v1），要求：①映射容器8080端口到主機(jī)80；②掛載主機(jī)/data/logs到容器/var/log/myapp；③限制容器CPU最大使用1核、內(nèi)存512MB；④容器重啟策略為“除非手動(dòng)停止，否則始終重啟”。寫出完整的dockerrun命令。答案：dockerrun-d\--namemyapp\-p80:8080\-v/data/logs:/var/log/myapp\--cpus=1\--memory=512m\--restartunless-stopped\myapp:v1解析：-d后臺(tái)運(yùn)行；--name指定容器名；-p端口映射（主機(jī)80:容器8080）；-v卷掛載（主機(jī)路徑:容器路徑）；--cpus限制CPU核數(shù)；--memory限制內(nèi)存大??；--restartunless-stopped設(shè)置重啟策略。24.問題：在AWS中，如何實(shí)現(xiàn)EC2實(shí)例的高可用部署？列舉關(guān)鍵步驟。答案：步驟①：創(chuàng)建VPC并劃分多可用區(qū)（AZ）的子網(wǎng)（如us-east-1a、us-east-1b）；步驟②：創(chuàng)建自動(dòng)擴(kuò)展組（AutoScalingGroup，ASG），指定啟動(dòng)模板（包含EC2實(shí)例類型、AMI、安全組）；步驟③：配置ASG的擴(kuò)展策略（如基于CPU使用率自動(dòng)擴(kuò)縮容），并設(shè)置最小/最大實(shí)例數(shù)（如最小2臺(tái)，分布在不同AZ）；步驟④：創(chuàng)建彈性負(fù)載均衡器（ELB/ALB），將ASG關(guān)聯(lián)到負(fù)載均衡器，實(shí)現(xiàn)流量分發(fā)；步驟⑤：配置健康檢查（ALB定期檢查實(shí)例狀態(tài)，不健康實(shí)例自動(dòng)替換）；步驟⑥：?jiǎn)⒂肊BS卷快照或使用EFS（彈性文件系統(tǒng)）實(shí)現(xiàn)數(shù)據(jù)持久化，避免實(shí)例重建導(dǎo)致數(shù)據(jù)丟失。25.問題：簡(jiǎn)述GitLabC