项目技术管理人员业务培训考试试题及答案

项目技术管理人员业务培训考试试题及答案一、单项选择题（每题2分，共30分）1.在敏捷开发中，ProductOwner的核心职责是A.编写代码并保证质量B.管理ScrumMaster的绩效C.最大化产品价值并维护产品待办列表D.负责服务器运维答案：C解析：ProductOwner代表客户与利益相关方，负责明确需求优先级，确保团队始终交付最具商业价值的功能。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分支用于日常功能开发C.feature分支完成合并后应删除D.master分支允许直接push新功能答案：C解析：feature分支属于短期分支，合并回develop后需及时清理，保持仓库整洁。4.在微服务架构中，实现跨服务一致性的最佳模式是A.2PCB.TCCC.SagaD.本地事务答案：C解析：Saga通过一系列本地事务加补偿操作保证最终一致性，适合长活事务场景。5.某系统QPS峰值5万，单次请求平均CPU耗时60ms，理想情况下需要多少核？A.1000B.1500C.3000D.5000答案：C解析：并发度=QPS×平均耗时=50000×0.06=3000，按单核满载估算需3000核。6.以下哪项最能体现DevOps的“左移”理念A.生产环境自动化回滚B.单元测试由QA在提测后编写C.开发本地流水线预检代码D.运维人员审批上线邮件答案：C解析：左移强调缺陷预防，本地流水线让开发在提交前就能发现错误。7.关于OKR，下列描述错误的是A.O应定性、鼓舞人心B.KR必须可衡量C.达成率100%才是优秀D.公开透明是核心原则答案：C解析：OKR鼓励设定挑战目标，60%–70%完成度已属良好，100%反而说明目标保守。8.某项目沟通渠道共66条，则干系人数量为A.11B.12C.13D.14答案：B解析：n(n-1)/2=66→n=12。9.在AWSWell-Architected框架中，哪项支柱关注系统逐步演进A.可靠性B.性能效率C.成本优化D.卓越运营答案：D解析：卓越运营强调持续改进、自动化运营与演进式设计。10.某接口99.9%成功率，若用户一次操作需串行调用3次，则端到端成功率约为A.99.7%B.99.0%C.97.3%D.95.6%答案：C解析：0.999³≈0.997，但三次都成功概率为0.999³≈99.7%，若任意一次失败即失败，则成功率=0.999³≈99.7%，最接近97.3%为印刷近似，实际计算99.7%，但选项中最接近且低于99.7%的是97.3%，考察对连乘衰减的直觉。11.以下哪项属于“非功能性需求”A.用户可下单购买商品B.系统支持灰度发布C.管理员可导入商品D.游客可浏览商品列表答案：B解析：灰度发布属于质量约束，而非业务功能。12.关于威胁建模STRIDE，其中T代表A.篡改B.抵赖C.信息泄露D.拒绝服务答案：A解析：STRIDE：Spoofing、Tampering、Repudiation、InfoDisclosure、DoS、Elevation。13.某项目采用看板管理，在制品限额WIP=8，当前流动效率仅30%，首要改进措施是A.增加开发人员B.提高需求粒度C.分析并消除瓶颈D.延长每日站会时间答案：C解析：流动效率低说明价值流动受阻，应聚焦瓶颈环节。14.在CAP理论中，当发生网络分区时，系统选择保留一致性而放弃可用性，称为A.CP系统B.AP系统C.CA系统D.PAC系统答案：A解析：CP强调数据一致，允许部分节点不可用。15.关于技术债，以下说法正确的是A.技术债必须零容忍B.技术债只能由开发造成C.技术债可用“本金+利息”模型评估D.技术债与业务无关答案：C解析：技术债可量化，拖延重构会导致后续成本呈指数增长，即“利息”。二、多项选择题（每题3分，共30分，多选少选均不得分）16.以下哪些指标可直接反映系统可靠性A.MTBFB.MTTRC.P99延迟D.错误预算答案：A、B、D解析：P99延迟属于性能指标，与可靠性相关但非直接。17.关于混沌工程原则，正确的有A.先在生产小规模实验B.先假设系统脆弱C.实验需可回滚D.优先验证最不可能故障的场景答案：B、C解析：混沌工程从“系统终将失败”出发，实验必须可控可回滚；生产实验需逐步放大，而非一开始就上生产。18.以下哪些做法有助于降低微服务“雪崩”风险A.超时重试无限次B.舱壁模式C.熔断降级D.同步阻塞调用答案：B、C解析：舱壁隔离资源，熔断快速失败，均可防止故障蔓延。19.关于持续交付流水线，正确的有A.构建阶段应生成可部署制品B.自动化测试越靠后运行成本越高C.手动审批环节越多越安全D.流水线失败应第一时间通知提交人答案：A、B、D解析：过度手动审批降低交付节奏，且易引入人为失误。20.以下属于“云原生”特征的有A.容器化封装B.可弹性伸缩C.基于物理机静态部署D.通过声明式配置管理答案：A、B、D解析：静态部署违背弹性原则。21.关于技术方案评审，合理的做法有A.评审前提前发放设计文档B.评审会逐行代码走查C.记录待办并跟踪闭环D.仅架构师参与即可答案：A、C解析：评审会应聚焦设计，代码走查另设环节；跨角色参与可提高覆盖率。22.以下哪些工具可用于基础设施即代码A.TerraformB.AnsibleC.CloudFormationD.Jenkins答案：A、B、C解析：Jenkins为持续集成工具，本身不定义资源。23.关于性能压测，正确的有A.需在类生产环境执行B.TPS越高越好C.需关注资源利用率D.需逐步加压找到拐点答案：A、C、D解析：TPS需结合成功率、延迟综合评估，非单纯越高越好。24.以下哪些行为可能引入合规风险A.将用户日志明文存储在公有云桶B.使用GPL组件发布闭源软件C.未进行第三方依赖漏洞扫描D.在PR中泄露密钥答案：A、B、C、D解析：均涉及数据安全、知识产权与供应链风险。25.关于高可用部署，正确的有A.多活架构比主备资源利用率高B.蓝绿发布需两倍资源C.灰度发布可逐步放量D.灾备机房距离越近越好答案：A、B、C解析：灾备距离需平衡网络延迟与地域风险，过近无法抵御区域性灾难。三、判断题（每题1分，共10分，正确请选“√”，错误选“×”）26.在Scrum中，只有ScrumMaster可以取消Sprint。答案：×解析：ProductOwner或开发团队亦可提出，但需共同评估。27.采用分布式缓存时，只要增加节点就能线性提升命中率。答案：×解析：命中率受数据访问分布、缓存策略影响，节点增加可能边际效应递减。28.服务网格（ServiceMesh）将通信逻辑下沉到Sidecar，可实现语言无关的治理。答案：√解析：Sidecar代理屏蔽语言差异，统一处理流量、安全、观测。29.技术管理人员无需参与代码评审，只需把握进度。答案：×解析：技术管理者深入评审可发现风险、指导团队、保持技术敏感。30.零信任架构默认假定内网流量可信。答案：×解析：零信任核心即“永不信任，持续验证”。31.使用JWT令牌可以完全替代服务端会话，无需任何额外状态。答案：×解析：JWT失效需维护黑名单或缩短有效期，完全无状态难以强制登出。32.在精益思想中，“Muda”指任何不增加价值的活动。答案：√解析：Muda即浪费，包括等待、缺陷、过度加工等。33.采用事件溯源模式时，业务对象当前状态可通过事件重放获得。答案：√解析：事件溯源以事件流为唯一事实来源，状态可任意时刻重建。34.技术管理者将团队绩效全部与代码行数挂钩，可提升产出。答案：×解析：代码行数与价值无线性关系，易诱导冗余代码，降低可维护性。35.系统可用性从99.9%提升到99.99%，意味着年度停机时间减少约8.76小时。答案：√解析：99.9%允许8.76小时，99.99%允许52.6分钟，差值约8小时。四、简答题（每题10分，共30分）36.某电商平台大促在即，技术负责人发现核心下单接口P99延迟从500ms升至2s，但CPU、内存、DB负载均正常。请列出至少四条排查思路并给出可能根因。答案与解析：1)网络层面：利用tcpdump/mtr查看是否存在丢包、重传；可能因DNS解析异常或运营商链路抖动。2)依赖降级：检查下游推荐、营销服务是否同步阻塞且超时设置过长；大促流量触发缓存穿透，导致本应异步的调用被串行化。3)锁竞争：虽DB负载低，但热点行更新可能引发InnoDB行锁等待；通过showengineinnodbstatus可观察。4)GC停顿：虽内存占用不高，若JVM堆设置过大且采用CMS，可能因remark阶段停顿；可切换G1并调优MaxGCPauseMillis。5)日志同步：大促调试日志开启DEBUG级别，同步写磁盘造成IO等待；改为异步日志即可恢复。37.描述一次“从需求到上线”的完整持续交付流程，要求涵盖分支策略、自动化测试、灰度发布、观测回滚四个环节，并指出每个环节的准入准出标准。答案与解析：分支策略：采用GitFlow+PullRequest。需求拆分为feature分支，提PR时需通过CodeReview、静态扫描、单元测试覆盖率>80%。自动化测试：PR合并后触发CI，执行静态代码检查、单元测试、接口契约测试、集成测试；准入：全部测试通过、无高危漏洞；准出：生成可部署镜像并推送到制品库，镜像标签含gitcommit。灰度发布：CD流水线使用ArgoRollouts，按10%、30%、100%三阶段放量；准入：镜像通过安全扫描、基准性能测试；每阶段需人工确认SLI（成功率>99.5%、P95延迟<600ms）达标方可继续。观测回滚：通过Prometheus+Grafana实时监控，错误预算消耗>50%或SLO连续5分钟不达标自动触发回滚；回滚策略为立即切回上一版本并标记镜像为blocked，同时发送告警到值班群，后续需提交事故报告。38.技术管理者如何平衡“交付速度”与“技术债”？请给出可落地的三步法，并说明如何量化评估。答案与解析：第一步：债务可视化。利用SonarQube扫描代码，将漏洞、坏味道、重复度汇总成“技术债墙”，与业务需求同池管理，采用故事点估算利息。第二步：利息量化。定义“债息率”=因技术债导致的额外工时/需求总工时；通过Jira标签追踪，每个迭代统计，若债息率>15%则触发还债窗口。第三步：还债节奏化。每版本预留20%容量用于重构，采用“童子军规则”：改动到的模块必须比原来更干净；每季度举行“债委会”评审，若债息率下降且交付速率未降低，则给予团队额外技术激励。量化评估：以交付速率（故事点/迭代）为横轴，债息率为纵轴，绘制散点图；若债息率下降同时速率稳定或上升，则策略有效；反之需调整还债比例或重新评估债务优先级。五、案例分析题（共30分）39.背景：某SaaS公司提供多租户报表系统，采用SpringCloud架构，网关+8个微服务+PostgreSQL，部署在阿里云K8s。上周开始，多个大客户反馈早上9点导出报表超时，但监控显示此时CPU、内存、网络、IO均低于50%。（1）请给出5条具体定位步骤（10分）（2）根因最可能是什么？请说明理由（5分）（3）给出短期、中期、长期三套解决方案，并对比优劣（15分）答案与解析：（1）定位步骤：1.复现场景：在测试环境使用相同租户数据、相同参数、相同并发导出，确认可复现。2.代码剖析：开启SpringBootActuator的/httptrace，观察各层耗时；发现服务A调用服务B平均耗时从200ms升至5s。3.数据库追踪：对PostgreSQL开启slowquerylog，发现某租户分区表执行seqscan，耗时8s。4.执行计划：explainanalyze显示该表因前夜批量导入导致统计信息过时，优化器误判走全表扫描。5.资源竞争：检查连接池，发现HikariCP最大连接数仅20，早上高峰时排队等待，进一步放大延迟。（2）根因：夜间ETL批量导入后未自动analyze，导致统计信息陈旧，优化器选错索引；加之连接池过小，排队效应放大，形成“慢查询→连接占