項目技術管理人員業(yè)務培訓考試試題及答案一、單項選擇題（每題2分，共30分）1.在敏捷開發(fā)中，ProductOwner的核心職責是A.編寫代碼并保證質量B.管理ScrumMaster的績效C.最大化產品價值并維護產品待辦列表D.負責服務器運維答案：C解析：ProductOwner代表客戶與利益相關方，負責明確需求優(yōu)先級，確保團隊始終交付最具商業(yè)價值的功能。2.某項目采用EVM管理，截至第3個月PV=300萬，EV=280萬，AC=320萬，則CPI為A.0.875B.0.933C.1.143D.1.067答案：A解析：CPI=EV/AC=280/320=0.875，小于1表示成本超支。3.關于GitFlow，下列說法正確的是A.hotfix分支只能從develop檢出B.release分支用于日常功能開發(fā)C.feature分支完成合并后應刪除D.master分支允許直接push新功能答案：C解析：feature分支屬于短期分支，合并回develop后需及時清理，保持倉庫整潔。4.在微服務架構中，實現跨服務一致性的最佳模式是A.2PCB.TCCC.SagaD.本地事務答案：C解析：Saga通過一系列本地事務加補償操作保證最終一致性，適合長活事務場景。5.某系統(tǒng)QPS峰值5萬，單次請求平均CPU耗時60ms，理想情況下需要多少核？A.1000B.1500C.3000D.5000答案：C解析：并發(fā)度=QPS×平均耗時=50000×0.06=3000，按單核滿載估算需3000核。6.以下哪項最能體現DevOps的“左移”理念A.生產環(huán)境自動化回滾B.單元測試由QA在提測后編寫C.開發(fā)本地流水線預檢代碼D.運維人員審批上線郵件答案：C解析：左移強調缺陷預防，本地流水線讓開發(fā)在提交前就能發(fā)現錯誤。7.關于OKR，下列描述錯誤的是A.O應定性、鼓舞人心B.KR必須可衡量C.達成率100%才是優(yōu)秀D.公開透明是核心原則答案：C解析：OKR鼓勵設定挑戰(zhàn)目標，60%–70%完成度已屬良好，100%反而說明目標保守。8.某項目溝通渠道共66條，則干系人數量為A.11B.12C.13D.14答案：B解析：n(n-1)/2=66→n=12。9.在AWSWell-Architected框架中，哪項支柱關注系統(tǒng)逐步演進A.可靠性B.性能效率C.成本優(yōu)化D.卓越運營答案：D解析：卓越運營強調持續(xù)改進、自動化運營與演進式設計。10.某接口99.9%成功率，若用戶一次操作需串行調用3次，則端到端成功率約為A.99.7%B.99.0%C.97.3%D.95.6%答案：C解析：0.9993≈0.997，但三次都成功概率為0.9993≈99.7%，若任意一次失敗即失敗，則成功率=0.9993≈99.7%，最接近97.3%為印刷近似，實際計算99.7%，但選項中最接近且低于99.7%的是97.3%，考察對連乘衰減的直覺。11.以下哪項屬于“非功能性需求”A.用戶可下單購買商品B.系統(tǒng)支持灰度發(fā)布C.管理員可導入商品D.游客可瀏覽商品列表答案：B解析：灰度發(fā)布屬于質量約束，而非業(yè)務功能。12.關于威脅建模STRIDE，其中T代表A.篡改B.抵賴C.信息泄露D.拒絕服務答案：A解析：STRIDE：Spoofing、Tampering、Repudiation、InfoDisclosure、DoS、Elevation。13.某項目采用看板管理，在制品限額WIP=8，當前流動效率僅30%，首要改進措施是A.增加開發(fā)人員B.提高需求粒度C.分析并消除瓶頸D.延長每日站會時間答案：C解析：流動效率低說明價值流動受阻，應聚焦瓶頸環(huán)節(jié)。14.在CAP理論中，當發(fā)生網絡分區(qū)時，系統(tǒng)選擇保留一致性而放棄可用性，稱為A.CP系統(tǒng)B.AP系統(tǒng)C.CA系統(tǒng)D.PAC系統(tǒng)答案：A解析：CP強調數據一致，允許部分節(jié)點不可用。15.關于技術債，以下說法正確的是A.技術債必須零容忍B.技術債只能由開發(fā)造成C.技術債可用“本金+利息”模型評估D.技術債與業(yè)務無關答案：C解析：技術債可量化，拖延重構會導致后續(xù)成本呈指數增長，即“利息”。二、多項選擇題（每題3分，共30分，多選少選均不得分）16.以下哪些指標可直接反映系統(tǒng)可靠性A.MTBFB.MTTRC.P99延遲D.錯誤預算答案：A、B、D解析：P99延遲屬于性能指標，與可靠性相關但非直接。17.關于混沌工程原則，正確的有A.先在生產小規(guī)模實驗B.先假設系統(tǒng)脆弱C.實驗需可回滾D.優(yōu)先驗證最不可能故障的場景答案：B、C解析：混沌工程從“系統(tǒng)終將失敗”出發(fā)，實驗必須可控可回滾；生產實驗需逐步放大，而非一開始就上生產。18.以下哪些做法有助于降低微服務“雪崩”風險A.超時重試無限次B.艙壁模式C.熔斷降級D.同步阻塞調用答案：B、C解析：艙壁隔離資源，熔斷快速失敗，均可防止故障蔓延。19.關于持續(xù)交付流水線，正確的有A.構建階段應生成可部署制品B.自動化測試越靠后運行成本越高C.手動審批環(huán)節(jié)越多越安全D.流水線失敗應第一時間通知提交人答案：A、B、D解析：過度手動審批降低交付節(jié)奏，且易引入人為失誤。20.以下屬于“云原生”特征的有A.容器化封裝B.可彈性伸縮C.基于物理機靜態(tài)部署D.通過聲明式配置管理答案：A、B、D解析：靜態(tài)部署違背彈性原則。21.關于技術方案評審，合理的做法有A.評審前提前發(fā)放設計文檔B.評審會逐行代碼走查C.記錄待辦并跟蹤閉環(huán)D.僅架構師參與即可答案：A、C解析：評審會應聚焦設計，代碼走查另設環(huán)節(jié)；跨角色參與可提高覆蓋率。22.以下哪些工具可用于基礎設施即代碼A.TerraformB.AnsibleC.CloudFormationD.Jenkins答案：A、B、C解析：Jenkins為持續(xù)集成工具，本身不定義資源。23.關于性能壓測，正確的有A.需在類生產環(huán)境執(zhí)行B.TPS越高越好C.需關注資源利用率D.需逐步加壓找到拐點答案：A、C、D解析：TPS需結合成功率、延遲綜合評估，非單純越高越好。24.以下哪些行為可能引入合規(guī)風險A.將用戶日志明文存儲在公有云桶B.使用GPL組件發(fā)布閉源軟件C.未進行第三方依賴漏洞掃描D.在PR中泄露密鑰答案：A、B、C、D解析：均涉及數據安全、知識產權與供應鏈風險。25.關于高可用部署，正確的有A.多活架構比主備資源利用率高B.藍綠發(fā)布需兩倍資源C.灰度發(fā)布可逐步放量D.災備機房距離越近越好答案：A、B、C解析：災備距離需平衡網絡延遲與地域風險，過近無法抵御區(qū)域性災難。三、判斷題（每題1分，共10分，正確請選“√”，錯誤選“×”）26.在Scrum中，只有ScrumMaster可以取消Sprint。答案：×解析：ProductOwner或開發(fā)團隊亦可提出，但需共同評估。27.采用分布式緩存時，只要增加節(jié)點就能線性提升命中率。答案：×解析：命中率受數據訪問分布、緩存策略影響，節(jié)點增加可能邊際效應遞減。28.服務網格（ServiceMesh）將通信邏輯下沉到Sidecar，可實現語言無關的治理。答案：√解析：Sidecar代理屏蔽語言差異，統(tǒng)一處理流量、安全、觀測。29.技術管理人員無需參與代碼評審，只需把握進度。答案：×解析：技術管理者深入評審可發(fā)現風險、指導團隊、保持技術敏感。30.零信任架構默認假定內網流量可信。答案：×解析：零信任核心即“永不信任，持續(xù)驗證”。31.使用JWT令牌可以完全替代服務端會話，無需任何額外狀態(tài)。答案：×解析：JWT失效需維護黑名單或縮短有效期，完全無狀態(tài)難以強制登出。32.在精益思想中，“Muda”指任何不增加價值的活動。答案：√解析：Muda即浪費，包括等待、缺陷、過度加工等。33.采用事件溯源模式時，業(yè)務對象當前狀態(tài)可通過事件重放獲得。答案：√解析：事件溯源以事件流為唯一事實來源，狀態(tài)可任意時刻重建。34.技術管理者將團隊績效全部與代碼行數掛鉤，可提升產出。答案：×解析：代碼行數與價值無線性關系，易誘導冗余代碼，降低可維護性。35.系統(tǒng)可用性從99.9%提升到99.99%，意味著年度停機時間減少約8.76小時。答案：√解析：99.9%允許8.76小時，99.99%允許52.6分鐘，差值約8小時。四、簡答題（每題10分，共30分）36.某電商平臺大促在即，技術負責人發(fā)現核心下單接口P99延遲從500ms升至2s，但CPU、內存、DB負載均正常。請列出至少四條排查思路并給出可能根因。答案與解析：1)網絡層面：利用tcpdump/mtr查看是否存在丟包、重傳；可能因DNS解析異?；蜻\營商鏈路抖動。2)依賴降級：檢查下游推薦、營銷服務是否同步阻塞且超時設置過長；大促流量觸發(fā)緩存穿透，導致本應異步的調用被串行化。3)鎖競爭：雖DB負載低，但熱點行更新可能引發(fā)InnoDB行鎖等待；通過showengineinnodbstatus可觀察。4)GC停頓：雖內存占用不高，若JVM堆設置過大且采用CMS，可能因remark階段停頓；可切換G1并調優(yōu)MaxGCPauseMillis。5)日志同步：大促調試日志開啟DEBUG級別，同步寫磁盤造成IO等待；改為異步日志即可恢復。37.描述一次“從需求到上線”的完整持續(xù)交付流程，要求涵蓋分支策略、自動化測試、灰度發(fā)布、觀測回滾四個環(huán)節(jié)，并指出每個環(huán)節(jié)的準入準出標準。答案與解析：分支策略：采用GitFlow+PullRequest。需求拆分為feature分支，提PR時需通過CodeReview、靜態(tài)掃描、單元測試覆蓋率>80%。自動化測試：PR合并后觸發(fā)CI，執(zhí)行靜態(tài)代碼檢查、單元測試、接口契約測試、集成測試；準入：全部測試通過、無高危漏洞；準出：生成可部署鏡像并推送到制品庫，鏡像標簽含gitcommit?；叶劝l(fā)布：CD流水線使用ArgoRollouts，按10%、30%、100%三階段放量；準入：鏡像通過安全掃描、基準性能測試；每階段需人工確認SLI（成功率>99.5%、P95延遲<600ms）達標方可繼續(xù)。觀測回滾：通過Prometheus+Grafana實時監(jiān)控，錯誤預算消耗>50%或SLO連續(xù)5分鐘不達標自動觸發(fā)回滾；回滾策略為立即切回上一版本并標記鏡像為blocked，同時發(fā)送告警到值班群，后續(xù)需提交事故報告。38.技術管理者如何平衡“交付速度”與“技術債”？請給出可落地的三步法，并說明如何量化評估。答案與解析：第一步：債務可視化。利用SonarQube掃描代碼，將漏洞、壞味道、重復度匯總成“技術債墻”，與業(yè)務需求同池管理，采用故事點估算利息。第二步：利息量化。定義“債息率”=因技術債導致的額外工時/需求總工時；通過Jira標簽追蹤，每個迭代統(tǒng)計，若債息率>15%則觸發(fā)還債窗口。第三步：還債節(jié)奏化。每版本預留20%容量用于重構，采用“童子軍規(guī)則”：改動到的模塊必須比原來更干凈；每季度舉行“債委會”評審，若債息率下降且交付速率未降低，則給予團隊額外技術激勵。量化評估：以交付速率（故事點/迭代）為橫軸，債息率為縱軸，繪制散點圖；若債息率下降同時速率穩(wěn)定或上升，則策略有效；反之需調整還債比例或重新評估債務優(yōu)先級。五、案例分析題（共30分）39.背景：某SaaS公司提供多租戶報表系統(tǒng)，采用SpringCloud架構，網關+8個微服務+PostgreSQL，部署在阿里云K8s。上周開始，多個大客戶反饋早上9點導出報表超時，但監(jiān)控顯示此時CPU、內存、網絡、IO均低于50%。（1）請給出5條具體定位步驟（10分）（2）根因最可能是什么？請說明理由（5分）（3）給出短期、中期、長期三套解決方案，并對比優(yōu)劣（15分）答案與解析：（1）定位步驟：1.復現場景：在測試環(huán)境使用相同租戶數據、相同參數、相同并發(fā)導出，確認可復現。2.代碼剖析：開啟SpringBootActuator的/httptrace，觀察各層耗時；發(fā)現服務A調用服務B平均耗時從200ms升至5s。3.數據庫追蹤：對PostgreSQL開啟slowquerylog，發(fā)現某租戶分區(qū)表執(zhí)行seqscan，耗時8s。4.執(zhí)行計劃：explainanalyze顯示該表因前夜批量導入導致統(tǒng)計信息過時，優(yōu)化器誤判走全表掃描。5.資源競爭：檢查連接池，發(fā)現HikariCP最大連接數僅20，早上高峰時排隊等待，進一步放大延遲。（2）根因：夜間ETL批量導入后未自動analyze，導致統(tǒng)計信息陳舊，優(yōu)化器選錯索引；加之連接池過小，排隊效應放大，形成“慢查詢→連接占