Version 2.1 by superadmin on 2026/02/20, 15:04
Show last authors
1 这几年很多团队都在追求一个词：快。
2
3
4 持续集成、持续交付、持续部署，流水线跑得飞起，发布频率越来越高。 可奇怪的是，业务和用户的抱怨并没有随之减少，甚至有的团队越“先进”，体验越差。 你问原因，大家会说：
5
6 “变化太频繁了，用户跟不上。 ”
7
8 “每次发布都引入一点小毛刺，积少成多。 ”
9
10 “支持每天都在解释‘为什么又变了’。 ”
11
12
13 这时候你会发现一个很尴尬的情况：
14
15 技术上你可以做到每天部署十次，但管理上你未必有能力让用户每天都舒服地接受十次变化。 交付的本质不是把代码推上去，而是让服务价值稳定地被消费，让体验不被折腾。
16
17
18 ITIL 第5版把管理对象扩展到数字产品与数字服务，并用八个阶段活动把全生命周期讲得更清楚；还强调体验优先、治理、问责和可审计性。 放到发布与部署上，它其实是在把一个被忽略的问题拎出来：**速度很重要，但可预测更重要；频率很重要，但稳定更重要。**
19
20
21 == 一、为什么第5版会逼你重新理解“发布与部署” ==
22
23
24 ITIL 第5版相对 ITIL 4 的核心升级要点如下：
25
26 • 管理对象从服务扩展到数字产品与数字服务
27
28 • 八个阶段活动的全生命周期：发现、设计、获取、构建、转换、运营、交付、支持
29
30 • 体验写入价值定义，变化本身会影响信任
31
32 • 治理强调授权、问责、可审计性与纠偏
33
34 • 人工智能与自动化纳入体系，自动化越强越需要边界
35
36 发布管理实践与部署管理实践，在第5版里不再只是技术活动，而是“转换”与“交付”的关键能力。 你做得越快，越需要治理与问责链条；你做得越频繁，越需要验收标准、可观测性和支持准备把风险兜住。
37
38
39 == 二、发布和部署到底差在哪：别再把两件事混着说 ==
40
41
42 很多团队把发布和部署混成一回事，结果工作流和责任边界就会乱。
43
44 [[image:https://my.feishu.cn/space/api/box/stream/download/asynccode/?code=Y2FiYTExYjMyZDRkOWQ4NmY5NTBmOTE3NWJjODk5YWVfUnRoMTYzam5oWEt5TDBTSnhGV3RGQzM1V0ZrR21RemhfVG9rZW46TG1wMWIzWDMwb044Vzd4Q0hpZGNXZFFibnVmXzE3NzE1NzAxMzI6MTc3MTU3MzczMl9WNA||height="251" width="554"]]
45
46 你可以这样理解：
47
48 • **发布（release）**：把变更以可理解、可沟通、可采用的方式交付给用户与组织，强调节奏与体验
49
50 • **部署（部署）：**把代码、配置、工件推到生产环境（live environment）里，强调技术执行与自动化
51
52 部署可以很频繁，甚至每天多次；发布不一定要同样频繁，因为发布涉及用户预期、培训、支持口径、沟通节奏。 你把部署当发布，就会把用户折腾疯；你把发布当部署，就会把自己拖慢。
53
54
55 ITIL 第5版的体验优先，会逼你把这两件事分清楚：
56
57 • 技术变化可以小步快跑
58
59 • 用户可感知的变化必须可管理、可沟通、可采用
60
61
62 == 三、持续部署做得勤快，体验却变差：根因通常不是“变得太快”，而是“变得没谱” ==
63
64
65 我见过体验被持续部署拖垮的团队，问题往往集中在三点：
66
67 1. (((
68 **验收标准太薄** 只要流水线绿了就部署，但验收标准只覆盖功能正确性，没覆盖性能、可用性、可观测性、回滚与支持准备。 于是每次部署都带一点小风险，小风险累积成大麻烦。
69 )))
70 1. (((
71 **转换就绪度没做** 很多团队没有把转换当成一段独立活动，只当成“点按钮”。 结果上线后才发现：监控没接、警报不准、日志没打、支持没口径、变更日程没人对齐。
72 )))
73 1. (((
74 **支持被动挨打** 用户一有申告，支持人员只能解释“刚上线了一个版本”，但不知道改了什么、影响是什么、怎么绕行。 支持没有能见度范围，没有可观测性信息，最后只能靠猜。
75 )))
76
77 所以体验差不是因为你部署快，而是因为你没有把“快”变成“可控”。
78
79
80 == 四、把发布与部署放进生命周期的八个阶段活动：你会知道该前置哪些准备 ==
81
82
83 ITIL 第5版最有用的一点，就是让你把发布与部署放回全生命周期，而不是只盯着流水线。
84
85 [[image:https://my.feishu.cn/space/api/box/stream/download/asynccode/?code=NjlmZjIxMDBkY2IyNDI1NzRkYWM0MzIyNjQ4OWQ1NjhfUGNXMlpuMllXcWRRdXVOT2Zwam1VVnBHUUNYSE9DWm5fVG9rZW46Q05vS2JGODRUb0lKdzl4akdkWGM1Q2t1bnJWXzE3NzE1NzAxMzI6MTc3MTU3MzczMl9WNA||height="121" width="584"]]
86
87 **发现与设计：**
88
89 • 用户旅程与接触点要明确，哪些变化会影响体验
90
91 • 验收标准要在设计阶段就写清楚，而不是上线前临时补
92
93 **获取与构建：**
94
95 • 工具链能力就绪：自动化、回滚、监控、日志、配置管理
96
97 • 构建产出要包括工件、版本基线、配置说明、变更影响说明
98
99 **转换：**
100
101 • 上线演练要覆盖：回滚、降级、监控、警报、支持升级路径
102
103 • 变更实施与变更授权方要对齐，变更日程要可见
104
105 • 支持团队要提前拿到口径与常见问题应对
106
107 **运营与支持：**
108
109 • 可观测性要能支撑快速定位
110
111 • 事件管理、问题管理要能关联到最近发布与部署
112
113 • 反馈回路要能推动持续改进，而不是每次都从头猜
114
115 你会发现：发布与部署不是流水线的问题，而是生命周期协同的问题。
116
117
118 == 五、验收标准怎么写才对得起“持续部署”：让它覆盖风险，而不是覆盖形式 ==
119
120
121 持续部署不是不能做，而是要把验收标准写得更像“服务能跑得稳”。
122
123
124 我建议持续部署场景的验收标准至少包括：
125
126 • 关键功能与关键错误处理通过
127
128 • 性能与容量关键指标满足目标
129
130 • 监控与警报就绪，警报准确性经过验证
131
132 • 可观测性要素齐全：日志、指标、链路追踪能支持定位
133
134 • 回滚方案可用且演练过
135
136 • 支持口径就绪，升级路径明确
137
138 验收标准不是为了写得漂亮，而是为了让你放行时有底气，复盘时可审计。
139
140
141 == 六、能见度范围要明确：IT支持团队必须“看得见”你在变什么 ==
142
143
144 发布频率高的组织，最容易忽略支持团队的能见度范围。 结果就是：部署做得很快，IT支持人员却像被蒙着眼开车。
145
146
147 你至少要让IT支持人员看见：
148
149 • 这次发布涉及哪些服务、哪些功能特性
150
151 • 哪些是已知风险、已知错误
152
153 • 出现问题时的绕行方案与升级路径
154
155 • 关键监控指标与警报口径
156
157 • 变更日程与对外沟通节奏
158
159 IT支持团队不是来背锅的，他们是体验的前线。 第5版强调体验优先，把支持人员拉进来，是必须的。
160
161
162 == 七、治理、问责、可审计性：部署越自动化，责任链越要清晰 ==
163
164
165 持续部署很容易让人产生错觉：既然是流水线跑的，那就“没人负责”。
166
167
168 这在ITIL 第5版的治理语境下是站不住的。 自动化不能消灭责任，只能改变责任。
169
170
171 你需要回答：
172
173 • 谁拥有发布节奏的决策权
174
175 • 谁定义验收标准
176
177 • 谁在异常时有授权触发回滚
178
179 • 谁对变更影响评估负责
180
181 • 证据链是否可审计：为什么当时放行、依据是什么
182
183 责任链清晰了，团队才敢跑得快；否则大家只会越来越保守。
184
185
186 == 八、人工智能怎么帮发布与部署：先做“风险提示与沟通一致性”，再谈自动决策 ==
187
188
189 人工智能在发布与部署里很有用，但我建议循序渐进。
190
191
192 更稳的用法：
193
194 • **整理**：归纳历史发布与事件的相关性，识别高风险模式
195
196 • **洞察：**对变更影响做辅助评估与风险提示
197
198 • **沟通**：生成发布说明草稿、支持口径草稿，提高一致性
199
200 • **监控**：辅助聚类警报，缩短定位时间
201
202
203 不稳的用法：让人工智能自动放行高风险发布、自动触发不可逆操作。 治理边界必须清楚，回退机制必须可用。
204
205
206 我最建议你先做一个样板：
207
208 让某个业务关键数字产品做到“部署很快、发布很稳”。
209
210
211 具体怎么做：
212
213 • 部署频率可以保持高，但发布节奏对用户可预测
214
215 • 验收标准覆盖服务稳定性与可观测性
216
217 • 转换就绪度检查固化到工作流
218
219 • 支持准备前置，口径一致
220
221 • 复盘可审计，持续改进有节奏
222
223 你只要把这个样板跑通，组织会立刻理解：快不是问题，可控才是能力。
224
225
226
227 2026年1月29日，PeopleCert正式发布了ITIL 第5版。作为ITIL官方中国区大使，我将会推出系列文章帮大家解读ITIL 第5版到底有哪些重大的更新。
228
229 欢迎加长河老师微信achotsao，深入交流ITIL 第5版最新资讯。
深圳市艾拓先锋企业管理咨询有限公司