ITSS项目经理考试第九组练习题逐题拆解与三轮刷题复盘

1. 这套练习题到底在练什么：先把考试的骨架摸清

第一次接触 ITSS 项目经理考试 的人，十有八九会被练习题的数量吓到：网上流传的各种“第几套”“第几组”，一套动辄几十上百题，从服务生命周期问到挣值分析，从服务台分级问到关键路径，看着哪儿都像考点。我当初也是这样，抱着“多刷几套总能考上”的心态，一套一套往下做，结果刷到第七套的时候猛然发现：错的地方来回就那么几个，第二套错的题，第七套还在错，只是换了个说法。

问题出在练习题的用法上。这份标着“（9）”的练习题，本质上是 考点的切片 ，而不是知识的全集。它把大纲里能出成客观题的部分剁碎了给你，你如果只记答案，等于只背下了切片的位置，换个角度切你就认不出来了。我后来调整了做法：把每一套练习题当成一次 知识体检 ，错一道就顺着这道题往回摸，摸到它在知识体系里挂在哪根枝上，把那根枝上的东西重新过一遍。这个方法听起来慢，实际比我一开始无脑刷题快得多——因为真正需要补的地方其实很少。

这篇内容适合两类人。一类是刚报名、手里攥着练习题但不知道从哪下手的，我会把整套复习框架和这份练习题的逐题拆解写清楚，你照着走就行。另一类是老 IT 运维或者项目岗转过来的，工作上那些事你天天在做，但考试考的是 标准语境下的表述 ，跟你工位上的习惯说法不一样，这部分差异我会专门挑出来说。整套内容按“知识骨架 → 考点拆解 → 完整练习题 → 计算速查 → 错题复盘 → 冲刺节奏”的路子走，中间会掺一些我自己踩过的坑，比如多选题里那种“看着全对其实全错”的选项设置套路。

1.1 ITSS 项目经理考试的知识结构长什么样

把大纲摊开看，整个 ITSS 项目经理考试的知识面可以归成三大块： 标准体系与生命周期、运维服务能力建设、项目管理通用知识 。这三块不是并列的，而是层层套着的。最外层是 ITSS 的服务生命周期——规划、部署、运营、改进、监督这五个阶段，几乎所有场景题都能塞进这五个抽屉里；中间一层是服务能力四要素，人员、过程、技术、资源，这是评价一次服务“够不够格”的尺子；最里层是项目管理的老五样，范围、进度、成本、质量，加上人力和风险，负责把服务真正落地。

很多人复习顺序搞反了，一上来就啃项目管理的网络图和挣值公式，因为它看起来很“硬”，算出来有数字，有安全感。但从分值分布看，标准体系和生命周期相关的题目占比往往更大，而且这部分是 送分题 ——只要把五个阶段的定义、输入输出、典型活动记住，很多题属于“看见关键词就选得上”的难度。真正的坑在能力四要素和项目管理交叉的地方，比如一道题问你“某单位的服务台响应慢、知识库缺失、工程师流失严重，应该优先从哪个要素入手改进”，这种题四个选项都沾边，得靠对四要素内部逻辑关系的理解才能选对。

我建议的复习顺序是这样的：先用一天时间把生命周期的五个阶段和一、二、三级运维服务能力成熟度的差异梳理成一张自己手画的表，别抄别人的，手画的时候大脑在建立索引；然后花两三天啃四要素的细节，尤其是“过程”里的十几个管理流程；最后再上项目管理的计算题。计算题放到后面有个好处——它的逻辑一旦通了就不会忘，早学反而会占用前期需要反复记忆的内容的脑容量。

1.2 三轮刷题法：把一份练习题榨干三遍

一份练习题我一般用三轮来打，每轮目的完全不同，用笔的颜色分开标记。

第一轮是摸底 ，不限时间，翻书也行，但每道题旁边必须写下“我为什么选它”。这一步的价值不在正确率，而在暴露你的 判断路径 。判断对了但依据错了，比判断错了更危险，因为你会在考场上稳定地错下去。我把自己第一轮的错误归成三类：完全没见过（知识盲区）、见过但记混了（记忆冲突）、看懂了但选项是陷阱（审题问题）。三类错误的补救方法完全不同，混在一起复习就是浪费时间。

第二轮是限时 。客观题按一分钟一道的速度压着走，案例题按十五分钟一道压。这一轮暴露的是 节奏问题 ——哪些题你其实会，但因为纠结太久拖垮了后面的题。我第二轮做下来发现，自己在多选题上平均要花将近三分钟，远超预算，原因是我总想把每个选项都验证一遍。后来我改成“确定错的划掉，剩下两个拿不准的先标记跳过”，回头再补，整体能省出七八分钟。

