Show last authors
1
2
3 = **服务级别管理程序(#CP-0010)** =
4
5
6 === **目的** ===
7
8 本过程描述公司采用的过程方法以有效地管理服务级别管理过程。该文件表明公司IT部门符合IS0 20000中对服务级别管理过程(IS0 20000-1:2005 6.1)的要求。
9
10
11 === **范围** ===
12
13 IT服务管理体系中的服务级别管理覆盖Internet服务、管理网络服务、管理安全服务和数据中心服务。
14
15
16 ===== **1. 服务级别管理过程** =====
17
18
19 ====== **1.1服务级别管理策划(计划)** ======
20
21 开发服务级别管理并以ITSM计划为目标。
22
23
24 ====== **1.2定义服务级别管理(执行)** ======
25
26 SLM建立框架使IT部门通过计划、实施和进行服务交付管理关注客户。服务级别管理管理和协调服务级别,包括:
27
28 服务要求、服务目标和期望的协议
29
30 测量和报告达到的服务级别
31
32 调查纠正措施和正在进行的服务改进项目
33
34
35 ====== **1.3 SLM的控制和评审(检查)** ======
36
37 为符合IS0 20000-1:2005, IT部门引入框架检查服务级别管理过程的结果。IT部门有责任每月评审可用性级别并提交关键绩效报告。
38
39
40 ====== **1.4 SLM反应行动(改进)** ======
41
42 IT部门应按月评审不同服务的服务级别并指定员工评估和监控服务级别。如果没有达到服务级别,IT部门应采取改进措施确定问题。
43
44
45 ===== **2.服务级别管理程序** =====
46
47
48 ====== **2.1 服务目录** ======
49
50 服务目录定义IT部门提供的所有服务。(略)
51
52
53 ====== **2.2 服务级别协议** ======
54
55 服务级别协议是IT部门需要达到的正式文件。
56
57
58 **2.2.1**有效期
59
60 有效期在相关SLA文件中明确。在有效期内,SLA有效,直到新的协议签定为止。
61
62 **2.2.2 **授权
63
64 **2.2.3  **沟通
65
66 **2.2.4** 联系
67
68 **2.2.5** 服务时间
69
70 所有服务需要7*24小时的服务。这在服务目录中有描述。
71
72 **2.2.6 **计划和协定的中断
73
74 **2.2.7** 客户职责
75
76 **2.2.8** 冲击和分级指南
77
78 **2.2.9** 升级和告知过程
79
80 **2.2.10** 投诉程序
81
82 **2.2.11 **服务目标
83
84 **2.2.12** 工作负载限制
85
86 下述工作负载限制由lT部门提供并被客户接受。
87
88 [[image:图片1.png]]
89
90 [[image:file:///C:\Users\Admmini\AppData\Local\Temp\ksohtml10100\wps1.png]]
91
92 **2.2.13 **财务管理
93
94 **2.2.14** 内务工作程序
95
96 **2.2.15 **例外
97
98 **2.2.16 **可用性初始评审报告
99
100 可用性初始评审报告必须附在相应的SLA后面作为记录。
101
102
103 ====== **2.3 服务级别管理(SLM)过程** ======
104
105 SLM是一个持续改进循环过程。由于业务变更、增长、业务重组或合并造成的要求变更,服务级别需要重新定义或临时暂停。IT部门引入的SLM过程能灵活的应对这些变更。
106
107
108 ====== **2.3.1服务需求的协议** ======
109
110 在SLA中,IT部门将满足客户要求的服务级别。每年定期由IT部门和客户进行评审。
111
112 变更可以在任何时间(非预定会议)根据SLA变更管理提出。
113
114
115 ====== **2.3.2服务目标** ======
116
117 服务目标由服务级别协议描述。更新的服务目标将列入服务管理委员会的日程。如果达到服务目标存在困难(如目标无法达到),IT部门和客户将定期评审以解决问题。
118
119
120 ====== **2.3.3测量和报告** ======
121
122 IT部门并每月向客户报告服务级别的达成情况。
123
124 下面的例子用来说明如何计算量测指标:
125
126 例如:
127
128 一个邮件服务器宕机影响1/3的用户2小时,则网络可用性:
129
130 Network Availability =100%*( (30 days×24 hours× 60 mins) -(2 hours×60 mins) × 1/3
131
132 customer impacted) /(30 days ×24 hours × 60 mins)=99.9074%
133
134
135 ====== **2.3.4纠正和预防措施** ======
136
137 纠正和预防措施过程如下:
138
139 每天进行异常和趋势检测。
140
141 根据事件的性质,问题将被提升到管理层。
142
143 一般问题将在月度问题管理会议给予关注。
144
145
146 ====== **2.3.5服务改进计划** ======
147
148 SLM过程负责人每月监控SLA
149
150
151 ====== **2.3.6 SLA变更管理** ======
152
153 如果需要变更,需要通过下述过程:
154
155 召开会议讨论SLA,两方代表必须参加。
156
157 E-mail沟通是另外的讨论SLA的渠道。
158
159 变更可以通过会议和电子邮件评估和决定。
160
161
162 ===== **3.0  参考** =====
163
164
165
166
167 ===== **4.0  批准** =====
168
169
170 技术总监 日期:
171
172
173
174
175 = **信息安全管理(#cp-0011)** =
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 公司所有人员和供应商,以及其他合约规定下的受雇佣者,只要可能接触到信息安全管理体系范围内的信息资产,都有责任遵守这一信息安全政策。本政策由IT管理部批准,并支持。
210
211
212 ===== **目的** =====
213
214 遁过适当的风险评估,识别信息资产价值,明确那些会让其暴露于风险之中的弱点和威胁。
215
216 通过设计、实施和维护一套规范的信息安装管理制度将风险减低到可接受的程度。
217
218 需要遵守的法律法规包括:
219
220 公司法
221
222 数据保护法
223
224 计算机使用保护法
225
226 版权、设计和专利保护法
227
228 通信法
229
230 纵上均为现行有效版本
231
232
233 应遵从合同条款中关于信息安全方面的条款;
234
235 应遵从公司的要求;
236
237 符合IS020000:2005标准的6.6条款的要求;
238
239 其他规定
240
241 其它方面的规定包括:
242
243 物理安全
244
245 对系统和数据的访问控制
246
247 安全教育和培训
248
249 员工行为准则
250
251 豆联网和邮件
252
253 数据备份
254
255 便携设备的使用
256
257 存储和处理机密数据
258
259 病毒防护和侦测
260
261 业务连续计划
262
263
264 ===== **参考** =====
265
266
267
268
269 ===== **批准** =====
270
271
272 技术总监 日期:
273
274
275
276
277 = **变更管理程序(#CP-0014)** =
278
279
280 ===== **1.目的** =====
281
282 定义职责和流程,管理变更请求的批准、实施、监控和测量。
283
284
285 ===== **2.范围** =====
286
287 本程序适用于所有公司使用的硬件和软件产品变更需求,这些在配置管理数据库中列出。这包括标准桌面软件,如微软XP标准版,微软Office2003, Symantec防病毒企业版9.0等等。
288
289
290 ===== **3.定义** =====
291
292 3.1 变更:任何在配置管理数据库中配置项的变化。
293
294 3.2 变更记录:一个授权的变更对于哪些配置项有影响,以及影响的程度的细节性记录。
295
296 3.3 配置项:被配置管理所控制的基础设施或者其条目的组件。
297
298 3.4 配置管理数据库(CMDB):包含每个配置项的相关细节和它们之间重要关系的细节的数据库。
299
300 3.5 变更请求:请求一个变更的过程需要使用在线表格(#CF-0013),以便记录对于服务或者基础设施的任何配置项的变更请求的细节。
301
302
303 ===== **4.职责** =====
304
305 4.1 变更经理负责对在公司CMDB列出的配置项(Cls)的所有变化。变更经理一定要在发布前批准所有的变更Cls,并确保每次Cls变更后更新CMDB。在公司内,变更经理默认是IT部门经理(IT部门经理或高层管理者可以根据情况指定其他人担任变更经理)。
306
307 4.2 变更请求者通过识别IT业务需求,启动变更流程。
308
309 4.3 变更指导委员会(CSC)负责响应、实施和监控变更请求。CSC成员被视为变更技术专家。
310
311
312 ===== **5.变更管理过程** =====
313
314 **5.1** 当业务相关的IT新需求被识别时,公司的员工必须填写在线变更请求表(#CF-0013)触发一个变更。通过变更管理工具软件自动把变更请求以E-mail方式发送给变更经理。
315
316 **5.2 **收到变更请求通知后,变更经理负责登录变更管理工具软件,评审所有递交的变更申请表(#CF-0013),然后变更经理必须:
317
318 5.2.1 把所有评审过的变更请求标注为“收到”。
319
320 5.2.2 把所有的不完全的变更请求标注为“由于不完全而拒绝”
321
322 5.2.3 指派CSC成员负责某个变更请求。
323
324 5.2.4 将变更分类为“紧急的”、“应急的”,“重大”或“轻微”。
325
326 5.2.5 转发所有的完整变更请求发送到CSC并标注为“审核中”。
327
328 **5.3 **CSC必须评审变更请求而且开始完成在线变更分析表格(#CF-0014),确定变更的范围。
329
330 **5.4 **CSC必须完成变更请求的风险分析,评估风险、冲击和业务收益。结果必须被记录在在线变更分析表(#CF-0014)。
331
332 **5.5** 如果风险可接受,CSC必须识剐变更实施后不满意的回退或补救方法,结果必须被记录在在线变更分析表(#CF-0014)。
333
334 **5.6** CSC必须制订正式实施计划一包括变更日期,以及在变更分析表(#CF-0014)记录变更结果。
335
336 **5.7 **完成以上步骤后,CSC必须把在线变更分析表(#CF-0014)标注为“等待批准”。
337
338 **5.8 **变更经理必须评审和批准在线变更分析表(#CF-0014),并与所有受影响(正面的或者负面的)部门的负责人沟通实施日期和步骤。
339
340 **5.9 **批准后,CSC可以所定义的范围内、在线变更分析表(#CF-0014)中约定之下,依照发布管理程序(#RM-0003)实施变更。
341
342 **5.10** 由于变更而导致的所有问题,必须记录于在线变更分析形表(#CF-0014)中。
343
344 **5.11 ** CSC负责联络所有受影响的团体,确定他们的满意度并把结果记录在线变更分析表(#CF-0014)中。
345
346 **5.12** 问题或客户抱怨必须记录于在线变更分析表(#CF-0014)中追踪,并由CSC来解决。基于问题或抱怨的种类,新的变更或纠正措施可能被CSC提出。
347
348 **5.13 **变更经理一定要在CMDB中记录所有执行的变更。
349
350
351 ===== **6.沟通和培训** =====
352
353 **6.1 ** 变更经理有责任确保IT部门的所有员工和所有部门领导们接受培训,了解他们在变更管理流程中的角色和职能。
354
355
356 ===== **7.0参考** =====
357
358 变更请求表(#CF-0013)
359
360 变更分析表(#CF-0014)
361
362 变更管理流程图(#FL-014)
363
364 变更管理流程图
365
366 === **[[image:file:///C:\Users\Admmini\AppData\Local\Temp\ksohtml10100\wps2.png]]** ===
367
368 ===== **8.0  批准** =====
369
370 技术总监 日期
371
372
373
374 === **配置管理程序(#CP一0017)** ===
375
376
377 ===== **1.  目的** =====
378
379 定义管理硬件、软件和相关文档的配置职责和过程。
380
381
382 ===== **2.  范围** =====
383
384 本程序适用于所有硬件、软件、相关文档和其它被公司使用的配置项(Cls)的配置管理,这些CI由IT部门依照服务级别协议(SLA)管控。员工个人购买使用的软件不在配置管理范围内,此外,不影响系统功能和完整性的内容或数据的变更也不在此范围中。
385
386
387 ===== **3.  定义** =====
388
389 3.1基线:指定时刻的服务或个别的配置项状态的快照。
390
391 3.2变更:对配置管理数据库内列出的配置的条目的改变。
392
393 3.3配置项(CI):被配置管理所控制的基础设施或者其条目的组件。
394
395 3.4配置管理数据库:包含每个配置项的相关细节和它们之间重要关系的细节的数据库。
396
397 3.5发布:新的配置项,和变更的配置项,在经过测试和引进实体环境的集合。
398
399
400 ===== **4. 责任** =====
401
402 4.1醌置经理负责评审和批准所有的正常情况下的基线配置并批准对CMDB的建议变更。在合适时,配置经理可以委派此责任给IT支持人员。
403
404 4.2不论是对IT硬件、软件或是文档所做的变更,变更经理或其代表负责此流程的符合性。
405
406
407 ===== **5. 配置管理策略** =====
408
409 5.1配置项包括被公司所使用的软件、硬件和文档,由IT部门按照所适用的服务级别协议管控。必须根据这个程序执行配置管理,确保受控,和有效的策划、实施、维护和改进IT系统。
410
411
412 ===== **6. 配置管理过程** =====
413
414 6.1当Cls发生改变,变更经理或其代表必须访问“http:~/~/Log_nphp”登录到CMDB(如果变更经理或其代表没有口令,必须联系配置经理要求口令)。
415
416 6.2登录后,变更经理或代表必须根据在线提示完成CMDB的变更,并按下“同意"按钮。
417
418 6.3配置经理必须登录CMDB,评审和批准所有提出的对CMDB的更新。如果提出的CMDB的更新可接受,配置经理必须选择“同意更新”按纽,正式接受对CMDB的变更。
419
420 6.4配置经理必须每月回顾CMDB,验证其准确性,在每月的lT部门会议介绍变更摘要。如果CMDB和实际检测到的配置项存在差异,必须触发纠正措施过程。
421
422 6.5配置经理负责更新CMDB,展示文档手册和硬件与软件之间的联系。
423
424 6.6当变更经理提出需求,配置经理必须提供信息,表明一个CI的变更对其它服务或基础设施配置的可能冲击。
425
426 6.7配置经理必须保证所有数字Cls的完整性,例如电子手册。配置经理必须对CMDB中的Cls在系统中分类,仅配置经理有该操作的读写权限。配置经理根据实际状况,决定谁对该操作和其中的数据Cls有读权限
427
428 6.8 IT服务支持人员负责执行和验证CMDB与其它公司的信息服务器的正常备份。
429
430
431 ===== **7. 沟通和培训** =====
432
433 7.1配置经理负责对IT部门的所有员工和所有部门领导进行培训,确保他们了解其在配置管理流程内角色和职能。
434
435
436 ===== **8.0参考** =====
437
438
439
440
441 ===== **9.0批准** =====
442
443
444 技术总监 日期:
445
446
447
448
449 = **问题管理程序(#CP-0019)** =
450
451
452 ===== **1.目的 ** =====
453
454 定义管理问题和帮助请求的责任与过程。
455
456
457 ===== **2.范围** =====
458
459 该程序覆盖所有问题和帮助请求,包括那些用户通报给IT部门的,或者由IT部门自行发现的。
460
461
462 ===== **3.定义** =====
463
464 3.1变更:任何对配置管埋数据库所列配置项的更改。
465
466 3.2严重问题:完全失去正常操作任何重大业务功能的能力。(例如:服务器或者网络硬件的故障)
467
468 3.3配置项(CI):被配置管理所控制的基础设施或者其条目的组件。
469
470 3.4配置管理数据库:包含每个配置项的相关细节和它们之问重要关系的细节的数据库。
471
472 3.5高风险问题:一个严重限制应用程序、系统或一个设备的使用的问题,显著影响业务功能(如,备份服务器问题。)
473
474 3.6突发事件:任何不属于服务标准操作部分的事件,造成或可能造成服务质量的中断或降低。
475
476 3.7问题:造成一个或多个突发事件的未知原因。
477
478 3.8常规问题:只影响一个人,而且并不会影响个人执行重要业务操作能力的问题。
479
480 3.9发布:新的配置项,和变更的配置项,在经过测试和引进实体环境的集合。
481
482
483 ===== **4.0责任** =====
484
485 4.1 IT经理负责保证所有的问题都被及时和有效地解决
486
487
488 ===== **5.0问题管理程序** =====
489
490 **5.1 **发现配置项(CI)问题的人,必须在问题管理数据库(PMD)中明确地描述问题,PMD可以通过“http:~/~/Login.php."访问。
491
492 **5.2** IT经理必须每天检查PMD,在PMD中对登录在案的问题划分优先级。问题被划分为“常规”,“高风险”或“严重”。
493
494 5.2.1严重问题必须立即处理。
495
496 5.2.2高风险问题在严重问题解决后处理。
497
498 5.2.3常规问题可以在时间允许的情况下解决。
499
500 **5.3 ** IT经理必须分配问题给IT服务人员,要求分析根本原因并提供解决方案。
501
502 **5.4**  IT服务人员必须立即采取措施,控制问题并最小化问题带来的进一步冲击。
503
504 **5.5 **基于根本原因分析,IT服务人员可以根据变更管理程序(#CP-0014),提出变更请求。变更请求必须包括所需要的,可能减少潜在问题的所有预防措施。
505
506 **5.6** IT服务人员须监控,并在PMD中记录变更请求的进展。变更完成后,IT服务人员必须监控问题解决的有效性,在PMD中记录其发现,从PMD中提交最终的问题管理报告给l丁经理。
507
508 **5.7** 由PMD生成的问题管理报告,将在每月的IT部门会议中被检查。基于问题管理报告的结果分析的改进机会必须在会议中讨论。会议议程项目的输出作为服务改进计划的输入。
509
510
511 ===== **6.0 沟通和培训** =====
512
513 6.1 IT经理负责对IT部门的所有员工和所有部门领导进行培训,确保他们了解其在问题管理流程内角色和职能。
514
515
516 ===== **7.0 参考** =====
517
518 变更管理程序(#CP-0014)
519
520
521 ===== **8.0 批准** =====
522
523 技术总监 日期:
524
525
深圳市艾拓先锋企业管理咨询有限公司