系統(tǒng)規(guī)劃與管理師真題與練習題含答案系統(tǒng)規(guī)劃與管理師考試作為信息技術(shù)服務領(lǐng)域的重要認證，其考核內(nèi)容涵蓋信息技術(shù)基礎、IT服務管理體系、服務運營與改進、應急響應與風險管理等核心模塊。以下通過典型真題與練習題的深度解析，幫助考生理解考試重點與解題邏輯。一、單項選擇題（每題2分，共20分）1.以下關(guān)于IT服務生命周期的描述中，正確的是：A.規(guī)劃設計階段僅需完成服務目錄的編制B.部署實施階段的核心是服務級別協(xié)議（SLA）的簽訂C.服務運營階段需持續(xù)監(jiān)控服務性能并記錄事件D.持續(xù)改進階段僅針對技術(shù)故障進行優(yōu)化答案：C解析：IT服務生命周期包括規(guī)劃設計、部署實施、服務運營、持續(xù)改進、監(jiān)督管理五個階段。規(guī)劃設計階段需完成服務方案、SLA、服務目錄等多維度設計（A錯誤）；部署實施階段的核心是將設計方案落地，包括資源部署、人員培訓等（B錯誤）；服務運營階段通過監(jiān)控、事件管理、問題管理等活動保障服務穩(wěn)定運行（C正確）；持續(xù)改進需覆蓋服務全流程，不僅限于技術(shù)故障（D錯誤）。2.某企業(yè)IT部門需制定服務臺管理規(guī)范，以下不屬于服務臺核心職能的是：A.接收用戶請求并記錄B.對簡單問題進行一線解決C.分析問題根本原因（RCA）D.協(xié)調(diào)二線/三線技術(shù)團隊支持答案：C解析：服務臺的核心職能是用戶接口、事件記錄與初步處理、協(xié)調(diào)支持，而問題根本原因分析屬于問題管理的范疇（通常由二線或三線團隊負責），因此C不屬于服務臺職能。3.根據(jù)《信息技術(shù)服務運行維護第1部分：通用要求》（GB/T28827.1-2012），運行維護服務能力成熟度模型（SACM）的四個等級從低到高依次是：A.基本級、拓展級、改進（協(xié)同）級、優(yōu)化（量化）級B.初始級、重復級、定義級、管理級C.基礎級、整合級、優(yōu)化級、創(chuàng)新級D.入門級、提高級、成熟級、卓越級答案：A解析：GB/T28827.1標準明確SACM的四個等級為基本級（一級）、拓展級（二級）、改進（協(xié)同）級（三級）、優(yōu)化（量化）級（四級），對應能力從基礎執(zhí)行到量化優(yōu)化的逐步提升。4.某系統(tǒng)因數(shù)據(jù)庫服務器磁盤空間不足導致服務中斷，此故障的根本原因最可能屬于：A.人員操作失誤B.資源容量不足C.網(wǎng)絡鏈路故障D.安全攻擊答案：B解析：磁盤空間不足直接指向存儲資源的容量管理問題，屬于資源容量不足導致的故障（B正確）。其他選項中，操作失誤（A）需有明確的誤操作記錄，網(wǎng)絡故障（C）表現(xiàn)為連接中斷，安全攻擊（D）通常伴隨異常訪問日志，均與題干描述不符。5.在IT服務風險管理中，以下屬于風險控制措施的是：A.購買IT服務中斷保險B.定期進行漏洞掃描C.記錄風險事件臺賬D.分析風險發(fā)生概率答案：B解析：風險控制措施包括規(guī)避、降低、轉(zhuǎn)移、接受等。定期漏洞掃描（B）屬于降低風險的主動措施；購買保險（A）是風險轉(zhuǎn)移；記錄臺賬（C）是風險監(jiān)控；分析概率（D）是風險評估，均不屬于控制措施。---二、案例分析題（每題20分，共40分）案例1：服務中斷應急響應某企業(yè)部署了ERP系統(tǒng)支撐核心業(yè)務，某天上午10:00，用戶反饋無法登錄系統(tǒng)，IT服務團隊立即啟動應急響應流程。經(jīng)初步排查，發(fā)現(xiàn)數(shù)據(jù)庫服務器無響應，ping通但遠程連接失敗。團隊嘗試重啟數(shù)據(jù)庫服務未成功，10:30確認數(shù)據(jù)庫物理機宕機，需更換備用服務器。11:15備用服務器部署完成，數(shù)據(jù)同步后系統(tǒng)恢復，11:30用戶確認業(yè)務正常。問題1：請描述IT服務應急響應的標準流程，并指出案例中未明確執(zhí)行的關(guān)鍵步驟。問題2：為避免同類故障再次發(fā)生，應采取哪些預防措施？答案與解析：問題1：標準應急響應流程通常包括：①事件檢測與確認（發(fā)現(xiàn)用戶反饋，驗證系統(tǒng)狀態(tài)）；②初步評估與分級（判斷影響范圍、緊急程度）；③啟動應急預案（根據(jù)預設流程調(diào)配資源）；④故障排查與恢復（定位原因，實施恢復措施）；⑤記錄與報告（記錄過程、通知相關(guān)方）；⑥事后總結(jié)與改進（分析根本原因，優(yōu)化預防措施）。案例中未明確執(zhí)行的步驟：-初步評估與分級：未提及對故障影響范圍（如涉及部門、業(yè)務量）的評估及分級（如一級/二級故障）；-記錄與未明確是否向管理層、用戶及時同步故障進展；-事后總結(jié)：案例僅描述恢復過程，未涉及根本原因分析和改進計劃。問題2：預防措施應包括：①容量管理：定期監(jiān)控數(shù)據(jù)庫服務器的磁盤空間、內(nèi)存、CPU利用率，設置閾值告警；②冗余部署：采用數(shù)據(jù)庫集群（如主備復制、讀寫分離）或云數(shù)據(jù)庫的高可用方案，避免單點故障；③備份與恢復驗證：加強數(shù)據(jù)庫定期備份（全量+增量），并定期測試備份數(shù)據(jù)的可恢復性；④應急預案優(yōu)化：明確物理機宕機時的備用服務器切換流程（如自動切換腳本、人工操作手冊），縮短恢復時間；⑤培訓與演練：組織團隊進行應急演練，熟悉故障排查步驟，提升響應效率。---案例2：服務級別協(xié)議（SLA）管理某IT服務提供商與客戶簽訂SLA，約定“關(guān)鍵業(yè)務系統(tǒng)可用性不低于99.9%，故障修復時間（MTTR）≤4小時”。運行3個月后，客戶投訴稱系統(tǒng)月度可用性僅99.8%，且某次故障修復耗時5小時。服務提供商核查發(fā)現(xiàn)：-可用性統(tǒng)計未包含非工作時間（晚18:00至次日早8:00）的系統(tǒng)停機；-故障修復時間計算未扣除等待客戶提供權(quán)限的2小時。問題1：指出SLA執(zhí)行中的爭議點，并說明SLA設計應遵循的原則。問題2：服務提供商應如何改進SLA管理以提升客戶滿意度？答案與解析：問題1：爭議點分析：①可用性統(tǒng)計范圍：SLA未明確“關(guān)鍵業(yè)務系統(tǒng)”的服務時間是否包含非工作時間。若客戶要求7×24小時可用，而提供商僅統(tǒng)計工作時間，則可用性計算不完整；②MTTR定義歧義：故障修復時間是否包含等待客戶配合的時間（如權(quán)限提供）。若SLA中MTTR指“從故障報告到完全恢復的總時長”，則等待時間應計入；若指“技術(shù)團隊實際處理時間”，則需明確排除外部依賴時間。SLA設計原則：-明確性：術(shù)語定義（如“可用性”“MTTR”）、統(tǒng)計范圍（時間、系統(tǒng)）需清晰；-可測量性：指標需量化（如99.9%=每月≤43.2分鐘停機）；-雙方共識：需客戶與服務提供商共同確認，避免單方解釋；-可實現(xiàn)性：指標需基于當前技術(shù)能力和資源，避免過度承諾；-動態(tài)調(diào)整：根據(jù)業(yè)務需求變化定期評審和更新。問題2：改進措施：①重新修訂SLA條款：明確服務時間范圍（如7×24小時或5×8小時）、MTTR的計算方式（是否包含外部等待時間），并與客戶簽字確認；②優(yōu)化監(jiān)控與統(tǒng)計工具：采用自動化監(jiān)控系統(tǒng)，準確記錄系統(tǒng)停機時間（包括非工作時間），避免人工統(tǒng)計誤差；③加強客戶溝通：在故障處理過程中，及時告知客戶等待原因（如權(quán)限需求），并協(xié)商是否將該時間計入MTTR；④建立SLA執(zhí)行報告機制：每月向客戶提交服務性能報告，包含可用性、MTTR等指標的達成情況及未達標原因分析；⑤完善補救措施：在SLA中約定未達標的補償方案（如服務時長延長、費用折扣），提升客戶信任。---三、綜合應用題（40分）某制造企業(yè)計劃建立IT服務管理體系，委托你作為系統(tǒng)規(guī)劃與管理師負責規(guī)劃設計。企業(yè)現(xiàn)狀如下：-現(xiàn)有IT系統(tǒng)：ERP（生產(chǎn)）、OA（辦公）、MES（車間）、CRM（銷售），分屬不同廠商部署；-問題痛點：故障響應慢（平均8小時）、跨系統(tǒng)問題推諉（如ERP與MES數(shù)據(jù)同步異常）、用戶滿意度65%（行業(yè)平均80%）；-資源條件：IT團隊15人（開發(fā)5人、運維8人、管理2人），年度預算80萬元。請設計IT服務管理體系的規(guī)劃方案，要求包含以下內(nèi)容：1.目標設定（3項核心目標）；2.關(guān)鍵實施步驟（5步以上）；3.資源配置建議（人員、工具、預算分配）；4.預期效果（3項以上）。答案與解析：1.核心目標設定①服務響應效率提升：將故障平均修復時間（MTTR）從8小時縮短至4小時內(nèi)；②跨系統(tǒng)協(xié)作優(yōu)化：消除跨系統(tǒng)問題推諉，建立統(tǒng)一的問題責任判定機制，問題解決及時率提升至90%以上；③用戶滿意度提升：6個月內(nèi)用戶滿意度從65%提高至80%（達到行業(yè)平均水平）。2.關(guān)鍵實施步驟①現(xiàn)狀調(diào)研與需求分析：通過訪談、問卷收集用戶（生產(chǎn)、銷售、車間等部門）的痛點，梳理現(xiàn)有IT系統(tǒng)的交互關(guān)系（如ERP與MES的數(shù)據(jù)接口），分析故障日志定位高頻問題（如接口不穩(wěn)定、權(quán)限配置錯誤）。②流程設計與優(yōu)化：基于ITIL4或ITSS標準，設計覆蓋事件管理、問題管理、變更管理的端到端流程。例如，事件管理流程需明確一線（服務臺）、二線（運維）、三線（開發(fā)/廠商）的分級響應時限；問題管理需建立根本原因分析（RCA）模板，避免同類故障重復發(fā)生。③組織架構(gòu)調(diào)整：設立專職服務臺（2人），負責統(tǒng)一接收用戶請求并分診；將運維團隊按系統(tǒng)分組（ERP/MES組、OA/CRM組），每組指定接口人，解決跨系統(tǒng)問題時由服務臺協(xié)調(diào)接口人共同處理，避免推諉。④工具平臺部署：采購或開發(fā)IT服務管理（ITSM）系統(tǒng)，集成監(jiān)控工具（如Zabbix監(jiān)控服務器性能）、CMDB（配置管理數(shù)據(jù)庫，記錄系統(tǒng)間接口信息），實現(xiàn)事件自動告警、派單、跟蹤閉環(huán)。⑤培訓與試運行：對IT團隊進行流程與工具操作培訓，選取OA系統(tǒng)作為試點，運行1個月后收集反饋，優(yōu)化流程細節(jié)（如調(diào)整派單規(guī)則、縮短二線響應時限）。⑥全面推廣與持續(xù)改進：試點通過后，將ITSM系統(tǒng)擴展至所有業(yè)務系統(tǒng)，每月召開服務評審會，分析SLA達成情況（如MTTR、問題解決率），針對未達標項制定改進計劃（如增加第三方廠商支持協(xié)議）。3.資源配置建議①人員：-服務臺：2人（需具備基礎技術(shù)知識，溝通能力強）；-運維分組：ERP/MES組3人、OA/CRM組3人（原運維8人調(diào)整）；-開發(fā)支持：保留5人，負責定制化開發(fā)與接口優(yōu)化；-管理崗：2人（負責流程監(jiān)督、客戶溝通）。②工具：-ITSM系統(tǒng)：預算30萬元（采購成熟產(chǎn)品，如ManageEngine）；-監(jiān)控工具：10萬元（Zabbix企業(yè)版或Prometheus定制）；-CMDB初始化：5萬元（梳理配置項并錄入）。③預算分配：工具采購45萬元，人員培訓（外部講師+內(nèi)部材料）5萬元，第三方支持（如廠商接口優(yōu)化）20萬元，應急儲備10萬元（總預算80萬元）。4.預期效果①效率提