第三轮只做错题 ，而且要求自己用 一句话讲清楚这题考什么、陷阱在哪 。讲不清楚的，说明还没真懂，回去翻资料。这一轮通常只需要第一轮三分之一的时间，但提升最明显。有个小技巧：第三轮复习时把题目念出来，用嘴讲一遍比在心里想一遍暴露问题快得多——心里默认的“我懂了”经常是自我欺骗。

1.3 为什么这份练习题不能当题库背

我见过最极端的备考方式是有人把网上所有练习题打印出来，把答案标红，然后反复看到“看到题干就能背出答案”的程度。这套打法在有些考试里也许管用，但在这类考试里风险很大。

原因在于命题方式。ITSS 项目经理的客观题大量采用 情境化改写 ：同一条标准要求，在 A 套题里问“规划设计阶段的首要输出”，在 B 套题里就变成“某单位要新建运维体系，第一步应该做什么”，在 C 套题里又变成“下列哪项不属于规划设计阶段的成果”。三句话指向同一个知识点，但如果你只记住了 A 套的答案“服务目录”，B 套和 C 套你还是会犹豫，因为题干语境变了。

更麻烦的是多选题。我印象很深的一道题，四个选项分别是“建立服务目录”“明确服务级别”“开展满意度调查”“制定人员培训计划”，问哪几项属于规划设计阶段的工作。答案前两项。但“满意度调查”在有些流程里确实会出现在规划阶段（基线调研），这就很容易让人犹豫。这种题的破法是 抓住阶段的核心目标 ：规划阶段解决的是“我们要提供什么服务、达到什么水平”，满意度调查是“我们已经提供了什么服务、水平如何”，属于持续改进阶段的输入。抓住目标，就不会被具体活动名词带偏。

所以这份练习题的正确价值是： 用它的题干去反推知识点的边界 ，而不是背它的答案。每做完一道题，多问一句“如果把题干里的某个条件换掉，答案会怎么变”，这一问往往能顶三道题。

2. 五大知识块的考点拆解与典型错题剖析

下面这块是这篇的核心。我把这份练习题涉及的内容按五个知识块重新归了类，每块讲清楚“考什么、怎么问、错在哪”。这不是把大纲抄一遍，而是按题目的实际出法来组织。

2.1 服务生命周期五阶段：最容易混淆的“边界题”

服务生命周期分规划设计、部署实施、服务运营、持续改进、监督管理五个阶段。教科书上的定义大家都会背，但题目从来不问定义，问的是 某件事该归哪 。这是最容易失分的地方，因为相邻阶段的边界是模糊的。

我整理了一张对照表，按“核心目标—典型产出—常见误判”三列来区分，比记定义管用得多。

阶段	核心目标	典型产出	常见误判
规划设计	明确服务内容与水平，形成可执行的方案	服务目录、SLA、服务方案、资源测算	把“现状调研”错认成运营阶段的监控
部署实施	把方案转成可交付的服务能力	人员到位、工具上线、流程试运行、移交	把“试运行期的问题处理”错认为运营
服务运营	按约定的水平稳定交付服务	事件单、服务报告、指标达成记录	把“满意度调查结果分析”错认为运营
持续改进	基于数据和差距提升服务能力	改进计划、根因分析报告、优化后的流程	把“日常问题解决”错认为改进
监督管理	对服务过程和结果进行评估与控制	审计记录、评价报告、风险预警	把“内部质量检查”错认为运营自查

判断归属的时候，我用的口诀是： “想清楚要做的事，是把事情想明白（规划）、把架子搭起来（部署）、按架子跑起来（运营）、跑得更好（改进），还是看跑得对不对（监督）。” 这五句话一过，八成题目能定位。

典型错题长这样：某单位已完成服务台建设、监控工具部署、运维流程试用，现在准备正式承接业务系统的日常运维，问当前处于生命周期的哪个阶段。选项里运营和改进最容易混。判断依据是“正式承接”这个动作——能力已经建好但还没开始按 SLA 交付，属于部署实施的收尾与移交。如果题干改成“已承接三个月，正在分析事件数据找高频故障”，那就是运营向改进过渡了。

注意：很多题目会在题干里埋“时间线词”，比如“刚刚完成”“已经运行半年”“正在编制”。这类词往往比具体活动描述更能定位阶段，做题时先圈时间线词，再看活动。

2.2 人员、过程、技术、资源：四要素题的判断口诀

服务能力四要素是另一个高频区。人员讲的是岗位、能力、培训、绩效；过程讲的是流程、制度、规范、记录；技术讲的是工具、平台、研发、创新；资源讲的是知识库、备件、服务台场地、供应商关系。

考题的常见套路是给一个场景描述痛点，问你 最应该优先改进哪个要素 。比如“工程师处理故障高度依赖个人经验，新人上手慢，同类问题反复处理耗时很长”——这句话里有人员（新人上手慢）、有过程（同类问题反复）、有资源（知识库）。到底选哪个？

