Wiki source code of 发布越来越快,用户却越来越烦:ITIL v5 其实是在提醒你把“部署”变成可控交付
Last modified by superadmin on 2026/02/20, 07:04
Hide last authors
| author | version | line-number | content |
|---|---|---|---|
| |
1.1 | 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 | |||
| |
4.1 | 44 | (% style="text-align:center" %) |
| 45 | [[image:1b94385d-51e7-4e32-8441-05a6fc7c2f23.jpg||height="323" width="549"]] | ||
| |
1.1 | 46 | |
| 47 | 你可以这样理解: | ||
| 48 | |||
| 49 | • **发布(release)**:把变更以可理解、可沟通、可采用的方式交付给用户与组织,强调节奏与体验 | ||
| 50 | |||
| 51 | • **部署(部署):**把代码、配置、工件推到生产环境(live environment)里,强调技术执行与自动化 | ||
| 52 | |||
| 53 | 部署可以很频繁,甚至每天多次;发布不一定要同样频繁,因为发布涉及用户预期、培训、支持口径、沟通节奏。 你把部署当发布,就会把用户折腾疯;你把发布当部署,就会把自己拖慢。 | ||
| 54 | |||
| 55 | |||
| 56 | ITIL 第5版的体验优先,会逼你把这两件事分清楚: | ||
| 57 | |||
| 58 | • 技术变化可以小步快跑 | ||
| 59 | |||
| 60 | • 用户可感知的变化必须可管理、可沟通、可采用 | ||
| 61 | |||
| 62 | |||
| 63 | == 三、持续部署做得勤快,体验却变差:根因通常不是“变得太快”,而是“变得没谱” == | ||
| 64 | |||
| 65 | |||
| 66 | 我见过体验被持续部署拖垮的团队,问题往往集中在三点: | ||
| 67 | |||
| 68 | 1. ((( | ||
| 69 | **验收标准太薄** 只要流水线绿了就部署,但验收标准只覆盖功能正确性,没覆盖性能、可用性、可观测性、回滚与支持准备。 于是每次部署都带一点小风险,小风险累积成大麻烦。 | ||
| 70 | ))) | ||
| 71 | 1. ((( | ||
| 72 | **转换就绪度没做** 很多团队没有把转换当成一段独立活动,只当成“点按钮”。 结果上线后才发现:监控没接、警报不准、日志没打、支持没口径、变更日程没人对齐。 | ||
| 73 | ))) | ||
| 74 | 1. ((( | ||
| 75 | **支持被动挨打** 用户一有申告,支持人员只能解释“刚上线了一个版本”,但不知道改了什么、影响是什么、怎么绕行。 支持没有能见度范围,没有可观测性信息,最后只能靠猜。 | ||
| 76 | ))) | ||
| 77 | |||
| 78 | 所以体验差不是因为你部署快,而是因为你没有把“快”变成“可控”。 | ||
| 79 | |||
| 80 | |||
| 81 | == 四、把发布与部署放进生命周期的八个阶段活动:你会知道该前置哪些准备 == | ||
| 82 | |||
| 83 | |||
| 84 | ITIL 第5版最有用的一点,就是让你把发布与部署放回全生命周期,而不是只盯着流水线。 | ||
| 85 | |||
| |
4.1 | 86 | (% style="text-align:center" %) |
| 87 | [[image:d4aeb615-48e4-46cf-87ef-1a6687d8fb93.jpg||height="119" width="577"]] | ||
| |
1.1 | 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 | |||
| 142 | |||
| 143 | == 六、能见度范围要明确:IT支持团队必须“看得见”你在变什么 == | ||
| 144 | |||
| 145 | |||
| 146 | 发布频率高的组织,最容易忽略支持团队的能见度范围。 结果就是:部署做得很快,IT支持人员却像被蒙着眼开车。 | ||
| 147 | |||
| 148 | |||
| 149 | 你至少要让IT支持人员看见: | ||
| 150 | |||
| 151 | • 这次发布涉及哪些服务、哪些功能特性 | ||
| 152 | |||
| 153 | • 哪些是已知风险、已知错误 | ||
| 154 | |||
| 155 | • 出现问题时的绕行方案与升级路径 | ||
| 156 | |||
| 157 | • 关键监控指标与警报口径 | ||
| 158 | |||
| 159 | • 变更日程与对外沟通节奏 | ||
| 160 | |||
| 161 | IT支持团队不是来背锅的,他们是体验的前线。 第5版强调体验优先,把支持人员拉进来,是必须的。 | ||
| 162 | |||
| 163 | |||
| 164 | == 七、治理、问责、可审计性:部署越自动化,责任链越要清晰 == | ||
| 165 | |||
| 166 | |||
| 167 | 持续部署很容易让人产生错觉:既然是流水线跑的,那就“没人负责”。 | ||
| 168 | |||
| 169 | |||
| 170 | 这在ITIL 第5版的治理语境下是站不住的。 自动化不能消灭责任,只能改变责任。 | ||
| 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 | |||
| 228 | |||
| 229 | 2026年1月29日,PeopleCert正式发布了ITIL 第5版。作为ITIL官方中国区大使,我将会推出系列文章帮大家解读ITIL 第5版到底有哪些重大的更新。 | ||
| 230 | |||
| 231 | 欢迎加长河老师微信achotsao,深入交流ITIL 第5版最新资讯。 |