5-6 大量IT资源的管理 · 波仔的云计算课

📄 一句话概括

机器一多，管理就分成两件事：IT 服务控制（服务台侧——接收请求、判断轻重、跟踪到底）和 IT 服务操作（现场侧——按流程执行、记录、交接）。教材把这一条放进技术章，是因为规模本身就是一种技术问题：一千台机器靠人盯是盯不住的，必须先把【怎么受理、怎么分类、怎么复盘】这套流程定下来。

📝 本节和前面几节的关系

上一节讲【算力怎么变强】，从这一节开始，问题的主语从机器换成了人——这么多资源，靠什么规则管住。

它和企业和组织的发展动向是一对：那一节讲的是对外要约定什么（服务目录、SLA、责任边界等六件事），这一节讲的是对内怎么运转（谁受理、谁执行、怎么复盘）。它也接着控制大量服务器的机制——那一节讲的是技术上的批量控制，这一节讲的是流程上的批量控制。

一、两件事，两个视角

谁	做什么	关心什么
IT 服务控制（服务台侧）	接收请求、判断轻重、跟踪到底	有没有人管、多久能好
IT 服务操作（现场侧）	按流程执行、记录、交接	做对没有、留下痕迹没有

看起来是两份活，实际上是一条线上的两端：

服务控制是【入口】：所有乱七八糟的诉求先集中到这里，由它变成有编号、有优先级、有负责人的工单。
服务操作是【执行】：拿着工单去干活，干完记录，交给下一个人。

这条线的价值在【中间那一步的转换】：用户说的是一句【我这边系统不好用了】，而服务台要把它变成【哪台机器、哪个服务、影响谁、什么优先级】。没有这一步转换，一切都会退化成【谁嗓门大谁先修】。

二、三个概念必须分清

概念	一句话	处理的目标
事件	服务已经断了或要断了	尽快恢复（先恢复，后查因）
问题	同一个事件反复出现	找到根因，让它不再来
变更	要动生产环境里的东西	让改动可控、可回滚

最容易搞混的是【事件】和【问题】，而它们的处理方式是互相矛盾的：

事件要的是快。用户还在等，这时候哪怕先重启一下把服务救回来也好——因为【服务恢复】和【查明原因】可以分开做。
问题要的是准。如果一直用【重启一下】来处理一个每周都复发的事件，那就等于每周都中断一次，永远不解决。

所以正确的顺序是：事件先恢复（哪怕手段粗暴），恢复之后立刻转成问题去查根因。这两件事由不同的人、按不同的节奏做——这就是为什么要分成两个概念，而不是一件事。

第三个概念【变更】是这两者之间的缓冲：想要根治问题，就得动生产环境（改配置、升级版本），而【动生产环境】本身就是风险源。所以要把变更单独管起来：谁可以改、改完怎么通知、出事怎么回滚。

三、动手 Demo：三笔账

看到什么算成功：

==================================================================================================
【Demo 6】大量 IT 资源的管理：IT 服务控制与 IT 服务操作
==================================================================================================
  机器多了以后，管理就分成两件事：
    IT 服务控制（服务台侧）  —— 接收请求、判断轻重、跟踪到底
    IT 服务操作（现场侧）    —— 按流程执行、记录、交接

  【一】三个必须分清的概念

  概念          一句话                                  处理的目标
  --------------------------------------------------------------------------------------------
  事件          服务已经断了或要断了                    尽快恢复（先恢复，后查因）
  问题          同一个事件反复出现                      找到根因，让它不再来
  变更          要动生产环境里的东西                    让改动可控、可回滚

  最容易搞混的是【事件】和【问题】：事件要的是【快】，
  问题要的是【准】。用查根因的速度处理事件，业务等不起；
  用重启的速度处理问题，它下周还会来。

  【二】算一笔请求处理的账（每月 1000 件请求）

  方式                        人工处理件数    每月工时        折合人力
  ----------------------------------------------------------------------------------
  纯人工：每件 12 分钟        1000 件         200.0 小时      1.25 人
  半自助：60% 走自助          400 件          80.0 小时       0.50 人
  全自助：85% 走自助          150 件          30.0 小时       0.19 人

  自助化省下的不是【单价】，是【人头】——而人头是不能按小时削的，
  所以真实的省法是【同样的人能扛更多的机器】。

  【三】两个指标：MTTR 与达成率
    MTTR（平均修复时间）：从报障到恢复的平均时长
    有流程之前约 4.0 小时，有流程之后约 1.5 小时
    SLA 达成率：承诺 99.9% 的服务，实际停了几分钟
    99.9% 一年只允许停 8.76 小时——这是算出来的红线，不是感觉。

  【四】2026 现状
    ITIL 第 5 版于 2026 年 1 月 29 日发布，是这一套方法论的当前版本。
    结构变化：原来的【服务价值链】换成【产品与服务生命周期】八阶段
    （发现、设计、获取、构建、转换、运营、交付、支持）。
    内容比例：约 40% 沿用 ITIL 4、36% 全新、24% 增改。
    ITIL 4 的证书仍然有效，官方给出的并行期到 2027 年初。
    新增的重点是【AI 治理】——AI 进了服务台，就得有人管它怎么用。

读结果：

第二张表的那句话是全节的重点：自助化省下的不是【单价】，是【人头】。因为人力成本不是线性的钱——你不能只雇 0.5 个人，要么雇一个，要么不雇。所以省下来的真正价值是【同样的人可以扛更多的机器】，这才是规模扩张时唯一能成立的逻辑。
第三段的两个指标是一体两面：MTTR 衡量【修得多快】，SLA 达成率衡量【有没有守住承诺】。只看 MTTR 会出问题：把 MTTR 压到 10 分钟，但如果每周出事三次，总停机时间照样超标。所以这两个指标必须一起看——速度和频率，缺一个都说明不了问题。