我的判断逻辑是找 因果链的根 。“同类问题反复处理耗时很长”是结果，“依赖个人经验”是原因，“知识库缺失”是原因的成因。题目问“优先改进”，答案一般指向 最上游的那个要素 ，也就是资源里的知识库建设。因为建了知识库，人员培养和问题处理效率会顺带改善。这条因果链的思路，比死记“知识库属于资源”有用得多。

再比如“服务台接到报修后，无法判断该派给谁，经常转错组导致处理时间拉长”——这题的根在过程（派单规则和升级机制不清晰），不在人员能力。如果题干改成“派单准确但工程师解决不了”，那才指向人员技能。

我把四要素的典型痛点做了个对照，做题时可以拿来对号：

• 人员类信号词 ：流失率高、能力参差、培训不足、绩效无法量化、岗位职责不清
• 过程类信号词 ：无章可循、口径不一、记录缺失、升级路径不清、重复返工
• 技术类信号词 ：工具老旧、告警风暴、监控盲区、无法自动巡检、数据无法关联
• 资源类信号词 ：知识库空白、备件不足、服务台容量不够、外部供应商响应慢

提示：四要素题里最容易被误选的是“技术”。因为工具问题是看得见的，很多人下意识选它。但如果题干的核心矛盾是“人不知道怎么干”或“流程没定”，上再多工具也解决不了，这时候选技术就是掉坑。

2.3 SLA 与指标类题目：数字背后的口径陷阱

服务级别协议这块，考题分两类：一类考 协议内容 （应该包含什么、由谁签署、多久评审一次），一类考 指标计算 （可用性、响应时间、解决时间、达成率）。第二类是重灾区，因为口径不同，答案能差一大截。

先说可用性。计算公式是 可用性 = MTBF ÷ (MTBF + MTTR) ，等价于 1 减去停机时间占比。但题目里给的条件形式五花八门：有的给“年度计划运行 8760 小时，累计故障停机 8.76 小时”，有的给“平均无故障时间 2000 小时，平均修复时间 2 小时”，有的给“一年内发生 5 次故障，每次平均 4 小时，计划检修 10 小时”。最后一种最坑—— 计划检修算不算停机 ？这取决于约定的口径。如果 SLA 里约定“计划内维护窗口不计入不可用时间”，那就要把检修时间剔掉；如果没约定，就要算进去。

我的做法是：做题时先在草稿纸上写一行“口径假设”，把题目里没明说但影响结果的点标出来，然后看选项。如果两个选项分别对应两种口径，说明命题人就是要考你这个辨析，那就回到题干找有没有“计划内”“约定除外”之类的字眼。

响应时间和解决时间也是一对容易混的概念。响应时间是从用户提交请求到 服务方首次回应 的时长，解决时间是从提交到 故障恢复或请求关闭 的时长。考场上经常出现“某工单 9:00 提交，9:20 工程师接单并回复，10:40 处理完毕”，问你响应时间和解决时间各是多少。答案是 20 分钟和 100 分钟。这个不难，但紧张的时候极易把“接单”当成“响应”的终点而把“首次回复”忽略掉。

指标	起算点	终止点	常见陷阱
响应时间	用户提交请求	服务方首次有效回应	把“系统自动回复”算作有效回应
解决时间	用户提交请求	故障恢复或请求关闭	暂停计时条件是否适用
可用性	统计周期开始	统计周期结束	计划维护窗口是否剔除
达成率	统计周期开始	统计周期结束	分母是总工单还是应响应工单

2.4 项目管理通用知识：进度、成本、风险、质量的高频组合

项目管理的题目，考的其实是 几个公式加几个判断 ，范围很窄，但出题方式灵活。

进度这块核心是关键路径。题目一般给一张活动清单加依赖关系和工期，问总工期或者某活动的总时差。手算的方法是画网络图正推最早开始、逆推最晚开始，两者相减得总时差。考场上时间紧，我的做法是先找 最长路径 ——从起点到终点把各条路径的工期加起来，最长的就是关键路径，其长度就是总工期。这个方法在活动数不超过十个的时候比正推逆推快得多。只有问“某非关键活动的总时差”时才需要老老实实算。

成本这块核心是挣值。三个基础值：计划价值 PV、挣值 EV、实际成本 AC。四个衍生指标：进度偏差 SV = EV − PV，成本偏差 CV = EV − AC，进度绩效指数 SPI = EV ÷ PV，成本绩效指数 CPI = EV ÷ AC。判断口诀是“ 偏差看正负，指数看大小 ”：SV 为负表示进度落后，CV 为负表示成本超支，SPI 小于 1 落后，CPI 小于 1 超支。题目常给一组数让你判断项目状态，或者问“按当前绩效完成剩余工作还需多少成本”，那就用完工估算 EAC = AC + (BAC − EV) ÷ CPI。

