Wiki source code of 13 某网络工程公司ITIL信息技术服务管理体系—发布流程管理办法
Version 4.1 by superadmin on 2024/06/17, 10:11
Show last authors
author | version | line-number | content |
---|---|---|---|
1 | [[返回本章节索引>>url:https://itil4hub.cn/bin/view/G%20%E5%8F%82%E8%80%83%E8%B5%84%E6%96%99/ITIL%E5%AE%9E%E6%96%BD%E9%A1%B9%E7%9B%AE%E8%B5%84%E6%96%99/ITIL%E5%AE%9E%E6%96%BD%E9%A1%B9%E7%9B%AE%E6%B5%81%E7%A8%8B%E8%AE%BE%E8%AE%A1%E6%96%B9%E6%A1%88%E9%9B%86/%E7%AE%A1%E7%90%86%E8%A7%84%E8%8C%83/]] [[ 阅读下一篇>>https://www.itil4hub.cn/bin/view/G%20%E5%8F%82%E8%80%83%E8%B5%84%E6%96%99/ITIL%E5%AE%9E%E6%96%BD%E9%A1%B9%E7%9B%AE%E8%B5%84%E6%96%99/ITIL%E5%AE%9E%E6%96%BD%E9%A1%B9%E7%9B%AE%E6%B5%81%E7%A8%8B%E8%AE%BE%E8%AE%A1%E6%96%B9%E6%A1%88%E9%9B%86/%E7%AE%A1%E7%90%86%E8%A7%84%E8%8C%83/14%20%E6%9F%90%E7%BD%91%E7%BB%9C%E5%B7%A5%E7%A8%8B%E5%85%AC%E5%8F%B8ITIL%E4%BF%A1%E6%81%AF%E6%8A%80%E6%9C%AF%E6%9C%8D%E5%8A%A1%E7%AE%A1%E7%90%86%E4%BD%93%E7%B3%BB%E2%80%94%E9%85%8D%E7%BD%AE%E6%B5%81%E7%A8%8B%E7%AE%A1%E7%90%86%E5%8A%9E%E6%B3%95/]] | ||
2 | |||
3 | |||
4 | = **某网络工程公司ITIL信息技术服务管理体系—发布流程管理办法** = | ||
5 | |||
6 | |||
7 | === **1 概述** === | ||
8 | |||
9 | |||
10 | ===== **1.1 目标** ===== | ||
11 | |||
12 | 发布是由一项或多项经过批准的变更所组成。发布管理定义了软件和相关硬件的上线(大规模实施)过程规范,并负责将经过测试无误的软硬件版本发布到目的变更地点。 | ||
13 | |||
14 | 发布管理流程目标为: | ||
15 | |||
16 | 1. 在大型或重要项目中,发布管理应成为项目总体计划的一部分,以确保企业可以进行集中的软件和硬件设计和构建,增强信息系统的整体协调性和稳定性计划和协调软件和相关硬件的发布,并通过对实施进行测试和控制,降低软硬件同时出现错误以及发布错误版本的风险; | ||
17 | 1. 使用户更多的参与发布测试,进而使用户的期望与实际发布更加一致; | ||
18 | 1. 在新版本的首次运行过程中,沟通并管理客户的期望; | ||
19 | 1. 确保与变更相关的硬件和软件是可追溯的和安全的,只有合法的、正确的、被授权的和经过测试的软硬件版本才能进入生产环境,降低了使用非法软件的风险,未经授权的拷贝和错误的版本更易于检测到; | ||
20 | 1. 确保发布过程中软件环境和硬件平台之间结合的紧密性和一致性,确保所有软件存在“最终软件库 (DSL)”中,并确保对 “配置管理数据库 (CMDB)” 进行更新。 | ||
21 | 1. 通过在不同地域内使用一致的软件,降低整体维护成本; | ||
22 | |||
23 | ===== **1.2 范围** ===== | ||
24 | |||
25 | |||
26 | |||
27 | **1.2.1 流程适用范围** | ||
28 | |||
29 | 本流程适用于常州大江网络工程有限公司(以下简称“公司”)信息技术服务管理相关部门、人员和信息系统。 | ||
30 | |||
31 | |||
32 | 1.2.2 **流程管理范围** | ||
33 | |||
34 | 发布管理负责对软件和硬件进行计划、设计、构建、配置和测试,以便为实际运行环境提供一系列的发布组件。发布管理进行控制的范围包括: | ||
35 | |||
36 | 1. 财务(资金)管理、营销管理、协同办公、人力资源管理、物资管理、项目管理和业务应用系统; | ||
37 | 1. 其它重要的自行开发系统; | ||
38 | |||
39 | 在以下情况下我们必须采用发布管理流程,而不是变更管理流程进行控制: | ||
40 | |||
41 | 1. 重大系统的变更(业务运行依赖性很强或客户影响范围很大的系统); | ||
42 | 1. 所有新增系统的首次运行; | ||
43 | 1. 多个关联变更不能独立实施,需将一组相关的变更打包成适当规模的单元。 | ||
44 | |||
45 | === **2 角色和职责** === | ||
46 | |||
47 | 发布管理流程中定义的主要角色:发布管理流程负责人、发布经理、发布主管、发布实施人、培训主管、软件控制主管等。发布管理流程负责人和发布经理可以由同一人担任。 | ||
48 | |||
49 | |||
50 | ===== **2.1 发布管理流程负责人** ===== | ||
51 | |||
52 | 发布流程负责人通过从宏观上监控流程,来确保发布流程被正确地执行。当流程不能够适应公司的情况时,流程负责人必须及时对此进行分析、找出缺陷、进行改进,从而实现可持续提高。 | ||
53 | |||
54 | 发布流程负责人的职责包括: | ||
55 | |||
56 | 1. 确保发布流程能够取得管理层的参与和支持; | ||
57 | 1. 确保发布流程符合公司实际状况和公司 IT发展战略; | ||
58 | 1. 总体上管理和监控流程,建立发布流程实施、评估和持续优化机制; | ||
59 | 1. 确保发布流程实用、有效、正确地执行,当流程不能够适应公司的情况时,必须及时对此进行分析、找出缺陷、进行改进(比如增加或合并流程的角色),从而实现可持续提高流程效率; | ||
60 | 1. 保持与其他流程负责人的定期沟通。 | ||
61 | |||
62 | ===== **2.2 发布经理** ===== | ||
63 | |||
64 | 发布流程经理全面负责发布管理流程中的所有具体活动执行,保障所有发布依照预定流程顺利执行。 | ||
65 | |||
66 | 发布经理的职责包括: | ||
67 | |||
68 | 1. 审核由变更管理流程提交的发布请求工作单,确认其正确性和必要性,必要时拒绝无关、无法实施或没有必要的发布请求; | ||
69 | 1. 审批发布请求,制定发布周期、进行分析风险控制,确保被发布的版本都是正确、且通过有效测试; | ||
70 | 1. 确定发布请求分类,指定发布负责人(发布主管),进行发布工作的总体管理与监控; | ||
71 | 1. 参与流程评估,对流程改进提出意见和建议,与流程负责人共同制定流程改进; | ||
72 | 1. 对发布参与人员工作进行管理与考评; | ||
73 | |||
74 | ===== **2.3 发布主管** ===== | ||
75 | |||
76 | 发布主管通常由与发布请求内容相关的具体技术领域的负责人担任。可以根据不同的发布种类,分派不同的人员作为发布主管。 | ||
77 | |||
78 | 发布主管主要关注在制定发布计划、组织发布实施等方面。发布主管的职责包括: | ||
79 | |||
80 | 1. 作为具体发布工作的负责人,负责领导发布的计划、准备、测试,实施工作; | ||
81 | 1. 针对具体发布请求,协调相应资源; | ||
82 | 1. 确保发布在预定的时间,资源内完成; | ||
83 | 1. 发布成功后通知配置管理流程对配置信息进行及更新; | ||
84 | 1. 在必要时,确保回退计划(Fallback Plan)得以正确实施; | ||
85 | 1. 负责收集与该发布有关的部门或小组的意见,综合发布对于应用的影响。 | ||
86 | |||
87 | ===== **2.4 发布实施人员** ===== | ||
88 | |||
89 | 发布实施人员负责在生产环境中的具体操作工作。其职责包括: | ||
90 | |||
91 | 1. 在发布主管领导下实施发布计划,必要时负责回退计划的执行。 | ||
92 | 1. 负责与发布相关的软、硬件的准备工作; | ||
93 | 1. 负责对发布系统的集成测试工作; | ||
94 | 1. 负责配合用户对发布系统的用户测试工作; | ||
95 | 1. 保持与发布主管沟通,通报发布实施的进度和结果; | ||
96 | |||
97 | ===== **2.5 培训主管** ===== | ||
98 | |||
99 | 发布系统的运行涉及多个环节,相对比较复杂。发布经理可指定发布流程中的相关培训工作由专门的培训主管负责。通过培训,相关人员能够充分掌握相应技能,保证发布系统的有效运营。 | ||
100 | |||
101 | 培训主管的职责包括: | ||
102 | |||
103 | 1. 确保发布系统的使用与维护人员获取必要知识; | ||
104 | 1. 提供发布系统的客户使用培训; | ||
105 | 1. 提供发布系统的维护操作培训; | ||
106 | 1. 提供发布系统的帮助台培训; | ||
107 | 1. 在培训中收集相关的反馈。 | ||
108 | |||
109 | ===== **2.6 软件控制主管** ===== | ||
110 | |||
111 | 软件控制主管负责公司的最终软件版本全面管理工作,通过对软件出入库、使用申请、更换等管理,保证发布系统的有效运行。 | ||
112 | |||
113 | 软件控制主管的职责包括: | ||
114 | |||
115 | 1. 确保经发布经理审批后的软件及相关组建得以记录; | ||
116 | 1. 确保及时准确地记录所有软件; | ||
117 | 1. 确保应用在测试和生产环境中,软件及相关组件和版本信息是最新和准确的,并保证记录与CMDB信息保持一致。 | ||
118 | |||
119 | 此外,根据每次发布的具体工作内容,发布经理可在发布计划初期即策划组建发布小组。发布小组是一个临时性的组织机构,目的是通过团队的工作,完成发布计划、设计、构建、测试和首次运行过程中的信息沟通、条件准备和规划的任务。发布小组中应至少包括以下角色:发布主管、软件控制主管、培训主管、测试专家。 | ||
120 | |||
121 | |||
122 | === **3 输入** === | ||
123 | |||
124 | |**编号**|**输入项**|**来源**|**周期** | ||
125 | |((( | ||
126 | 1 | ||
127 | )))|发布申请单|发布提交人| | ||
128 | |((( | ||
129 | 2 | ||
130 | )))|发布计划|发布提交人| | ||
131 | |((( | ||
132 | 3 | ||
133 | )))|相关的配置信息|CMDB| | ||
134 | |((( | ||
135 | 4 | ||
136 | )))|相关的SLA|服务级别管理流程| | ||
137 | |((( | ||
138 | 5 | ||
139 | )))|相关的容量计划|容量管理流程| | ||
140 | |||
141 | === **4 输出** === | ||
142 | |||
143 | |**编号**|**输出项**|**去向**|**周期** | ||
144 | |((( | ||
145 | 1 | ||
146 | )))|服务、系统、软件、硬件、补丁程序|生产系统| | ||
147 | |((( | ||
148 | 2 | ||
149 | )))|软件、补丁程序|记录| | ||
150 | |((( | ||
151 | 3 | ||
152 | )))|硬件|日常运维| | ||
153 | |((( | ||
154 | 4 | ||
155 | )))|设计方案、开发文档、测试文档、技术支持文档、培训资料|CMDB、知识库| | ||
156 | |((( | ||
157 | 5 | ||
158 | )))|发布通知|相关的客户、用户、客服、技术支持人员| | ||
159 | |((( | ||
160 | 6 | ||
161 | )))|新的、更新的SLA|服务级别管理流程| | ||
162 | |||
163 | === **5 流程描述** === | ||
164 | |||
165 | |||
166 | ===== **5.1 流程描述** ===== | ||
167 | |||
168 | |**序号**|**步骤名称**|**责任人**|**流程描述** | ||
169 | |1|制定发布策略(线外)|发布经理|((( | ||
170 | 1. 发布经理定期回顾发布策略,修订不适合的部分和添加新的规定内容,并重新发布 | ||
171 | 1. 当系统进行了较大变更时,通常是技术框架、系统框架或应用结构发生改变时,发布经理需要及时变更发布策略 | ||
172 | ))) | ||
173 | |2|接受发布申请|发布经理/初审人|((( | ||
174 | 1. 变更管理流程提出发布申请工作单 | ||
175 | 1. 发布流程经理对发布请求进行审核 | ||
176 | 1. 根据发布请求分类将工作分派给相应技术职能的发布主管 | ||
177 | ))) | ||
178 | |3|制定发布计划|((( | ||
179 | 发布经理 | ||
180 | |||
181 | 发布初审人 | ||
182 | |||
183 | 发布主管 | ||
184 | )))|((( | ||
185 | 1. 发布主管接受发布工作单 | ||
186 | 1. 对当前发布计划进行检查 | ||
187 | 1. 对发布任务进行日程安排 | ||
188 | 1. 对发布任务进行人员安排 | ||
189 | 1. 制定本发布周期的发布计划 | ||
190 | 1. 发布经理正式签发发布计划,并召开协调沟通会 | ||
191 | ))) | ||
192 | |4|发布准备|((( | ||
193 | 发布主管 | ||
194 | |||
195 | 发布实施人 | ||
196 | )))|((( | ||
197 | 1. 完成与发布相关的配套设施准备工作 | ||
198 | 1. 完成与发布相关的硬件设备准备工作 | ||
199 | 1. 完成与发布相关的软件安装准备工作 | ||
200 | 1. 完成与发布相关的支持工具准备工作 | ||
201 | ))) | ||
202 | |5|系统集成测试|((( | ||
203 | 发布主管 | ||
204 | |||
205 | 发布实施人 | ||
206 | )))|((( | ||
207 | 1. 对发布所涉及变更进行统一考虑,制定集成测试计划 | ||
208 | 1. 发布流程经理对测试申请进行审批 (上传至QA环境) | ||
209 | 1. 发布主管组织进行系统集成测试 | ||
210 | 1. 通过测试后签署系统集成测试意见 | ||
211 | ))) | ||
212 | |6|用户测试|发布主管|((( | ||
213 | 1. 对于影响终端用户功能的发布,制定用户测试计划 | ||
214 | 1. 发布主管组织进行用户测试验收 | ||
215 | 1. 通过测试后签署用户测试意见 | ||
216 | ))) | ||
217 | |7|首次运行计划与审批|发布流程经理|((( | ||
218 | 1. 与 IT用户进行沟通 | ||
219 | 1. 对系统上线时间与系统用户取得一致,确定确切详细的时间安排 | ||
220 | 1. 制定沟通计划和采购计划 | ||
221 | 1. 对于符合发布要求的进行批准 | ||
222 | 1. 授权发布主管进行投产发布 | ||
223 | ))) | ||
224 | |8|培训与沟通|培训主管|((( | ||
225 | 1. 根据发布内容制定培训计划 | ||
226 | 1. 对发布相关的系统维护人员进行培训 | ||
227 | 1. 对帮助台的人员进行发布系统的培训工作 | ||
228 | 1. 对系统用户进行发布系统的培训工作 | ||
229 | 1. 对发布实施参与人进行发布培训工作 | ||
230 | ))) | ||
231 | |9|试点发布与运行|((( | ||
232 | 发布主管 | ||
233 | |||
234 | 发布实施人 | ||
235 | )))|((( | ||
236 | 1. 进行软件的分发、安装 | ||
237 | 1. 发布主管与发布实施人负责生产环境发布实施工作 | ||
238 | 1. 发布实施后对结果进行确认,如发布成功则提交发布流程经理进行确认。如发布失败则实施回退计划 | ||
239 | ))) | ||
240 | |10|确认与关闭|发布流程经理|((( | ||
241 | 1. 发布流程经理组织对发布工作的确认,关闭发布流程,向变更管理流程返回发布申请工作单。 | ||
242 | ))) | ||
243 | |||
244 | ===== **5.2 流程补充说明** ===== | ||
245 | |||
246 | |||
247 | **5.2.1 发布类型** | ||
248 | |||
249 | 如果可行,对于系统的多处变更时,应该采用全发布方式进行。对于在用系统的变更,如果不能采用全发布方式,应尽量减少增量发布,而采用包发布方式。 | ||
250 | |||
251 | 5.2.2 **紧急变更引起的发布** | ||
252 | |||
253 | 对于紧急变更引起的发布,应配合紧急变更,及时发布。 | ||
254 | |||
255 | 5.2.3 **发布失败** | ||
256 | |||
257 | 发布失败时,执行回退计划,并应得到评估和记录。 | ||
258 | |||
259 | |||
260 | === **6 表单和模板** === | ||
261 | |||
262 | |**名称**|**版本**|**负责人**|**说明** | ||
263 | |标准化表单(发布记录等)|V1.0|发布流程负责人|记录 | ||
264 | |发布流程管理报告|V1.0|发布流程负责人|报告。 | ||
265 | |||
266 | === === | ||
267 | |||
268 | === **7 关键绩效指标(KPI)** === | ||
269 | |||
270 | 发布管理的可选指标包括: | ||
271 | |||
272 | |**绩效指标**|**目标值**|**衡量方式**|**频度**|**负责人** | ||
273 | |规定周期内发布成功数量| |统计|每月|高超 | ||
274 | |规定周期内发布失败数量| |统计|每月|高超 | ||
275 | |按发布管理指标类型的发布数量| |统计|每月|高超 | ||
276 | |发布成功的比率|95%|统计|每月|高超 | ||
277 | |||
278 | === **8 流程质量控制** === | ||
279 | |||
280 | [[image:file:///C:\Users\Admmini\AppData\Local\Temp\ksohtml11140\wps12.png]][[image:图片9.png]] | ||
281 | |||
282 | |**步骤**|**输入**|**步骤描述**|**输出**|**负责人** | ||
283 | |((( | ||
284 | 1 现有流程评估 | ||
285 | )))|KPI、报告、流程执行过程中发现的问题|通过对KPI的完成程度,事件历史记录等数据进行差距、趋势分析定期对事件管理流程的实施有效性、服务质量和用户满意度进行回顾。|差距分析评估报告、趋势分析报告|发布经理 | ||
286 | |((( | ||
287 | 2 制定改进计划 | ||
288 | )))|差距分析评估报告、趋势分析报告|根据差距分析评估报告、趋势分析报告总结待改进项,制定改进计划,改进计划中包括:流程的待改进项和改进机会;改进收益;执行改进计划可能带来的影响和风险;所需资源;测试和培训计划;相关的支持文档等内容。|改进计划|发布经理 | ||
289 | |((( | ||
290 | 3 审批改进计划 | ||
291 | )))|改进计划|对改进计划进行评估审批。|审批后的改进计划|发布经理 | ||
292 | |((( | ||
293 | 4 执行改进计划 | ||
294 | )))|被批准的改进计划|调动资源组织相关人员执行被批准的改进计划。|实施后的改进计划、改进效果|发布经理 | ||
295 | |((( | ||
296 | 5 回顾 | ||
297 | )))|实施后的改进计划、改进结果|对改进后的结果进行回顾,评估改进计划是否成功,存在哪些待改进项。依据PDCA方法论再次执行步骤1对现有流程进行评估,对流程进行持续改进,起到对流程质量控制的作用。|回顾结果|发布经理 | ||
298 | |||
299 | === === | ||
300 | |||
301 | === **9 与其它流程的接口** === | ||
302 | |||
303 | |||
304 | **[[image:图片10.png]]** | ||
305 | |||
306 | [[image:file:///C:\Users\Admmini\AppData\Local\Temp\ksohtml11140\wps13.jpg]] | ||
307 | |||
308 | 在实际运营环境中,软件和硬件的新发布利用了配置管理和变更管理中的控制流程。发布管理流程从变更管理流程接收正常变更的发布请求工作单,同时变更管理通过实时了解发布工单的状态来监控发布的实施。在发布工作完成后由发布主管协调配置管理流程对与发布相关的配置信息进行及时更新工作。 | ||
309 | |||
310 | * **变更管理** | ||
311 | |||
312 | 变更管理需要确定多少项变更可以组合在一项发布中。变更管理描述了确保所有变更都是经过批准的程序,包括影响度分析以及对所要资源的分析。 | ||
313 | |||
314 | 变更管理通过发布流程实现变更系统在生产环境中的发布,同时发布流程为变更流程提供变更实现的时间表。变更管理流程完成发布所更改配置项在配置管理数据库中的更新工作。 | ||
315 | |||
316 | * **配置管理** | ||
317 | |||
318 | 当一个新版本的软件或硬件被导入最终软件库中,配置管理应当将这些信息同步添加到配置管理数据库中。同样,当新的或者变更过的软硬件转出时,配置管理数据库中的信息也要相应的进行更新。发布管理在发布过程中需要用到配置管理提供的各种配置信息。 | ||
319 | |||
320 | |||
321 | === **11 术语定义** === | ||
322 | |||
323 | |**术语**|**定义** | ||
324 | |**最终软件库(DSL)**|用来储存和保护所有最终授权版本的软件配置项的安全库。发布管理涉及从软件被纳入最终软件库开始的整个软件生命周期。DSL中可能包括同一种软件的多个版本,包括存档版本、相应的文档记录和源代码等。 | ||
325 | |**发布来源代码**|发布来源代码是指发布以什么样的途径输入到发布管理流程中。 | ||
326 | |**发布分类**|发布分类代表当前发布所属的应用系统或其模块的情况,是对流程过程中的沟通和日后统计分析的重要信息。 | ||
327 | |**发布状态代码**|状态代码标识某条记录当前处于何种阶段,是流程中各参与人员沟通的工具,也是流程与流程间流转衔接的纽带。 | ||
328 | |||
329 | === **12 附则 ** === | ||
330 | |||
331 | **1 本管理办法由技术部负责组织制定、解释和修改,各部门可根据本规定制定相应的实施细则。** | ||
332 | |||
333 | **2 本管理办法自印发之日起实行。** | ||
334 | |||
335 | **3 相关文件:** | ||
336 | |||
337 | 《信息技术服务管理手册》 | ||
338 | |||
339 | 《信息技术服务管理策略》 | ||
340 | |||
341 | 《变更流程管理办法》 | ||
342 | |||
343 | 《记录控制管理规定》 | ||
344 | |||
345 | **4 相关时间要求:** | ||
346 | |||
347 | 管理办法中规定的“每月”为每月10号前; | ||
348 | |||
349 | 管理办法中规定的“每季度”为每季度第每月10号前; | ||
350 | |||
351 | 管理办法中规定的“每半年”为每半年度第一个月15号前; | ||
352 | |||
353 | 管理办法中规定的“每年”为每自然年度第一个月20号前; | ||
354 | |||
355 | 如遇节假日可顺延。 | ||
356 | |||
357 | |||
358 | [[返回本章节索引>>url:https://itil4hub.cn/bin/view/G%20%E5%8F%82%E8%80%83%E8%B5%84%E6%96%99/ITIL%E5%AE%9E%E6%96%BD%E9%A1%B9%E7%9B%AE%E8%B5%84%E6%96%99/ITIL%E5%AE%9E%E6%96%BD%E9%A1%B9%E7%9B%AE%E6%B5%81%E7%A8%8B%E8%AE%BE%E8%AE%A1%E6%96%B9%E6%A1%88%E9%9B%86/%E7%AE%A1%E7%90%86%E8%A7%84%E8%8C%83/]] [[ 阅读下一篇>>https://www.itil4hub.cn/bin/view/G%20%E5%8F%82%E8%80%83%E8%B5%84%E6%96%99/ITIL%E5%AE%9E%E6%96%BD%E9%A1%B9%E7%9B%AE%E8%B5%84%E6%96%99/ITIL%E5%AE%9E%E6%96%BD%E9%A1%B9%E7%9B%AE%E6%B5%81%E7%A8%8B%E8%AE%BE%E8%AE%A1%E6%96%B9%E6%A1%88%E9%9B%86/%E7%AE%A1%E7%90%86%E8%A7%84%E8%8C%83/14%20%E6%9F%90%E7%BD%91%E7%BB%9C%E5%B7%A5%E7%A8%8B%E5%85%AC%E5%8F%B8ITIL%E4%BF%A1%E6%81%AF%E6%8A%80%E6%9C%AF%E6%9C%8D%E5%8A%A1%E7%AE%A1%E7%90%86%E4%BD%93%E7%B3%BB%E2%80%94%E9%85%8D%E7%BD%AE%E6%B5%81%E7%A8%8B%E7%AE%A1%E7%90%86%E5%8A%9E%E6%B3%95/]] |