Last modified by superadmin on 2025/12/23, 10:07
Show last authors
1 那台服务器的名字，我永远忘不了——它宕机过三次。 每次原因都不一样：第一次是补丁冲突，第二次是脚本误操作，第三次是配置文件丢失。 三次事故，三次停机，三次道歉。 而更令人无奈的是，三次复盘报告几乎一模一样： “已恢复正常，原因分析中。 ” 那一刻我明白，**我们不是不会修，而是不知道为什么总是坏。**
2
3
4 (% style="text-align:center" %)
5 [[image:微信图片_20251129143636_159_5.png]]
6
7 ----
8
9 ==== 一、现象：没有问题管理，复盘只是形式 ====
10
11 在IT运维里，事件解决得越快，往往越容易忽视根因。
12
13 我们擅长“止血”，但不擅长“疗伤”。
14
15 每次故障都能恢复，却从不问“为什么会发生”。
16
17 那时，我们的事件处理流程已经很完善：
18
19 工单闭环率达到98%，响应时间平均不到1小时。
20
21 但如果从“重复率”看，问题依然层出不穷。
22
23 这正是缺乏~*~*问题管理（Problem Management）~*~*的典型症状。
24
25 ITSS标准在《服务问题管理规范》中指出：
26
27 >“问题管理旨在通过根因分析与改进措施，减少或避免事件重复发生，提升组织服务稳定性。 ”
28
29 事件管理关注“恢复”，问题管理关注“预防”。
30
31 一个解决“症状”，一个治“病根”。
32
33 ----
34
35 ==== 二、根因：反复的背后是机制的缺席 ====
36
37 我带着团队做了一次“事件堆叠分析”。
38
39 我们从过去六个月的工单中筛选出重复事件，结果显示：
40
41 * (((
42 37%的故障重复发生两次以上；
43 )))
44 * (((
45 22%的故障根因描述为空；
46 )))
47 * (((
48 60%的改进措施未验证效果。
49 )))
50
51 这意味着，我们的“复盘”只是过程，没有形成机制。 很多人以为“问题管理”就是“找原因”，但真正难的是**建立体系**：
52
53 * (((
54 谁来触发问题分析？
55 )))
56 * (((
57 谁来主导根因挖掘？
58 )))
59 * (((
60 谁来跟踪改进结果？
61 )))
62
63 如果这些问题没有制度保障，任何分析都只是“自说自话”。
64
65 于是我们决定导入ITSS问题管理体系，用流程固化改进。
66
67 ----
68
69 ==== 三、机制：让根因分析变成组织习惯 ====
70
71 1. (((
72 **触发机制** 我们规定：当事件在一个月内重复两次或以上时，自动转入问题管理流程。 系统生成“问题单”，并指派责任人牵头分析。
73 )))
74 1. (((
75 **根因分析方法** 我们采用ITSS推荐的“五问法”和鱼骨图（Ishikawa Diagram）相结合的方式： 每次分析都必须回答——
76 )))
77 1. (((
78 发生了什么？
79 )))
80 1. (((
81 为什么会发生？
82 )))
83 1. (((
84 为什么没被提前发现？
85 )))
86 1. (((
87 为什么没被防止？
88 )))
89 1. (((
90 如何确保不再发生？ 分析过程全程可追踪、可复核。
91 )))
92 1. (((
93 **改进与验证机制** 所有改进措施都需定义负责人、完成时限与验证标准。 验证通过后，系统自动关闭问题单，并将改进内容同步入知识库。
94 )))
95 1. (((
96 **指标与反馈机制** 我们新增两个核心指标：重复事件率（RE）与问题关闭率（PCR）。 这些数据纳入月度绩效考核，用结果倒逼改进落实。
97 )))
98
99 作为艾拓先锋的官方ITSS授权讲师，在讲授ITSS服务项目经理认证培训课程时我会特别强调这一点：**问题管理的核心不在工具，而在文化。 **只有当组织愿意面对自己的错误，改进才会成为习惯。
100
101 ----
102
103 ==== 四、提升：让“自愈”成为能力 ====
104
105 三个月后，我们的重复故障率下降了65%，工单复盘时间缩短了一半。
106
107 更重要的是，团队的氛围变了。
108
109 以前事故一发生，大家先想“是谁的锅”；
110
111 现在，大家会主动复盘、讨论根因、提出改进。
112
113 我们建立了“问题知识库”，每条记录都附带根因分析、改进方案与验证结果。
114
115 这些知识反哺到培训体系中，新人入职后能直接学习最常见的故障场景与改进案例。
116
117 这意味着——我们的组织开始具备“学习”与“自愈”能力。
118
119 有一次，总经理在听汇报时感慨道：“以前我听你们讲KPI，现在我看到你们在讲成长。 ”
120
121 我笑着回答：“这就是ITSS的精神——让体系学会自己修复自己。 ”
122
123 自愈，是成熟组织的标志。
124
125 它不靠个人英雄，而靠机制传承；
126
127 不靠记忆，而靠知识沉淀。
128
129 当组织能把每一次问题都转化为下一次改进的动力时，
130
131 IT服务，才真正走向成熟。
深圳市艾拓先锋企业管理咨询有限公司