风险这块考应对策略的归类。规避是改计划消除风险，转移是把影响转给第三方（保险、外包、担保），减轻是降低概率或影响，接受是不主动采取措施、留应急储备。判断的关键看 动作对象的性质 ：动了计划就是规避，动了合同就是转移，动了措施就是减轻，什么都没动就是接受。题目里经常出现“购买保险”这个经典选项，一定对应转移。

质量这块考的是质量保证和质量控制的区别。质量保证关注 过程 ，防止缺陷产生；质量控制关注 结果 ，发现并纠正缺陷。题干里出现“审计过程执行情况”“优化流程”就往保证上靠，出现“抽检”“测试”“评审交付物”就往控制上靠。

2.5 案例分析与简答题：四段式答题框架

案例题是拉开差距的地方，也是最多人写了一大段却拿不到分的地方。原因很简单： 没按得分点写 。阅卷是按点给分的，你写三百字散文，不如写四条短句。

我用的框架是四段： 定性问题 → 分析原因 → 给出措施 → 补充预防 。

第一段定性，用一两句话说清楚这个案例的核心矛盾是什么，比如“该单位的核心问题是服务级别约定不清晰，导致运维投入与业务期望长期错位”。这段的作用是让阅卷人知道你看懂了，虽然本身分值不高，但定错了后面全歪。

第二段分析原因，按要素拆。人员上有没有岗位职责不清、能力不足；过程上有没有流程缺失、记录不全；技术上有没有监控盲区；资源上有没有知识库空白。每条一句话，能拆出四条就够了，不要凑数。

第三段给措施，必须 和原因一一对应 ，而且要有动作、有主体、有时序。比如原因写“事件升级机制缺失”，措施就写“由服务经理牵头，两周内梳理三级升级路径，明确各级响应时限并纳入流程文件，下月起执行”。带主体、带时间、带交付物的措施，比“完善升级机制”这种空话值钱得多。

第四段预防，一般落在持续改进上——建立指标监控、定期评审、把改进纳入 PDCA 循环。这段不用长，两句话即可，但一定要写，因为它是“闭环”的标志。

注意：案例题千万别写成“我觉得”。阅卷看的是标准动作，不是个人感想。把“我认为应该加强培训”改成“建议由服务经理组织，针对一线工程师开展为期两周的专项技能培训，培训后进行考核并纳入绩效”，分数立刻不一样。

3. 完整一套练习题（第九组）与逐题拆解

下面这组题我按考试的实际题型配比来排：单选、多选、判断、计算、案例。题目是我按常见考点仿写的，难度和出题角度贴近真实考试。每道题都给解析，重点讲 为什么错 ，而不是只给答案。

3.1 单项选择题（12 道）

第 1 题 服务生命周期中，将服务方案转化为可交付服务能力的过程属于（　）。 A. 规划设计　B. 部署实施　C. 服务运营　D. 持续改进

答案 B。题干关键词是“转化”和“可交付能力”。规划设计产出的是方案和文档，部署实施才是把方案落地成人员到位、工具上线、流程可运行的状态。这题的错误选项通常是 A，因为很多人把“做方案”和“实施方案”混在一起。

第 2 题 运维服务能力四要素中，为服务过程提供工具支撑和知识沉淀的是（　）。 A. 人员　B. 过程　C. 技术　D. 资源

答案 D。这里有个辨析点：技术和资源都跟工具有关。约定俗成的划分是——技术侧重工具平台本身的能力与研发创新，资源侧重知识库、备件、服务台设施等可被调用的支撑物。知识沉淀归资源。如果题干换成“监控平台的能力升级”，那才归技术。

第 3 题 某系统年度计划运行时间为 8760 小时，全年因故障累计停机 17.52 小时，其可用性约为（　）。 A. 99.8%　B. 99.9%　C. 99.5%　D. 99.99%

答案 A。计算：17.52 ÷ 8760 = 0.2%，可用性 = 99.8%。很多人会想当然选 99.9%，因为 8.76 小时对应 99.9% 这个数字太常见了，形成记忆惯性。这题就是专门治这个惯性的——先算再选。

第 4 题 用户在 10:00 提交故障请求，10:15 服务台受理并回复，11:30 故障恢复。该请求的响应时间为（　）。 A. 15 分钟　B. 90 分钟　C. 75 分钟　D. 105 分钟

答案 A。响应时间止于首次有效回应。B 是解决时间。C 是受理到恢复的时长，属于干扰项。

第 5 题 PDCA 循环中，将改进措施固化为标准并推广的阶段是（　）。 A. P　B. D　C. C　D. A

答案 D。A（处置）阶段包含两件事：有效则标准化，无效则总结教训进入下一循环。这题很多人选 C，因为“检查”听起来像在固化，其实检查只是发现差距。

