一、SLA 是什么——一句话定位
SLA（服务级别协议）就是服务提供方和客户之间，把"服务质量承诺"白纸黑字签下来的合同。
| 维度 | 内容 |
|---|---|
| 定义 | 服务双方就服务质量、范围、责任、违约处理等达成的书面协议 |
| 本质 | 把模糊的"服务好"变成可度量、可考核、可追责的数字承诺 |
| 作用 | ① 锁定服务范围 ② 量化服务质量 ③ 明确违约后果 ④ 沉淀服务对账依据 |
| 教材定位 | 教材第 2 版第 12 章 ITSS 服务运营阶段（PIOIS 中的 O）核心工作 |
记一句话总结：SLA 是服务管理的"度量衡"——没有 SLA 的服务管理就是凭感觉打分，这句话也是论文里非常好用的金句。
我每年带学员都会先讲一个"为什么需要 SLA"的故事——某 IT 服务商和客户对接 3 年，没签过正式 SLA、双方靠口头说"我们尽量保证可用"。后来一次系统中断 6 小时，客户索赔 50 万、服务商认为"没那么严重赔 5 万"，两边吵到法院——法官一句话："没有 SLA 就没有违约标准，请双方各自举证"。最后判决双方各退一步赔 20 万、彻底闹翻。这就是没 SLA 的代价——任何长期服务关系，没有 SLA 等于把双方都暴露在"事后扯皮"的风险里。所以 SLA 不是"愿意不愿意"的事，是任何正式 IT 服务关系都必须有的底线工具。
二、SLA 在 ITSS 体系里的位置
先看 SLA 在 ITSS 整体里的位置——这是案例题最爱考的关联问题。
记忆口诀：SLA 是 ITSS 服务运营阶段的核心工作——属于 PIOIS 五阶段中的 O（Operation 服务运营），由 PPTR 四要素里的"过程"维度承载，关联"人员"维度（运营团队）和"技术"维度（监控工具）。这种"既属于阶段 X、又承载于要素 Y"的纵横交叉考法是案例题难点。
去年（2024 下）案例题就出过这种纵横交叉题——给一段服务管理场景，问"按 ITSS 体系拆解，该场景涉及哪些要素和哪些阶段"。能正确同时答出"PPTR 四要素中主要涉及过程 + 人员 + 技术"和"PIOIS 五阶段中主要在服务运营阶段"的同学，案例题这一问几乎拿满。所以 ITSS 这一章的横纵两套坐标必须同时记牢。
三、SLA 必背的 5 类核心指标
这是综合知识题最爱考的部分。SLA 指标按业内常用分类分 5 大类——每类指标的定义、计算公式、行业典型值都要记牢。
第 1 类：可用性指标（最高频）
| 指标 | 定义 | 计算公式 | 行业典型值 |
|---|---|---|---|
| 系统可用率 | 服务正常运行时间占总时间的比例 | 可用率 = （总时间 − 停机时间）÷ 总时间 × 100% | 一般业务 99.5% / 重要业务 99.9%（3 个 9）/ 核心业务 99.95% / 关键业务 99.99%（4 个 9） |
| 月停机时间上限 | 按可用率反推的月度允许停机分钟数 | 月停机上限 = 30 天 × 24 小时 × 60 分 × (1 − 可用率) | 99.9% → 约 43 分钟 / 月；99.99% → 约 4 分钟 / 月 |
"几个 9"是高频考点——3 个 9 = 99.9%、4 个 9 = 99.99%、5 个 9 = 99.999%。记住每多一个 9，停机时间砍 10 倍。
帮你具体感受一下数量级——按 1 年（365 天 × 24 小时 = 8760 小时）计算：99.9% = 全年停机 8.76 小时（约半个工作日）；99.99% = 全年停机 52.6 分钟（不到 1 小时）；99.999% = 全年停机 5.26 分钟（一杯咖啡的时间）。从 99.9% 到 99.999% 看着只多了 2 个 9，实际成本从 1 倍翻到 100 倍以上——因为要做异地双活、双路供电、热备切换、自动化运维、7×24 NOC 等一整套体系。所以别一上来就追求 5 个 9，得按业务实际重要性匹配——核心业务上 4 个 9 已经很有诚意了，5 个 9 通常只在金融核心交易、电信级、航空、医疗等极端场景用。
第 2 类：响应时间指标
| 指标 | 定义 | 行业典型值 |
|---|---|---|
| 平均响应时间 | 从用户提交请求到系统返回首个有效响应的时间 | Web 应用 < 3 秒 / API 接口 < 500 毫秒 / 报表查询 < 10 秒 |
| 95 分位响应时间 | 95% 的请求响应时间不超过该值（业内更常用，比平均值更能反映用户体验） | 比平均值再加 1-2 秒 |
| 99 分位响应时间 | 99% 的请求响应时间不超过该值 | 比 95 分位再加 1-2 秒 |
教材里讲到响应时间一般用平均值，但实际项目里 95 分位 / 99 分位更常用——案例题里如果让你设计 SLA，建议两种都写出来，体现专业度。
为什么实际项目用分位值而不用平均？因为平均值很容易被极少数极端慢请求拉高 / 极少数极快请求拉低，反映不出"绝大多数用户的真实体验"。比如 100 个请求，99 个 1 秒、1 个 100 秒——平均值约 2 秒看起来还行，但 95 分位是 1 秒、99 分位是 100 秒——实际有 1% 的用户在等 100 秒。分位值能精准抓到"尾部体验"，这是平均值掩盖不了的真相。
第 3 类：服务台响应解决指标
| 优先级 | 响应时间 | 解决时间 | 适用场景 |
|---|---|---|---|
| 紧急（P1） | 15 分钟 | 4 小时 | 核心业务中断、影响所有用户 |
| 高（P2） | 30 分钟 | 8 小时 | 重要业务受影响、部分用户无法使用 |
| 中（P3） | 2 小时 | 24 小时 | 一般业务问题、单用户受影响 |
| 低（P4） | 4 小时 | 72 小时 | 咨询类、非紧急问题 |
4 级优先级 × 响应 / 解决双指标 = 8 个数字——案例题里给一个场景让你判定优先级或写 SLA 时间，这张表必须背熟。
判定优先级有 2 个标准：① 业务影响（是否核心业务）；② 影响范围（是否影响多数用户）。两个标准都"是"= P1 紧急；一个"是"= P2 高；都"否但仍有业务影响"= P3 中；纯咨询性 = P4 低。这套判定逻辑案例题里直接拿来套就行。
第 4 类：质量类指标
| 指标 | 定义 | 行业典型值 |
|---|---|---|
| 一次解决率（FCR） | 首次响应就解决的工单占比 | ≥ 70% |
| 重复故障率 | 30 天内同一根因故障再次发生的比例 | ≤ 5% |
| 服务变更成功率 | 变更后未引发新故障的比例 | ≥ 95% |
| 客户满意度（CSAT） | 客户对服务的主观评分 | ≥ 4.5 分 / 5 分制 |
质量类指标比前 3 类"硬指标"更能反映服务真实水平——可用率 99.95% 看着漂亮，但如果一次解决率只有 30%、CSAT 才 3 分，说明系统虽然没大宕机但小问题不断、用户体验很差。论文里如果能把硬指标和质量指标结合写（"既要关注可用率等硬数字、也要关注一次解决率和满意度等软数字"），思想深度档位明显高一档。
第 5 类：合规与报告指标
| 指标 | 内容 |
|---|---|
| SLA 报告周期 | 月度报告 / 季度复盘 / 年度评审 |
| 违约处理 | 单次违约 / 累计违约的赔偿比例（如月服务费的 5-10%） |
| 升级机制 | 重大事件升级路径（一线 → 二线 → 主管 → 高管） |
5 类指标里最容易被忽略的是第 5 类——很多同学答题时把前 4 类指标列得很全，第 5 类合规报告直接漏掉，结果丢 2-3 分。完整 SLA 必须 5 类全有，少一类都不算合格 SLA。
四、SLA 设计的 5 步法
教材第 2 版强调"SLA 不是抄一份模板"——必须按 5 步法量身设计。
第 1 步 识别业务关键服务——梳理出哪些是"中断 5 分钟就上新闻"的核心服务（如政务一网通办主入口）、哪些是"中断半天客户感知不到"的边缘服务（如内部知识库）。识别方法可以用"3 问"——这个服务中断 30 分钟会上新闻吗 / 中断 1 小时会被监管追责吗 / 中断 4 小时会被客户索赔吗。3 个都"是"就是核心服务、有 1-2 个"是"就是重要服务、都"否"就是普通服务。
第 2 步 分级定义——按业务影响划分核心 / 重要 / 普通 3 档，每档对应不同的可用率、响应时间、优先级。别一刀切——核心服务 99.99% 没必要全套到边缘服务上、成本会爆。一个常见的"分级失败"案例——某企业把所有业务都按 4 个 9 签 SLA，结果一年下来运维成本翻 3 倍、还经常违约赔款；后来按核心 / 重要 / 普通 3 档重新签，核心 4 个 9、重要 3 个 9、普通 99%，总成本砍 40%、违约率反而下降。分级的本质是把有限的运维资源压在最重要的服务上，这是 SLA 设计的灵魂。
第 3 步 量化指标——按第三节 5 类指标分别定值，每项都要数字化、可监控、可追溯。不能定"较高可用性""快速响应"这种空话。量化的一个小窍门——所有指标都要"主语 + 数字 + 单位 + 时间窗"四要素齐全。比如"核心系统月度可用率 ≥ 99.95%"比"系统稳定可用"明确 10 倍——前者能监控、能考核、能追责，后者就是空话。
第 4 步 协商签订——服务提供方和客户开会逐项过 SLA 草案，达成共识后签约。这一步最忌"单方面拍板"——客户不认的 SLA 在违约时是引不来共识的。协商时最容易拉锯的 3 个点：①可用率档位（客户希望 4 个 9、提供方希望 3 个 9，成本差 5-10 倍）；②违约赔偿比例（客户希望按整年合同额、提供方希望按月服务费）；③升级触发条件（多久没解决就要升级到高管层）。这 3 个点要提前留谈判空间，别一上来就把底线亮出来。
第 5 步 监控考核——上线后每月出 SLA 报告（各项指标实际值 vs 承诺值、达成率、违约赔偿），每季度复盘是否需要调整指标。这一步最容易被忽视——很多企业 SLA 签完就锁在抽屉里，没人定期对账、没人定期复盘，到出事时才翻出来发现"承诺的指标和实际情况差出 10 倍"。月度报告 + 季度复盘 + 年度评审"3 个时间窗"必须固化成例行机制，否则 SLA 就是死的。
5 步闭环跑起来，SLA 才是活的服务管理工具，不是写完就放进柜子的合同。
闭环里最关键的反馈环——第 5 步的考核数据要喂回第 1 步的"业务关键服务识别"。比如月度报告显示某个一开始被定为"普通服务"的系统每次出故障客户投诉量都很大，说明它实际的业务重要性被低估了——下一个 SLA 修订周期就要重新定级、可用率档位上调一档。SLA 闭环跑得好的企业，往往一年内会动态调整 10-20% 的服务定级、SLA 在 6-12 个月内迭代到 v2、v3 版本。SLA 不是签一次的合同、是持续迭代的活文档——这是论文里非常好用的金句。
五、案例题最爱考的 3 种 SLA 题型
题型 1：判定优先级
典型题干："某政务云上 12306 售票系统在春运期间访问超时，导致 30% 用户买不到票。请按 SLA 优先级判定，并给出响应 / 解决时限。"
答题模板：核心业务 + 影响 30% 用户 → 判定 P1 紧急（核心业务受影响）→ 响应时限 15 分钟 / 解决时限 4 小时 → 同时启动应急升级路径（一线→二线→主管→高管）。
加分细节：可以补一句"考虑春运高峰特殊场景，建议把 P1 响应时限压缩到 5 分钟、解决时限压缩到 1 小时，并启动应急扩容预案"——这种"标准 SLA + 场景化加强"的答法体现你不是死背模板、是真懂业务，能多拿 2-3 分。
题型 2：设计 SLA
典型题干："请为某省政务云的 3 类业务系统（核心 / 重要 / 普通）设计 SLA 关键指标。"
答题模板：分 3 档 × 4 类指标列表——可用率、响应时间、解决时限、报告周期。别忘了写"违约处理"和"升级机制"这两块，很多同学答完前 4 类就停了、被扣 2-3 分。
具体写起来——核心业务（如政务一网通办主入口）可用率 99.95% / 紧急响应 15 分钟 / 解决 4 小时 / 月度报告；重要业务（如政务办公系统）可用率 99.9% / 紧急响应 30 分钟 / 解决 8 小时 / 月度报告；普通业务（如内部培训平台）可用率 99% / 响应 2 小时 / 解决 24 小时 / 季度报告。违约处理按服务费 5-10% 阶梯赔偿。这一答就是一个完整的 SLA 设计骨架。
题型 3：分析 SLA 违约
典型题干："某 IT 服务商连续 3 个月 SLA 达成率低于 90%，请分析可能的原因并给出改进建议。"
答题模板：从 ITSS 四要素 PPTR 分析——
- 人员：团队能力不足 / 人手紧张
- 过程：流程不闭环 / 监控不及时
- 技术：监控工具不到位 / 自动化欠缺
- 资源：CMDB 不全 / 配置管理混乱
改进建议对应 4 要素一一列方案。这种"按 PPTR 四要素拆"的答题骨架是案例题拿高分的关键，凡涉及 ITSS 改进类问题都套这个骨架。
具体改进建议示范——人员维度：扩编 5 名二线工程师 + 季度技能认证；过程维度：梳理事件升级流程 + 建立月度 SLA 复盘机制；技术维度：部署 APM 应用性能监控工具 + 自动化告警；资源维度：完善 CMDB 配置基线 + 建立知识库。这一答 4 维度 8 条具体动作，比"加强组织管理、提升服务能力"这种空话强 10 倍。
六、3 个高频踩坑
坑一：把"几个 9"算错。3 个 9 = 99.9% 不是 99.999%，5 个 9 = 99.999% 不是 99.9%。每多一个 9，停机时间砍 10 倍。算错一档差出 10 倍停机量、SLA 完全不一致。综合知识里这道题年年出，写错就是直接丢分——背的时候默念"几 9 几 9 几 9"把 3/4/5 三档全部串起来记。
坑二：把 SLA 和 OLA / UC 搞混。
- SLA：服务提供方 vs 外部客户的协议
- OLA（Operational Level Agreement，运营级别协议）：IT 部门内部各小组之间的协议
- UC（Underpinning Contract，支撑合同）：IT 部门 vs 外部供应商的合同
三层协议合起来才能撑住 SLA 承诺。综合知识题里这三个英文缩写经常出题区分，别答反。
打个比方就好记——你向客户承诺 P1 事件 15 分钟响应（这是 SLA），但你团队内部数据库小组和应用小组之间也要约定"数据库小组 5 分钟内必须配合排查"（这是 OLA），同时你和外部硬件供应商签了"备件 4 小时到货"（这是 UC）。SLA 是对外承诺、OLA 是内部分工、UC 是外部支撑——三层合起来才能兑现 15 分钟响应这个对外承诺。任何一层断了，SLA 就兑现不了。
坑三：SLA 没和监控工具对齐。SLA 写了"核心系统可用率 99.95%"，但监控工具根本没采集这个指标——这种 SLA 是死的。写 SLA 之前必须确认每项指标都有对应的监控点 + 报表自动产出，否则就是纸面承诺。我见过最离谱的案例是某公司 SLA 上写"P1 事件 15 分钟响应"，但服务台连个值班排班表都没有——夜里 2 点出事根本没人接电话。这种 SLA 不仅是死的，是给自己挖坑——签字那一刻就埋下了大额违约赔偿的雷。这就是为什么 SLA 设计第 1 步要先识别业务关键服务——你得先知道哪些服务你真有能力守住、哪些目前的资源根本撑不起。
七、本讲总结
| 维度 | 关键事实 |
|---|---|
| SLA 定义 | 服务双方就服务质量、范围、责任的书面协议 |
| 教材定位 | 教材第 2 版第 12 章 ITSS 服务运营阶段 |
| 5 类核心指标 | 可用性 / 响应时间 / 服务台响应解决 / 质量 / 合规报告 |
| 4 级优先级 | P1 紧急 15min/4h、P2 高 30min/8h、P3 中 2h/24h、P4 低 4h/72h |
| SLA 设计 5 步 | 识别 → 分级 → 量化 → 协商 → 监控 |
| 易混三协议 | SLA（对外）/ OLA（内部）/ UC（对供应商） |
| 论文金句 | "SLA 是服务管理的度量衡——没有 SLA 的服务管理就是凭感觉打分"；"SLA 不是签一次的合同、是持续迭代的活文档" |
今晚一定要做的两件事：第一，把 4 级优先级的 8 个数字（15min/4h / 30min/8h / 2h/24h / 4h/72h）背下来；第二，把 SLA / OLA / UC 三个英文缩写的区别背下来。这两块是案例 + 综合双高频考点。如果你有时间再多记一件——把"几个 9"对应的年停机时间记住（3 个 9 ≈ 8.76 小时 / 4 个 9 ≈ 52.6 分钟 / 5 个 9 ≈ 5.26 分钟）——综合知识题里这道题不出则已、一出就是送分题，不容错过。
八、一对一时间
ITSS 这一章是系规 S 档章节里最容易在论文里"写出深度"的——只要你按 PPTR 四要素 + PIOIS 五阶段 + SLA 5 步法的骨架把内容填进去，论文就能稳稳到 45 分以上。但很多同学卡在"骨架知道、填不进自己项目"——这一步是一对一最能帮上忙的环节。
如果你想要把自己手里的真实项目按 ITSS 体系重新组织、做成论文储备，加我微信详聊。我每年都会陪一对一学员做 1-2 个项目的"ITSS 重组训练"，2-3 小时能把一个项目改造成"3-5 个论文方向都能用"的核心素材。
特别建议手里有 IT 服务、运维、SLA 相关真实经验的同学，优先把这一章作为论文储备的第一选择——你天然有素材底子，借这一章的骨架重组后效率最高、产出最快。完全没做过 IT 服务的同学也别慌，这一章的骨架可以套到任何"组织化管理"经验上——比如做过项目管理、客户支持、产品运营都能借这套骨架重写。
九、明日预告
明天 9/12（周六）是真题速评的日子，第 111 篇老孙带你深拆 2024 下案例第 1 题"调研步骤"满分模板——这道题去年很多同学答了一半就卡住，6 步调研法的"完整集合"漏 1-2 步是普遍现象，正好印证昨天 8 字诀里"漏"这个坑。明天把这 6 步背景、答题骨架、踩分点一次性给你讲透，对照 8 字诀过一遍，案例题答题感会再上一个台阶。我们明天见。
