2025上半年高級軟件水平考試《系統(tǒng)規(guī)劃與管理師(案例分析)》練習(xí)題及答案一、綜合案例分析（共3題，每題25分，滿分75分）【案例背景】某省級“智慧城市運營中心”項目于2023年10月啟動，總投資4.2億元，建設(shè)周期24個月。項目采用“1+3+N”架構(gòu)：1個城市大腦中樞平臺、3大基礎(chǔ)能力中心（數(shù)據(jù)、AI、數(shù)字孿生）、N個智慧應(yīng)用（交通、應(yīng)急、環(huán)保、社區(qū)等）。甲方為省大數(shù)據(jù)局，乙方為某上市系統(tǒng)集成商（以下簡稱A公司），丙方為監(jiān)理單位。2024年12月，項目進入試運行，但甲方連續(xù)三次發(fā)出《整改通知單》，集中反映以下問題：1.運維組織未建立，一線值班電話無人接聽；2.SLA未量化，僅模糊描述“盡快處理”；3.知識庫空白，故障重復(fù)發(fā)生率38%；4.供應(yīng)商管理缺失，AI算法升級導(dǎo)致GPU利用率驟降60%，無回溯機制；5.預(yù)算超支21%，其中70%為運維期額外采購。A公司任命你為新任系統(tǒng)規(guī)劃與管理師，要求你在2025年2月底前完成整改，確保2025年6月順利通過終驗。【題目1】（25分）結(jié)合案例，請指出該項目在“系統(tǒng)規(guī)劃”階段存在的5項關(guān)鍵缺陷，并給出對應(yīng)的補救措施。要求：（1）每項缺陷用“問題描述—影響—補救措施”三段式闡述；（2）補救措施需量化，可驗證；（3）總字?jǐn)?shù)不超過600字。【答案】1.問題描述：未建立以業(yè)務(wù)價值為導(dǎo)向的分層架構(gòu)基線，導(dǎo)致后續(xù)擴容只能垂直堆疊硬件。影響：預(yù)算超支21%，且無法橫向擴展。補救措施：2025年1月15日前，依據(jù)TOGAF重新制定“目標(biāo)架構(gòu)”與“過渡架構(gòu)”，將城市大腦拆分為28個可獨立水平擴展的微服務(wù)；2月底前完成POC，驗證在同等并發(fā)下成本降低≥30%。2.問題描述：可研報告未對數(shù)據(jù)資源做分級分類，僅籠統(tǒng)估算“3PB存儲”。影響：試運行階段發(fā)現(xiàn)視頻結(jié)構(gòu)化數(shù)據(jù)增長超預(yù)期400%，存儲告急。補救措施：1月內(nèi)依據(jù)GB/T352732020完成數(shù)據(jù)分類分級，熱溫冷數(shù)據(jù)比例按1:3:6設(shè)計；2月底前通過藍光歸檔+對象存儲生命周期策略，使年度存儲成本下降≥25%。3.問題描述：未在規(guī)劃階段設(shè)置“可觀測性”非功能需求，導(dǎo)致故障定位平均耗時92分鐘。影響：SLA無法承諾。補救措施：1月內(nèi)補充《非功能需求規(guī)格書》，明確TraceID透傳率100%、Metrics采樣率≥10%；2月底前通過Grafana+Prometheus實現(xiàn)P99故障定位時間≤15分鐘。4.問題描述：未將“運維組織設(shè)計”納入規(guī)劃，角色、職責(zé)、預(yù)算缺位。影響：值班電話無人接聽。補救措施：1月內(nèi)采用ITIL4設(shè)計“三級運維”體系，設(shè)置1個指揮崗、6個專業(yè)崗、18一線崗；2月底前完成人員招聘及外包合同簽署，確保7×24小時接通率≥99.9%。5.問題描述：未在規(guī)劃階段識別關(guān)鍵供應(yīng)商技術(shù)鎖定風(fēng)險，未設(shè)置退出條款。影響：GPU利用率驟降60%時無法索賠。補救措施：1月內(nèi)補充《供應(yīng)商管理計劃》，設(shè)置源碼托管、性能基線、違約金20%；2月底前完成與GPU廠商簽訂補充協(xié)議，若再出現(xiàn)性能回退≥10%，按日違約金1‰?！窘馕觥肯到y(tǒng)規(guī)劃的核心是“把不確定變成可度量的確定性”。本案例的5項缺陷均源于“可度量”缺失：架構(gòu)無基線、數(shù)據(jù)無量化、可觀測性無指標(biāo)、組織無編制、供應(yīng)商無約束。補救措施全部給出量化驗證指標(biāo)，確保整改結(jié)果可被終驗審計復(fù)核?！绢}目2】（25分）甲方要求2025年3月1日前正式發(fā)布《運維服務(wù)級別協(xié)議（SLA）》，覆蓋事件、問題、變更、容量、信息安全五大流程。請根據(jù)案例數(shù)據(jù)，設(shè)計一套可落地的SLA框架，要求：（1）為每個流程給出2項核心指標(biāo)（KPI）、測量方法、計算公式、目標(biāo)值；（2）給出違約賠付條款，單條罰款不超過合同總額的1%；（3）用表格呈現(xiàn)，并附200字以內(nèi)實施要點?！敬鸢浮勘?智慧城市運營中心SLA框架（2025版）|流程|KPI|測量方法|計算公式|目標(biāo)值|違約賠付|||||||||事件|一線首次響應(yīng)時間|工單系統(tǒng)時間戳|Tr=T接單T建單|≤10分鐘|每超1分鐘扣800元||事件|事件解決時間（P1）|工單關(guān)閉時間戳|Ts=T關(guān)閉T建單|≤2小時|每超1小時扣2000元||問題|問題關(guān)閉率|月度統(tǒng)計|R關(guān)閉=關(guān)閉數(shù)/總數(shù)|≥95%|每低1%扣5000元||問題|重復(fù)故障率|季度統(tǒng)計|R重復(fù)=重復(fù)故障數(shù)/總故障數(shù)|≤5%|每高1%扣3000元||變更|變更成功率|變更窗口統(tǒng)計|R成功=成功數(shù)/總數(shù)|≥99%|每低1%扣6000元||變更|緊急變更占比|月度統(tǒng)計|R緊急=緊急變更數(shù)/總數(shù)|≤3%|每高1%扣2000元||容量|關(guān)鍵組件利用率|Prometheus采樣|U=avg(cpu|mem|io)|≤70%|每高1%扣1000元||容量|容量預(yù)測偏差|季度對比|Δ=|預(yù)測實際|/實際|≤10%|每高1%扣1500元||信息安全|高危漏洞修復(fù)時長|掃描報告時間戳|T修復(fù)=修復(fù)發(fā)現(xiàn)|≤30天|每超1天扣1000元||信息安全|數(shù)據(jù)泄露事件|審計日志|0事件|0|每發(fā)生1次扣合同總額1%|實施要點：1.工具鏈：工單系統(tǒng)+Prometheus+ELK+漏洞掃描平臺，全部接入統(tǒng)一時鐘源，確保時間戳誤差<1秒。2.數(shù)據(jù)采樣：事件、問題、變更數(shù)據(jù)按分鐘級同步；容量指標(biāo)按15秒采樣，保留90天原始數(shù)據(jù)備審。3.賠付封頂：同一自然月內(nèi)，同一KPI多次違約，按累計值計算但不超過合同總額1%；總額亦不超過合同總額5%。4.爭議仲裁：引入第三方SaaS監(jiān)控平臺（如Catchpoint）做外部探針，甲乙雙方共管，數(shù)據(jù)不可篡改。【解析】SLA設(shè)計必須“可測量、可回溯、可仲裁”。本框架所有指標(biāo)均基于系統(tǒng)原生時間戳，避免人工粉飾；計算公式采用國際標(biāo)準(zhǔn)，目標(biāo)值參考ITIL4與ISO/IEC200001:2018高階基準(zhǔn)；違約賠付采用“線性+封頂”模式，既給乙方改進空間，又給甲方補償?shù)拙€。【題目3】（25分）2025年1月，GPU利用率驟降事件引發(fā)甲方強烈不滿。經(jīng)初步排查，系算法供應(yīng)商B公司在1月15日22:00推送了新版CNN模型，導(dǎo)致顯存泄漏。A公司運維部在1月16日08:00才發(fā)現(xiàn)異常，期間城市大腦交通視頻分析模塊累計丟失抓拍數(shù)據(jù)約42萬條。甲方要求：1.48小時內(nèi)給出根因分析報告；2.1周內(nèi)建立供應(yīng)商軟件版本準(zhǔn)入機制；3.1個月內(nèi)實現(xiàn)同類故障提前5分鐘預(yù)警。請完成以下任務(wù)：（1）用“5Whys”法寫出根因分析報告（不超過300字）；（2）設(shè)計一份《供應(yīng)商軟件版本準(zhǔn)入檢查表》，至少包含10項檢查點；（3）給出實現(xiàn)“提前5分鐘預(yù)警”的技術(shù)方案，含數(shù)據(jù)源、算法、閾值、通知鏈路與驗證方法?！敬鸢浮浚?）5Whys根因分析報告1.為什么GPU利用率驟降？→顯存泄漏。2.為什么顯存泄漏未被發(fā)現(xiàn)？→無GPU進程級監(jiān)控。3.為什么無監(jiān)控？→監(jiān)控規(guī)劃階段未將GPU進程顯存增量列為指標(biāo)。4.為什么未列指標(biāo)？→供應(yīng)商管理計劃缺失性能基線要求。5.為什么缺失基線？→A公司未在合同階段約定可觀測性交付物。根因：供應(yīng)商管理流程缺位，導(dǎo)致可觀測性需求未閉環(huán)。（2）供應(yīng)商軟件版本準(zhǔn)入檢查表（V1.0）|序號|檢查點|通過標(biāo)準(zhǔn)|驗證方法|責(zé)任人|結(jié)果記錄|||||||||1|版本號規(guī)范|符合語義化版本2.0.0|正則掃描|配置管理員|||2|性能基線報告|提供GPU/CPU/內(nèi)存基線|基準(zhǔn)測試平臺|性能測試工程師|||3|顯存泄漏測試|連續(xù)運行6小時，泄漏<10MB|Valgrind+Nsight|開發(fā)工程師|||4|回滾策略|提供一鍵回滾腳本且≤5分鐘|演練記錄|運維工程師|||5|灰度方案|支持按10%、30%、100%灰度|文檔評審|SRE|||6|可觀測性指標(biāo)|暴露Prometheus指標(biāo)≥20項|指標(biāo)review|監(jiān)控工程師|||7|安全掃描|高危漏洞=0|安全掃描報告|安全工程師|||8|代碼diff評審|變更行覆蓋率100%|GitLabMR|架構(gòu)師|||9|許可證合規(guī)|無GPL傳染性許可證|FOSSA掃描|法務(wù)|||10|用戶驗收測試|業(yè)務(wù)場景用例通過率100%|甲方簽字|項目經(jīng)理||（3）提前5分鐘預(yù)警技術(shù)方案數(shù)據(jù)源：GPU進程顯存占用量（nvidiasmi，1Hz）顯存增長率（ΔMem/Δt，滑動窗口30s）業(yè)務(wù)請求QPS（KafkaTopictraffic）算法：采用Prophet時間序列預(yù)測+3σ控制圖，預(yù)測未來5分鐘顯存趨勢；若預(yù)測值>當(dāng)前可用顯存85%，觸發(fā)預(yù)警。閾值：顯存預(yù)測上限≥可用85%QPS下降≥20%（防止誤報）通知鏈路：PrometheusAlertmanager→Webhook→飛書機器人@值班+電話；同時自動創(chuàng)建工單，標(biāo)簽“GPULeakWarning”。驗證方法：歷史回放：用1月15日22:00前30分鐘數(shù)據(jù)回放，驗證可提前≥5分鐘發(fā)出Alert；假陽性率：連續(xù)運行2周，假陽性≤2次。【解析】5Whys追到“流程缺位”而非“技術(shù)失誤”，才能避免下次換技術(shù)棧仍重蹈覆轍；準(zhǔn)入檢查表把“可觀測性”固化為門檻，解決“看不見”的問題；預(yù)警方案用“預(yù)測+控制圖”而非簡單閾值，提前量可控，且通過歷史回放驗證，確保真實有效。二、計算與建模（共2題，每題20分，滿分40分）【題目4】（20分）2025年Q1，智慧城市交通視頻分析模塊日均處理視頻流8000路，每路平均碼率2.5Mbps，存儲周期30天。原方案采用高性能對象存儲，單價0.12元/GB/月。為控制成本，A公司擬引入“冷熱分層”策略：熱數(shù)據(jù)（最近7天）仍用原存儲；溫數(shù)據(jù)（第8—30天）遷移至低頻存儲，單價0.08元/GB/月；冷數(shù)據(jù)（30天后）轉(zhuǎn)存藍光光盤庫，一次性寫入成本0.015元/GB，免后續(xù)月租。假設(shè)遷移帶寬無限制，且忽略API請求費用。（1）計算原方案年存儲成本；（2）計算分層后年存儲成本；（3）若要求投資回收期≤6個月，求藍光光盤庫最小可接受單價降幅（百分比）。【答案】（1）原方案年存儲量8000路×2.5Mbps÷8×3600×24×30×12÷1024÷1024≈74166TB≈7.42萬TB年成本=7.42萬TB×1024GB×0.12元×12月≈1.097億元（2）分層后熱數(shù)據(jù)：7/30×7.42萬TB×1024×0.12×12≈2565萬元溫數(shù)據(jù)：23/30×7.42萬TB×1024×0.08×12≈4453萬元冷數(shù)據(jù)：7.42萬TB×1024×0.015元一次性≈1140萬元總成本=2565+4453+1140=8158萬元（3）設(shè)藍光單價下降x，則新一次性成本=1140×(1x)要求6個月回收，即節(jié)省金額≥光盤庫額外投資節(jié)省=原成本新成本=109708158=2812萬元需滿足：1140×x≥2812→x≥246.7%但藍光一次性成本已遠低于原月租，實際無需降價即可滿足回收期。故最小可接受降幅=0%。【解析】題眼在“投資回收期”定義。藍光方案一次性投入即永久節(jié)省月租，因此即使藍光單價不降，也能在首月即收回“光盤庫設(shè)備”投資，故降幅可為0?！绢}目5】（20分）參考ITIL4的“容量管理”實踐，建立城市大腦“交通視頻分析”微服務(wù)的容量模型。已知：單路1080p視頻分析需CPU0.8核、GPU0.3卡、內(nèi)存3GB；日均峰值系數(shù)1.8，季節(jié)系數(shù)1.2；冗余度要求N+1；服務(wù)器規(guī)格：CPU64核/256GB/GPU8卡/臺，單價18萬元/臺；目標(biāo)：支持2026年日均1.2萬路，求（1）所需服務(wù)器數(shù)量；（2）若采用公有云彈性方案，僅保留70%基準(zhǔn)容量，剩余按小時彈性，單價CPU0.05元/核/時、GPU3元/卡/時，計算年成本對比自建節(jié)省金額；（3）給出容量模型敏感性分析結(jié)論（100字以內(nèi)）?！敬鸢浮浚?）峰值路數(shù)=1.2萬×1.8×1.2=25920路需CPU=25920×0.8=20736核GPU=25920×0.3=7776卡N+1冗余，服務(wù)器數(shù)=max(20736/64,7776/8)+1=max(324,972)+1=973臺（2）自建一次性投資=973×18=17514萬元云方案：基準(zhǔn)容量=25920×0.7=18144路基準(zhǔn)CPU=18144×0.8=14515核基準(zhǔn)GPU=18144×0.3=5443卡服務(wù)器數(shù)=max(14515/64,5443/8)+1=max(227,681)+1=682臺年成本=682×18=12276萬元彈性部分=（2592018144）×(0.8×0.05+0.3×3)×24×365÷10000=7776×(0.04+0.9)×8760÷10000=6447萬元總成本=12276+6447=18723萬元節(jié)省=1751418723=1209萬元（云更貴）（3）敏感性結(jié)論：GPU單價權(quán)重最高，若云GPU單價下降30%，云方案即可比自建節(jié)省約8%；季節(jié)系數(shù)每±10%，服務(wù)器數(shù)量±6.7%，呈線性敏感?！窘馕觥咳萘磕Ｐ捅仨毻瑫r考慮峰值、季節(jié)、冗余三因子。本題顯示GPU為瓶頸資源，云GPU單價過高導(dǎo)致云方案不經(jīng)濟；敏感性分析用龍卷風(fēng)圖可直觀呈現(xiàn)GPU單價彈性最大。三、論述題（共1題，滿分35分）【題目6】（35分）結(jié)合《“數(shù)據(jù)要素×”三年行動計劃（2024—2026年）》以及你單位實踐，論述“數(shù)據(jù)運維”與傳統(tǒng)“IT運維”在目標(biāo)、指標(biāo)、流程、工具、組織五個維度的差異，并給出落地路線圖（要求：每個維度先對比差異，再給出落地舉措；整體字?jǐn)?shù)1000—1200字；禁止列框架，需段落式論述）?！敬鸢浮繑?shù)據(jù)運維的核心目標(biāo)是持續(xù)釋放數(shù)據(jù)要素價值，而傳統(tǒng)IT運維的核心目標(biāo)是保障系統(tǒng)可用。前者關(guān)注“數(shù)據(jù)熵減”，后者關(guān)注“系統(tǒng)熵穩(wěn)”。在城市大腦項目中，數(shù)據(jù)運維需確保交通視頻結(jié)構(gòu)化數(shù)據(jù)被AI模型高效消費，進而產(chǎn)生實時信號優(yōu)化價值；IT運維則只需保障攝像頭在線、GPU不宕機即可。目標(biāo)差異帶來指標(biāo)差異。傳統(tǒng)IT運維以“五個9”為最高追求，數(shù)據(jù)運維卻需引入“數(shù)據(jù)新鮮度”“數(shù)據(jù)完整度”“數(shù)據(jù)血緣健康度”等新指標(biāo)。以交通視頻為例，若抓拍數(shù)據(jù)延遲超過信號機周期180秒，即使系統(tǒng)可用性100%，也無法優(yōu)化紅綠燈，數(shù)據(jù)價值歸零。因此，數(shù)據(jù)運維把“端到端數(shù)據(jù)時延P90≤60秒”寫進SLA，與IT運維的“API成功率≥99.9%”并列，形成雙軌指標(biāo)。流程差異體現(xiàn)在“數(shù)據(jù)可觀測性”被前置。傳統(tǒng)事件管理強調(diào)“先恢復(fù)、后根因”，數(shù)據(jù)運維則要求“先定位數(shù)據(jù)斷點、再恢復(fù)”。城市大腦曾出現(xiàn)“視頻流正常但車牌識別字段為空”的怪象，IT運維監(jiān)控顯示GPU利用率99%，卻看不到數(shù)據(jù)斷點。數(shù)據(jù)運維流程強制要求每個A