第 6 题 某运维项目 SPI = 0.85，CPI = 1.10，则该项目当前状态是（　）。 A. 进度超前、成本节约　B. 进度落后、成本节约 C. 进度落后、成本超支　D. 进度超前、成本超支

答案 B。SPI 小于 1 落后，CPI 大于 1 节约。这题几乎每年都有变体，只要记住“偏差看正负、指数看大小”就不会错。

第 7 题 下列不属于变更管理必要环节的是（　）。 A. 变更申请　B. 变更评估　C. 变更实施　D. 变更责任人绩效考评

答案 D。绩效考评属于人力资源管理范畴，不是变更流程环节。这类“不属于”题最容易被“看起来相关”的选项带偏，做题时先默念一遍标准流程的环节序列，再逐个排除。

第 8 题 服务台实行分级支持，负责处理一线无法解决的复杂技术问题的通常是（　）。 A. 一线　B. 二线　C. 三线　D. 服务经理

答案 B。二线一般由技术专家组成，处理一线升级上来的问题；三线多为原厂或研发支持。C 是常见误选，但三线的定位更靠后，通常涉及产品缺陷层面的处理。

第 9 题 事件管理与问题管理的核心区别在于（　）。 A. 事件管理由服务台负责，问题管理由技术部门负责 B. 事件管理关注尽快恢复服务，问题管理关注消除根因 C. 事件管理有 SLA，问题管理没有 D. 事件管理面向用户，问题管理面向管理层

答案 B。A 是组织分工的描述，不是本质区别；C 错误，问题管理同样有目标时限；D 是受众描述，也不准确。

第 10 题 项目风险应对策略中，购买保险属于（　）。 A. 规避　B. 转移　C. 减轻　D. 接受

答案 B。这题几乎是送分题，但要注意变体：如果题干说“与供应商签订固定总价合同”，同样是转移。

第 11 题 某活动的总时差为 0，则说明该活动（　）。 A. 可以延迟而不影响总工期 B. 位于关键路径上 C. 成本一定超支 D. 工期最长

答案 B。总时差为 0 就是在关键路径上。D 是常见混淆项——关键路径是 路径总长 最长，不是单个活动工期最长，一条关键路径上的活动工期可能都很短。

第 12 题 编制服务目录时最应该避免的做法是（　）。 A. 按业务视角分类 B. 明确每项服务的交付内容 C. 把所有技术组件都列为服务项 D. 与服务级别约定保持一致

答案 C。服务目录应该面向服务使用者的需求，而不是把内部技术栈摊开。把技术组件当服务项，会让使用者无从选择，也让 SLA 无法对应。这题考的是“服务思维”而不是“技术思维”，很多人凭工程师直觉选错。

3.2 多项选择题（6 道）

第 13 题 下列属于服务规划设计阶段输出的有（　）。 A. 服务目录　B. 服务级别协议　C. 事件处理记录　D. 服务方案　E. 满意度分析报告

答案 ABD。C 属于运营阶段产物，E 属于持续改进的输入。多选题的稳法不是“挑对的”，而是“先挑确定错的”，把 C、E 划掉，剩下的再确认一遍。

第 14 题 运维服务能力四要素包括（　）。 A. 人员　B. 过程　C. 技术　D. 资源　E. 财务

答案 ABCD。财务不在四要素内，但成本管理确实是项目管理的一部分，容易混淆。做题时记住“四要素是能力视角，成本是项目视角”。

第 15 题 一份完整的服务级别协议通常应包含（　）。 A. 服务内容与范围　B. 服务时间与可用性指标 C. 双方职责　D. 违约与例外处理　E. 供应商内部员工薪酬结构

答案 ABCD。E 明显越界。这类题的干扰项往往“过于内部化”，凡是涉及一方内部管理细节而非双方约定的，基本都要排除。

第 16 题 下列属于持续改进阶段典型活动的有（　）。 A. 服务质量数据分析　B. 根因分析 C. 改进方案制定与跟踪　D. 新员工入职培训 E. 服务能力差距评估

答案 ABCE。D 属于人员要素的日常管理活动，虽然可能因改进而触发，但它本身不是改进阶段的标准动作。

第 17 题 事件升级可能触发的场景包括（　）。 A. 处理时限即将超期 B. 故障影响范围扩大 C. 一线技能不足以处理 D. 用户要求更换工程师 E. 事件已闭环

答案 ABCD。E 是结束条件，不是升级条件。这个选项的设置很有意思——它考察你是否理解“升级”和“关闭”是流程的两个不同出口。

第 18 题 评价运维服务质量时常用的指标维度包括（　）。 A. 可用性　B. 响应及时性　C. 解决有效性　D. 用户满意度　E. 服务人员学历分布

答案 ABCD。E 不是质量指标，是人员结构描述。学历可能影响能力，但不能直接衡量服务质量。

3.3 判断题（8 道）