四、这套方法论为什么会长成现在这样

管理 IT 服务这件事，国际上叫 ITSM（IT 服务管理），而最有名的一套方法论是 ITIL——本节 Demo 第四段讲的正是它 2026 年的版本变化。理解它的演变，能看出这门学问在回答什么问题：

版本	核心结构	在回答什么
ITIL v3	服务生命周期（五个阶段）	服务从策划到退役怎么管
ITIL 4	服务价值系统	怎么和其他方法（敏捷、DevOps）配合
ITIL 5	产品与服务生命周期（八阶段）	怎么把产品、服务、AI 一起管

三次变化的共同方向：从【流程为中心】走向【价值为中心】，再走到【把产品和服务当成一件事】。

2026 年这一版最值得注意的两点：

它把 AI 写进了框架里，而且是当作要被治理的对象——AI 进了服务台（自动分流工单、自动回答），那就要回答【出了问题谁负责】这个问题。这就是新增的 AI 治理模块要解决的事。
它没有推翻上一版。官方明确说大部分内容沿用，已有的证书继续有效——这个做法本身说明了一件事：这类管理框架的价值在【稳定和共识】，不在于频繁换新。

30 秒实验

打开你们公司（或任意一家公司）的 IT 支持页面或服务台入口，做两件事：

看有没有分级——也就是不同的问题走不同的入口、有不同的响应时限。
看有没有【已知问题】或【故障公告】这类栏目——它对应的是本节讲的【问题】这个概念。

做完这个你会看出一个组织的成熟度：只有入口、没有分类的，说明还处在【谁先喊就先修】的阶段（也就是没有【服务控制】）；有【已知问题】栏目的，说明它已经开始把【反复发生的那些事】单独拿出来处理了（也就是有了【问题管理】）。这两个栏目有没有，比墙上贴了多少流程文件更能说明问题。

常见误区

错误：服务台就是个接电话、转工单的地方，没什么技术含量。——纠正：服务台最有价值的工作是【分类和定级】。同一句【系统不好用】，可能是个人电脑的问题、可能是账号权限的问题、也可能是核心服务已经挂了——这三种的处理方式、优先级、波及范围完全不一样。把这一句模糊的描述变成准确的分类，决定了整个组织在故障时的反应速度。这也是为什么本节把它放在【IT 服务控制】而不是【操作】那一侧。
错误：出了事赶紧修好就行，不用记录。——纠正：没有记录就没有【问题】这个概念。单个事件修完就过去了，但如果没记录，谁也发现不了【这是本周第三次同样的故障】——于是每一次都被当成新问题重新排查，成本重复付出，根因永远找不到。所以记录不是流程上的形式，它是【事件】转化为【问题】的唯一途径。
错误：上了 ITSM 工具就等于有了 ITSM。——纠正：工具只是载体，先把【提供什么、承诺多少、谁负责】想清楚才有用（4-20 里已经点过这一条）。顺序错了会得到一个很典型的结果：系统里堆着几百张没人看的工单，大家照样在群里喊人。判断标准很直接：出事的时候能不能立刻说清【这该谁管、要多久、现在达标没有】——能，说明流程真的在跑；不能，工具再多也没用。
错误：流程会让做事变慢。——纠正：流程慢的原因通常是【流程设计得不对】，不是【流程本身错】。好的流程只做三件事：把模糊变清楚（分类）、把优先级说明白（定级）、把经验留下来（记录）——这三件事都是减少重复劳动的。真正让人烦的是那些为审批而审批、加了好几个签字环节却不承担责任的流程。所以正确的做法是先看这个环节解决了什么问题，而不是笼统地反对流程。

自测三问（点开对答案）

1. 为什么【事件】和【问题】要分开处理，而不能合成一件事？ —— 因为**两者的时间要求是冲突的**。事件发生时用户还在等，**必须用最快的手段让服务恢复**——哪怕手段是重启、切备用机、临时关掉某个功能。而查明根因需要**慢慢查日志、复现、分析**，**这个过程必须等服务恢复之后再做**。如果合成一件事，就会出现两种坏结果：**要么为了查根因让用户等很久，要么为了快而永远不查根因**。分开之后，**两个目标都能追求，代价由不同的人承担。** 2. 为什么说【自助化省下的是人头，不是钱】？ —— 因为**人力成本是阶梯式的，不是线性的**。每月 200 小时的工作量需要 1.25 个人——**但现实中你只能安排 1 个人或 2 个人，不能安排 1.25 个**。所以自助化之后工作量降到 0.5 人，**省下来的并不是【0.75 人的工资】，而是【那 1 个人现在可以去干别的】**。这就解释了为什么自助化的收益通常不体现在【裁员】上，而体现在【同样的团队能支撑更多的业务】上。 3. 为什么 ITIL 5 要把 AI 治理单独做成一个模块？ —— 因为**AI 已经真的进了服务台，而它带来了一类新责任问题**。当工单是 AI 自动分类的、回答是 AI 自动生成的，**出了错该谁负责？AI 的判断依据能不能解释？训练数据里有没有偏见？** 这些都不是传统流程能回答的。**把它单独列出来，说明这门方法论承认了一件事**：AI 不是一个可以随便挂上去的工具，**它一旦参与决策，就必须有人对它的决策负责**。这也是为什么它被列为【无前置条件的独立模块】——**因为用的人可能完全不懂 AI。**

☐ 下一节（5-7 大量服务器的管理：Zabbix）