2025年上半年信息系統(tǒng)管理工程師練習(xí)題及答案一、單項(xiàng)選擇題（共20題，每題2分，共40分）1.在信息系統(tǒng)生命周期中，確定系統(tǒng)邊界、主要功能和性能指標(biāo)的階段是（）。A.系統(tǒng)規(guī)劃B.系統(tǒng)分析C.系統(tǒng)設(shè)計(jì)D.系統(tǒng)實(shí)施答案：A解析：系統(tǒng)規(guī)劃階段的核心任務(wù)是確定系統(tǒng)的發(fā)展戰(zhàn)略，明確系統(tǒng)的邊界、主要功能和性能指標(biāo)，為后續(xù)階段提供指導(dǎo)。2.某企業(yè)信息系統(tǒng)采用微服務(wù)架構(gòu)，當(dāng)部分服務(wù)出現(xiàn)故障時(shí)，系統(tǒng)通過自動(dòng)切換備用實(shí)例保持整體可用。這體現(xiàn)了信息系統(tǒng)的（）特性。A.可擴(kuò)展性B.可靠性C.可維護(hù)性D.安全性答案：B解析：可靠性強(qiáng)調(diào)系統(tǒng)在規(guī)定條件下和規(guī)定時(shí)間內(nèi)完成規(guī)定功能的能力，自動(dòng)切換備用實(shí)例屬于容錯(cuò)設(shè)計(jì)，直接提升可靠性。3.以下不屬于IT服務(wù)管理（ITSM）核心流程的是（）。A.事件管理B.問題管理C.配置管理D.數(shù)據(jù)管理答案：D解析：ITIL框架下的核心流程包括事件管理、問題管理、變更管理、發(fā)布管理和配置管理，數(shù)據(jù)管理屬于數(shù)據(jù)治理范疇。4.某系統(tǒng)需要存儲(chǔ)用戶行為日志，要求支持高并發(fā)寫入和實(shí)時(shí)查詢。最適合的數(shù)據(jù)庫類型是（）。A.關(guān)系型數(shù)據(jù)庫（如MySQL）B.列式數(shù)據(jù)庫（如HBase）C.鍵值數(shù)據(jù)庫（如Redis）D.文檔數(shù)據(jù)庫（如MongoDB）答案：B解析：列式數(shù)據(jù)庫適合高并發(fā)寫入和大規(guī)模數(shù)據(jù)實(shí)時(shí)查詢，常用于日志存儲(chǔ)場景；Redis主要用于緩存，MongoDB適合非結(jié)構(gòu)化數(shù)據(jù)但實(shí)時(shí)查詢性能弱于列式存儲(chǔ)。5.信息系統(tǒng)安全等級保護(hù)中，第三級系統(tǒng)的安全保護(hù)要求不包括（）。A.系統(tǒng)審計(jì)覆蓋到每個(gè)用戶B.重要數(shù)據(jù)加密傳輸C.具備災(zāi)難恢復(fù)能力D.無需進(jìn)行安全評測答案：D解析：三級系統(tǒng)需每年至少進(jìn)行一次安全評測，四級系統(tǒng)需每半年一次，一級、二級無強(qiáng)制要求。6.在信息系統(tǒng)運(yùn)維中，通過監(jiān)控發(fā)現(xiàn)服務(wù)器CPU利用率持續(xù)超過90%，觸發(fā)預(yù)警。該操作屬于（）。A.性能管理B.故障管理C.配置管理D.容量管理答案：A解析：性能管理通過監(jiān)控關(guān)鍵指標(biāo)（如CPU、內(nèi)存利用率）評估系統(tǒng)運(yùn)行狀態(tài)，預(yù)警屬于性能管理的主動(dòng)控制環(huán)節(jié)。7.某企業(yè)部署私有云平臺(tái)，采用VMwarevSphere技術(shù)。管理員通過（）實(shí)現(xiàn)虛擬機(jī)的資源動(dòng)態(tài)分配。A.vMotionB.vSANC.HA（高可用性）D.DRS（動(dòng)態(tài)資源調(diào)度）答案：D解析：DRS（動(dòng)態(tài)資源調(diào)度）用于根據(jù)負(fù)載自動(dòng)調(diào)整虛擬機(jī)的資源分配，vMotion是虛擬機(jī)遷移技術(shù)，HA是故障恢復(fù)，vSAN是存儲(chǔ)解決方案。8.以下關(guān)于信息系統(tǒng)項(xiàng)目風(fēng)險(xiǎn)管理的描述，錯(cuò)誤的是（）。A.風(fēng)險(xiǎn)識別應(yīng)在項(xiàng)目啟動(dòng)階段完成B.風(fēng)險(xiǎn)評估包括定性評估和定量評估C.風(fēng)險(xiǎn)應(yīng)對策略包括規(guī)避、轉(zhuǎn)移、減輕、接受D.風(fēng)險(xiǎn)監(jiān)控需貫穿項(xiàng)目全生命周期答案：A解析：風(fēng)險(xiǎn)識別是一個(gè)持續(xù)過程，需在項(xiàng)目各階段動(dòng)態(tài)更新，啟動(dòng)階段完成初始識別但非全部。9.某系統(tǒng)需要支持跨地域分支機(jī)構(gòu)的數(shù)據(jù)同步，要求延遲低于50ms。最適合的網(wǎng)絡(luò)架構(gòu)是（）。A.公網(wǎng)VPNB.MPLSVPNC.互聯(lián)網(wǎng)直連D.衛(wèi)星通信答案：B解析：MPLSVPN通過專用鏈路提供低延遲、高可靠性的廣域網(wǎng)連接，適合跨地域企業(yè)數(shù)據(jù)同步；公網(wǎng)VPN延遲較高，衛(wèi)星通信延遲通常超過100ms。10.在數(shù)據(jù)倉庫設(shè)計(jì)中，維度表的作用是（）。A.存儲(chǔ)事實(shí)數(shù)據(jù)的度量值B.提供上下文信息以分析事實(shí)C.優(yōu)化數(shù)據(jù)查詢性能D.實(shí)現(xiàn)數(shù)據(jù)的ETL轉(zhuǎn)換答案：B解析：維度表用于描述事實(shí)數(shù)據(jù)的環(huán)境（如時(shí)間、地點(diǎn)、產(chǎn)品），為事實(shí)表提供分析維度，是數(shù)據(jù)倉庫多維分析的基礎(chǔ)。11.某企業(yè)實(shí)施ERP系統(tǒng)，上線后發(fā)現(xiàn)采購流程審批節(jié)點(diǎn)遺漏關(guān)鍵部門。該問題最可能源于（）階段的缺陷。A.需求分析B.系統(tǒng)設(shè)計(jì)C.系統(tǒng)測試D.運(yùn)維優(yōu)化答案：A解析：需求分析階段未完整識別關(guān)鍵部門的審批需求，導(dǎo)致后續(xù)流程設(shè)計(jì)遺漏，屬于需求獲取不充分。12.信息系統(tǒng)審計(jì)中，檢查系統(tǒng)日志是否完整記錄用戶登錄、操作和退出時(shí)間，屬于（）審計(jì)內(nèi)容。A.安全性B.可用性C.完整性D.合規(guī)性答案：A解析：日志完整性是安全審計(jì)的核心指標(biāo)，用于追蹤用戶行為、發(fā)現(xiàn)潛在安全事件。13.以下不屬于IT服務(wù)連續(xù)性管理（ITSCM）關(guān)鍵活動(dòng)的是（）。A.業(yè)務(wù)影響分析（BIA）B.風(fēng)險(xiǎn)評估C.服務(wù)級別協(xié)議（SLA）制定D.災(zāi)難恢復(fù)計(jì)劃（DRP）測試答案：C解析：ITSCM關(guān)注業(yè)務(wù)中斷后的恢復(fù)能力，包括BIA、風(fēng)險(xiǎn)評估、DRP制定與測試；SLA是服務(wù)水平的約定，屬于服務(wù)級別管理。14.某系統(tǒng)采用敏捷開發(fā)模式，迭代周期為2周。在第3次迭代中，客戶提出新增功能需求。正確的處理方式是（）。A.立即停止當(dāng)前迭代，調(diào)整需求B.將需求加入待辦事項(xiàng)列表（Backlog），后續(xù)迭代評估C.直接修改當(dāng)前迭代的用戶故事（UserStory）D.要求客戶等待下一個(gè)大版本更新答案：B解析：敏捷開發(fā)中，需求變更需通過Backlog管理，當(dāng)前迭代目標(biāo)固定，新需求進(jìn)入待辦列表后由團(tuán)隊(duì)評估優(yōu)先級，在后續(xù)迭代中處理。15.信息系統(tǒng)的可用性計(jì)算公式為（）。A.（總時(shí)間停機(jī)時(shí)間）/總時(shí)間×100%B.（停機(jī)時(shí)間/總時(shí)間）×100%C.（平均無故障時(shí)間/平均修復(fù)時(shí)間）×100%D.（平均修復(fù)時(shí)間/平均無故障時(shí)間）×100%答案：A解析：可用性通常用系統(tǒng)正常運(yùn)行時(shí)間占總時(shí)間的比例表示，公式為（總時(shí)間停機(jī)時(shí)間）/總時(shí)間×100%。16.某企業(yè)使用Zabbix監(jiān)控服務(wù)器，設(shè)置CPU利用率超過85%觸發(fā)告警。若服務(wù)器在1小時(shí)內(nèi)CPU利用率為90%（持續(xù)20分鐘）、80%（持續(xù)40分鐘），則該小時(shí)內(nèi)告警觸發(fā)時(shí)長為（）。A.0分鐘B.20分鐘C.40分鐘D.60分鐘答案：B解析：告警觸發(fā)條件是CPU利用率超過85%，僅當(dāng)持續(xù)20分鐘滿足條件時(shí)觸發(fā)，因此告警時(shí)長為20分鐘。17.在信息系統(tǒng)性能優(yōu)化中，數(shù)據(jù)庫索引優(yōu)化屬于（）優(yōu)化策略。A.應(yīng)用層B.數(shù)據(jù)層C.網(wǎng)絡(luò)層D.硬件層答案：B解析：數(shù)據(jù)庫索引直接影響數(shù)據(jù)存儲(chǔ)和查詢效率，屬于數(shù)據(jù)層優(yōu)化；應(yīng)用層優(yōu)化涉及代碼邏輯，網(wǎng)絡(luò)層涉及帶寬/延遲，硬件層涉及服務(wù)器配置。18.以下關(guān)于信息系統(tǒng)文檔管理的描述，正確的是（）。A.開發(fā)文檔僅需在項(xiàng)目結(jié)束時(shí)編寫B(tài).用戶文檔應(yīng)使用技術(shù)術(shù)語以確保準(zhǔn)確性C.文檔版本需與系統(tǒng)版本一一對應(yīng)D.電子文檔無需保留紙質(zhì)備份答案：C解析：文檔版本與系統(tǒng)版本對應(yīng)可確保追溯性；開發(fā)文檔需在各階段同步編寫，用戶文檔應(yīng)避免技術(shù)術(shù)語，關(guān)鍵電子文檔需紙質(zhì)備份。19.某系統(tǒng)采用負(fù)載均衡技術(shù)，當(dāng)主服務(wù)器故障時(shí)，流量自動(dòng)切換到備用服務(wù)器。該負(fù)載均衡算法最可能是（）。A.輪詢（RoundRobin）B.加權(quán)輪詢（WeightedRoundRobin）C.最少連接（LeastConnections）D.故障轉(zhuǎn)移（Failover）答案：D解析：故障轉(zhuǎn)移算法專門處理服務(wù)器故障場景，自動(dòng)切換流量到健康節(jié)點(diǎn)；其他算法主要用于正常負(fù)載分配。20.信息系統(tǒng)的可維護(hù)性不包括（）。A.可理解性B.可測試性C.可移植性D.可恢復(fù)性答案：D解析：可維護(hù)性包括可理解性、可測試性、可修改性、可移植性；可恢復(fù)性屬于可靠性范疇。二、案例分析題（共3題，每題20分，共60分）案例一：某制造企業(yè)信息系統(tǒng)升級項(xiàng)目某制造企業(yè)計(jì)劃將現(xiàn)有ERP系統(tǒng)升級為支持智能制造的新一代系統(tǒng)，涵蓋生產(chǎn)、采購、銷售、倉儲(chǔ)四大模塊。項(xiàng)目團(tuán)隊(duì)由企業(yè)IT部門、外部軟件供應(yīng)商和業(yè)務(wù)部門代表組成。升級過程中出現(xiàn)以下問題：（1）生產(chǎn)部門反映新系統(tǒng)的排產(chǎn)邏輯與實(shí)際工藝要求不符，導(dǎo)致工單錯(cuò)誤率上升30%；（2）采購模塊上線后，供應(yīng)商協(xié)同接口頻繁報(bào)錯(cuò)，影響原材料到貨及時(shí)性；（3）項(xiàng)目進(jìn)度延遲2周，成本超支15%。問題1：分析問題（1）產(chǎn)生的可能原因。（6分）問題2：針對問題（2），提出至少3項(xiàng)解決方案。（8分）問題3：結(jié)合項(xiàng)目管理知識，說明如何應(yīng)對進(jìn)度延遲和成本超支。（6分）答案：問題1：可能原因包括：①需求分析階段未充分調(diào)研生產(chǎn)部門實(shí)際工藝要求，需求規(guī)格說明書與業(yè)務(wù)場景脫節(jié)；②系統(tǒng)開發(fā)過程中未邀請生產(chǎn)部門參與原型測試，導(dǎo)致排產(chǎn)邏輯未驗(yàn)證；③需求變更管理缺失，生產(chǎn)部門后期提出的工藝調(diào)整未及時(shí)納入系統(tǒng)優(yōu)化。問題2：解決方案：①檢查供應(yīng)商協(xié)同接口的技術(shù)文檔，確認(rèn)數(shù)據(jù)格式（如JSON/XML）、通信協(xié)議（如HTTP/REST）是否與供應(yīng)商系統(tǒng)匹配；②在測試環(huán)境模擬接口交互，使用抓包工具（如Wireshark）分析報(bào)錯(cuò)日志，定位網(wǎng)絡(luò)延遲或數(shù)據(jù)校驗(yàn)失敗點(diǎn)；③與供應(yīng)商簽訂接口聯(lián)調(diào)備忘錄，明確雙方技術(shù)對接人及問題響應(yīng)時(shí)限（如4小時(shí)內(nèi)反饋）；④對采購模塊接口增加重試機(jī)制（如失敗后自動(dòng)重試3次）和異常日志記錄功能，便于追溯問題。問題3：應(yīng)對措施：①重新評估項(xiàng)目關(guān)鍵路徑，識別延遲的關(guān)鍵活動(dòng)（如生產(chǎn)模塊排產(chǎn)邏輯修復(fù)），通過并行處理非關(guān)鍵活動(dòng)（如銷售模塊培訓(xùn)）壓縮總工期；②分析成本超支原因（如需求變更、外部資源加價(jià)），與供應(yīng)商協(xié)商調(diào)整合同條款（如固定成本部分重新定價(jià)）；③建立每日站會(huì)機(jī)制，跟蹤剩余工作量和資源使用情況，及時(shí)調(diào)配冗余資源（如從倉儲(chǔ)模塊抽調(diào)開發(fā)人員支援生產(chǎn)模塊）；④更新項(xiàng)目管理計(jì)劃，將延遲影響通知相關(guān)方（如管理層、業(yè)務(wù)部門），調(diào)整后續(xù)里程碑時(shí)間節(jié)點(diǎn)。案例二：某銀行信息系統(tǒng)安全事件某銀行核心交易系統(tǒng)在凌晨2:003:00出現(xiàn)交易中斷，經(jīng)排查發(fā)現(xiàn)：系統(tǒng)日志顯示數(shù)據(jù)庫服務(wù)器CPU利用率在2:15達(dá)到100%，持續(xù)10分鐘；數(shù)據(jù)庫連接數(shù)從正常的200并發(fā)驟增至800并發(fā)；防火墻記錄顯示有大量來自IP段/24的請求，其中部分請求包含SQL注入特征。問題1：判斷該事件的類型，并說明依據(jù)。（6分）問題2：描述事件處理的關(guān)鍵步驟。（8分）問題3：提出3項(xiàng)后續(xù)改進(jìn)措施以防止類似事件。（6分）答案：問題1：事件類型為混合攻擊事件，包含DDoS攻擊和SQL注入攻擊。依據(jù)：①數(shù)據(jù)庫連接數(shù)驟增（800并發(fā)遠(yuǎn)超正常200）和CPU滿載，符合DDoS攻擊特征；②防火墻記錄顯示大量來自同一IP段的請求，且包含SQL注入特征，說明存在針對數(shù)據(jù)庫的惡意代碼注入嘗試。問題2：處理步驟：①立即啟動(dòng)應(yīng)急預(yù)案，切換至災(zāi)備系統(tǒng)恢復(fù)交易服務(wù)（15分鐘內(nèi)完成）；②隔離受攻擊的數(shù)據(jù)庫服務(wù)器，斷開與公網(wǎng)連接，避免攻擊擴(kuò)散；③收集攻擊證據(jù)（如日志、網(wǎng)絡(luò)流量包），使用安全工具（如Splunk）分析攻擊源和手段；④修復(fù)數(shù)據(jù)庫漏洞（如關(guān)閉未使用的端口、加強(qiáng)SQL語句參數(shù)校驗(yàn)），重啟主系統(tǒng)并驗(yàn)證功能正常；⑤向監(jiān)管部門（如銀保監(jiān)會(huì)）和客戶通報(bào)事件情況，說明影響范圍及已采取的措施。問題3：改進(jìn)措施：①在網(wǎng)絡(luò)入口部署WAF（Web應(yīng)用防火墻），對SQL注入、XSS等攻擊進(jìn)行實(shí)時(shí)攔截；②配置數(shù)據(jù)庫連接數(shù)閾值（如最大500并發(fā)），超過閾值自動(dòng)拒絕新連接并告警；③對核心系統(tǒng)實(shí)施流量清洗（通過DDoS防護(hù)設(shè)備識別并過濾異常流量）；④定期進(jìn)行滲透測試和漏洞掃描，重點(diǎn)關(guān)注數(shù)據(jù)庫和接口安全；⑤加強(qiáng)員工安全培訓(xùn)，禁止使用弱口令，定期輪換數(shù)據(jù)庫管理員賬號密碼。案例三：某電商企業(yè)IT服務(wù)運(yùn)維優(yōu)化某電商企業(yè)年交易額超500億元，現(xiàn)有IT運(yùn)維團(tuán)隊(duì)30人，負(fù)責(zé)1000臺(tái)服務(wù)器、50個(gè)業(yè)務(wù)系統(tǒng)的運(yùn)維。近期用戶投訴量上升25%，主要問題包括：系統(tǒng)故障響應(yīng)時(shí)間平均45分鐘（SLA要求≤30分鐘）；每月因補(bǔ)丁升級導(dǎo)致的業(yè)務(wù)中斷次數(shù)達(dá)8次（目標(biāo)≤2次）；運(yùn)維文檔分散在個(gè)人電腦，新員工入職后需1個(gè)月才能獨(dú)立處理問題。問題1：分析用戶投訴上升的根本原因。（6分）問題2：設(shè)計(jì)IT服務(wù)運(yùn)維優(yōu)化方案（需包含工具、流程、人員三方面）。（8分）問題3：說明如何評估優(yōu)化效果。（6分）答案：問題1：根本原因：①運(yùn)維流程不規(guī)范，故障響應(yīng)缺乏分級處理機(jī)制（如未定義P1P4級故障的響應(yīng)時(shí)限）；②變更管理缺失，補(bǔ)丁升級前未進(jìn)行充分測試（如灰度發(fā)布），導(dǎo)致意外中斷；③知識管理混亂，運(yùn)維經(jīng)驗(yàn)未沉淀為標(biāo)準(zhǔn)化文檔，新員工培訓(xùn)效率低；④監(jiān)控工具落后，無法實(shí)時(shí)發(fā)現(xiàn)潛在故障（如服務(wù)器性能預(yù)警閾值設(shè)置不合理）。問題2：優(yōu)化方案：工具方面：部署一體化運(yùn)維平臺(tái)（如Zabbix+ITSM系統(tǒng)），集成監(jiān)控（CPU/內(nèi)存/網(wǎng)絡(luò)）、事件管理、變更管理模塊，實(shí)現(xiàn)故障自動(dòng)觸發(fā)工單；流程方面：①建立故障分級制度（P1級故障15分鐘響應(yīng)，P2級30分鐘），明確各層級處理責(zé)任人；②實(shí)施變更管理流程：補(bǔ)丁升級前需通過測試環(huán)境驗(yàn)證（覆蓋90%業(yè)務(wù)場景），采用灰度發(fā)布（先升級10%服務(wù)器），無異常后全量推廣；③完善知識管理流程：要求運(yùn)維人員處理問題后48小時(shí)內(nèi)將解決方案錄入企業(yè)知識庫（如Confluence），設(shè)置審核機(jī)制確保內(nèi)容準(zhǔn)確性；人員方面：①按業(yè)務(wù)系統(tǒng)劃分運(yùn)維小組（如電商交