第 19 题 服务运营阶段的核心目标是把服务方案落地为可交付的服务能力。（×） 落地是部署实施的目标，运营的目标是按约定水平稳定交付。

第 20 题 知识库属于运维服务能力四要素中的资源。（√） 知识沉淀、备件、服务台设施都归资源。

第 21 题 可用性计算时，计划内维护窗口的停机时间一律不计入不可用时间。（×） 是否计入取决于 SLA 约定，不能一概而论。这一题是典型的“绝对化表述即错误”型。

第 22 题 问题管理的目标是尽快恢复服务。（×） 那是事件管理的目标。问题管理追求消除根因、防止复发。

第 23 题 关键路径上任何活动的延迟都会导致项目总工期延迟。（√） 关键路径总时差为零，没有缓冲空间。

第 24 题 服务级别协议一经签署，在整个服务周期内不得调整。（×） SLA 需要定期评审，业务变化时应当修订。绝对化表述再次踩坑。

第 25 题 配置管理数据库中应记录配置项之间的关联关系。（√） 只记清单不记关系，等于有账本没账目逻辑，变更影响分析就做不了。

第 26 题 满意度调查结果只用于考核服务团队绩效。（×） 主要用途是发现服务短板、驱动改进，考核只是其中一个应用场景。

3.4 计算题（3 道，含完整过程）

第 27 题 某系统统计周期内累计运行 720 小时，发生故障 4 次，故障修复时间分别为 0.5、1、1.5、1 小时。求该系统可用性（保留两位小数）。

解题过程：总故障停机时间 = 0.5 + 1 + 1.5 + 1 = 4 小时。可用性 = (720 − 4) ÷ 720 = 716 ÷ 720 ≈ 99.44%。用 MTBF/MTTR 公式验算：MTBF = (720 − 4) ÷ 4 = 179 小时，MTTR = 4 ÷ 4 = 1 小时，可用性 = 179 ÷ 180 ≈ 99.44%，结果一致。两种算法互为校验，考场上用其中一种算完，另一种快速验一下，能避免低级算术错误。

第 28 题 某项目活动及依赖关系如下：A 工期 3 天；B 依赖 A，工期 4 天；C 依赖 A，工期 2 天；D 依赖 B 和 C，工期 5 天；E 依赖 C，工期 3 天；F 依赖 D 和 E，工期 2 天。求总工期及关键路径。

解题过程：把所有路径列出来。A-B-D-F = 3+4+5+2 = 14；A-C-D-F = 3+2+5+2 = 12；A-C-E-F = 3+2+3+2 = 10。最长路径是 A-B-D-F，14 天，因此总工期 14 天，关键路径 A→B→D→F。这里有个容易漏的点：D 同时依赖 B 和 C，所以 D 的最早开始时间取 B 和 C 完成时间的较大者，即 A+B = 7 天，而不是 A+C = 5 天。列路径法天然规避了这个陷阱。

第 29 题 某服务台日均受理请求 400 个，平均每个请求处理耗时 6 分钟，工程师人均每日有效工时 6 小时，出勤率按 90% 计，考虑 20% 的冗余系数应对突发，求至少需要配置多少名工程师。

解题过程：日总工作量 = 400 × 6 = 2400 分钟 = 40 小时。人均日有效产出 = 6 × 90% = 5.4 小时。基础人力 = 40 ÷ 5.4 ≈ 7.41，向上取整为 8 人。再乘冗余系数 1.2，得 9.6，向上取整为 10 人。答案 10 人。

提示：这类题的两个坑，一是忘记向上取整（人力不能是小数），二是漏掉冗余系数。冗余系数不是随便加的，它对应的是请假、培训、会议、突发峰值这些真实占用，行业里常见取值在 1.15 到 1.3 之间。考试时如果题干给了系数就用给的，没给一般不会要求你加。

3.5 案例题（1 道，含参考答案与得分点）

第 30 题 某单位核心业务系统上线后交由内部运维团队承接。运行三个月，业务部门反馈：报修后经常找不到人，平均响应超过两小时；同类故障反复出现，每次都要重新排查；运维工程师抱怨工单太多、没有时间做优化；管理层拿不到完整的服务数据，无法判断运维投入是否合理。请分析问题并提出改进措施。

参考答案按四段式组织：

第一段定性：该单位运维服务处于“有队伍、无体系”的状态，核心问题是服务过程缺失与数据能力空白，导致服务质量不可控、服务价值不可证。

第二段原因：一是过程要素缺失，报修入口、派单规则、升级机制未定义，导致“找不到人”；二是资源要素缺失，知识库空白，同类故障无法复用历史方案；三是人员要素配置失衡，工单量超出负荷且缺少分级分流，工程师被琐事占满；四是技术要素支撑不足，缺少工单与监控数据的采集分析手段，管理层看不到服务全貌。

第三段措施：由服务经理牵头，两周内明确统一报修入口和三级升级路径，形成流程文件并全员宣贯；同步启动知识库建设，要求每张故障工单闭环时必须沉淀处理要点，三个月内覆盖高频故障；按请求类型分级，把标准请求与复杂故障分离，简单请求走自助或一线快速通道；一个月内上线工单统计视图，按月输出服务报告，包含响应达标率、重复故障率、工单分布等核心指标。

第四段预防：将上述指标纳入月度服务评审，形成“数据—分析—改进—验证”的闭环，每季度对流程和知识库做一次复审，防止体系再次退化。

这道题的得分点在于 每条原因都有对应措施 ，且措施带主体、带时间、带交付物。我见过不少人只写“加强管理、完善流程、提升效率”这类话，写了满满一页，一条分都拿不到。

4. 参数计算速查与公式推导

计算题不难，但 容易在单位换算和口径上翻车 。下面把考试里出现频率最高的三类计算整理成速查形式，每个公式都说明推导思路，理解了就不用背。

4.1 可用性与 MTBF/MTTR 的三种出题形态

第一种，直接给停机时间：可用性 = (统计周期总时长 − 停机时长) ÷ 统计周期总时长。这是最直观的形态。

第二种，给 MTBF 和 MTTR：可用性 = MTBF ÷ (MTBF + MTTR)。这个公式的推导其实很朴素——一个完整循环包括“正常运行一段时间”和“坏了修一段时间”，正常运行占比就是可用性。

第三种，给故障次数和每次时长：先算累计停机，再套第一种。这种形态的坑在于可能混入计划检修时间，需要看题干是否声明剔除。

三种形态的换算关系要熟：年停机时间 = 8760 × (1 − 可用性)。常用的对应关系是 99% 对应年停机约 87.6 小时，99.9% 对应约 8.76 小时，99.99% 对应约 52.6 分钟。这几个数字记熟，遇到“某系统要求年停机不超过 1 小时”这类题，能立刻反应出可用性要求接近 99.99%。

注意：可用性的统计周期不一定是自然年，题干如果说“季度”，就用 2160 小时（按 90 天算）或按题干给的数字算，别习惯性套 8760。

4.2 人力配置测算的通用模型

人力测算的本质是“总工作量 ÷ 人均产出 × 冗余系数”，所有变体都是在这三个量上做文章。

总工作量通常由请求量乘以单次处理时长得到，注意单位统一到小时或分钟。人均产出等于每日有效工时乘以出勤率，有效工时不是 8 小时，要扣掉会议、培训、休息，行业里常按 6 到 6.5 小时估。冗余系数用来覆盖波动和不可预见占用。

我在实际测算时还会多加一步： 按技能分层算 。一线能处理的请求和二线才能处理的请求，单次耗时差好几倍，混在一起算会严重低估。考试题一般会简化，但如果你在真实工作中做测算，分层算出来的结果往往比整体算高出 20% 以上，这一点别忽略。

4.3 服务成本与服务台投入的粗略估算

成本类的计算题出现频率低于前两类，但偶尔会考。核心构成是人力和工具两块钱：人力成本 = 人数 × 人均综合成本；工具成本包括监控平台、工单系统、备件的采购与维护。题目一般给单位成本让你加总，难点在于 识别哪些成本该计入 。

我的判断原则是： 直接为该项服务发生、且能归属于该服务的成本才计入 。管理层的分摊费用、与该项服务无关的办公场地，一般不计入。这条原则能排除掉大部分干扰项。

5. 常见错误与排查式复盘

做完题不复盘，等于白做。这一节我把练习中最高频的错误按类型归了档，配了识别方法和纠正动作，你可以直接拿去对照自己的错题本。

5.1 错题归因表

错误类型	典型表现	根本原因	纠正动作
阶段归属错	把试运行问题处理归到运营	只记定义没记边界	用“目标—产出”两列法重画阶段表
概念混淆	响应时间与解决时间互换	记忆时没有场景锚点	拿一个真实工单时间线走一遍
计算口径错	可用性未剔除计划维护	忽略题干约定条件	做题先写口径假设再计算
要素误判	知识库缺失选了技术	被表面工具问题带偏	找因果链最上游的要素
多选题漏选	只选最确定的两个	不敢判断剩余选项	先排错再确认，不留空白
案例题空泛	措施写“加强管理”	没有主体、时间、交付物	每条措施套“谁—何时—做什么—产出什么”
绝对化陷阱	看到“一律”“不得”就选对	没有警惕绝对表述	绝对化表述默认判错，除非标准原文如此

这张表我在冲刺阶段每天扫一遍，扫到某一行心里发虚，就说明那一类还没过关，当天专门补。

5.2 命题偏好与陷阱识别

做了足够多题之后，会发现命题人有一些固定的“手法”。识别这些手法，比多背十个知识点管用。

最常用的是 近义替换 。标准里写“服务级别协议”，题干里改成“服务水平约定”，选项里再混一个“服务承诺书”，看你能不能对上。应对办法是把核心术语的常见同义说法整理一份，心里有数就不慌。

第二种是 条件反转 。把“应当”改成“可以”，把“必须”改成“宜”，一字之差答案就反了。读题时遇到这类词要放慢速度，用笔圈出来。

第三种是 场景冗余 。题干写一大段背景，其实有用的就最后一句。我一开始总被前面的描述带跑，后来养成习惯：先看问题问什么，再回头找题干里跟问题相关的条件，效率提升明显。

第四种是 选项对称 。四个选项里如果两个互为反义，答案大概率在这两个里。这个规律不是绝对的，但在时间紧张时可以做概率判断。

5.3 我踩过的三个坑

第一个坑是 把练习题当模拟考 。我早期每套题都掐表做，做完对答案看分数，分数高就安心，低就焦虑。后来发现这完全没意义——练习题的分值分布和真题不一样，用它估分只会误导自己。练习题的正确用法是 诊断 ，不是 估分 。

第二个坑是 只复习错题，不复习对题 。有些题我是蒙对的，当时没标记，考场上同样的知识点换个问法就错了。后来我改成“不确定的题一律标记”，哪怕选对了也进错题本，这一改，正确率的稳定性立刻上来了。

第三个坑是 案例题不动笔 。我前期看案例题都是“想想思路”，觉得想通了就行。真正动笔才发现，脑子里的逻辑落到纸上会散架，写出来的东西跟自己想的不一样。案例题必须动笔，而且最好手写，因为考场是手写，手写的速度和排版跟打字完全两回事。我练了大概十道手写案例，才把时间控制在十五分钟以内。

6. 三十天冲刺节奏与考场策略

最后说说时间安排。我给自己的节奏是按三十天倒排的，如果你时间更紧，把比例压缩就行，但 顺序不要变 。

6.1 三十天时间分配表

阶段	天数	主要任务	产出物
打底	第 1–8 天	通读标准框架，手画生命周期表与四要素表	两张手绘图
精练	第 9–18 天	每天一组练习题，重点做解析和归类	错题归因表
攻坚	第 19–24 天	集中攻计算题和案例题，每天一道手写案例	计算速查卡、案例模板
模拟	第 25–28 天	完整限时模拟两到三套	时间分配记录
回炉	第 29–30 天	只看错题本和速查卡，不做新题	心态稳定

打底阶段千万不要跳过，很多人上来就做题，做一道错一道，越做越焦虑。花八天把骨架搭起来，后面做题速度会快一倍——因为你不再需要每道题都从头推理，而是“认出来”它属于哪一块。

精练阶段我建议 每天只做一组，但把这一组吃透 。做完对答案，错的标红，对的但不确定的标黄，然后每道标色题都写一句“这题考什么”。一天一组，十天十组，比你一天刷五组有用得多。

攻坚阶段最痛苦，但也最提分。计算题就那么几个公式，练熟之后基本不会错；案例题难在表达，必须动笔，写十道之后你会发现套路是固定的，四段结构一摆，内容填空就行。

模拟阶段的目的不是估分，是练 时间分配 。我的分配是单选 30 分钟、多选 25 分钟、判断 10 分钟、计算 20 分钟、案例 35 分钟，留 20 分钟检查。第一次模拟我案例超时了将近十分钟，原因是前面多选题纠结太久，调整之后才稳住。

6.2 考场答题顺序与检查清单

进考场后我的一般顺序是：先通览一遍，标出三类题——秒会的、要想的、完全没谱的。然后按顺序做，遇到“要想的”超过一分钟没思路就先跳过，标记后继续。“完全没谱”的题最后统一处理，用排除法至少拿一半概率。

检查阶段只看三样东西：一是有没有漏答，尤其是多选题和案例题的分小问；二是计算题的单位和取整，人力必须向上取整，百分比保留几位看题干要求；三是绝对化表述的判断题，考场上紧张时容易反过来判。

提示：案例题如果时间不够，先写措施段。原因分析写不完整扣分有限，措施段空着直接损失大头。这是我从两次模拟超时里换来的经验。

我在实际备考中体会最深的一点是，这套考试真正筛的不是记忆力，而是 你有没有用体系的眼光看过运维这件事 。天天在工位上救火的人，做场景题反而容易错，因为他的经验是碎片化的，跟标准语境对不上；而那些把五个阶段、四个要素在脑子里串成一条线的人，即使一线经验不多，答题也更稳。练习题的作用就是帮你把碎片串起来——每错一道，就是找到一根还没接上的线头。我最后阶段基本不刷新题了，就反复看自己整理的那张错题归因表，看到能背下来为止，因为我知道，考场上真正会绊倒我的，一定是那几个我反复错的地方，而不是什么没见过的新知识。