Show last authors
author | version | line-number | content |
---|---|---|---|
1 | = **容量管理程序** = | ||
2 | |||
3 | |||
4 | |||
5 | === **1 简介** === | ||
6 | |||
7 | |||
8 | ===== **1.1 目的** ===== | ||
9 | |||
10 | 负责确保 IT 处理、存储和网络以最经济和及时的方式与发展中的业务需求相匹配。 | ||
11 | |||
12 | |||
13 | |||
14 | ===== **1.2 适用范围** ===== | ||
15 | |||
16 | 适用于公司通过对IT服务容量的规划、改进和管理,提供满足容量需求的IT服务活动。 | ||
17 | |||
18 | |||
19 | |||
20 | ===== **1.3 术语表** ===== | ||
21 | |||
22 | |||
23 | [[image:file:///C:\Users\Admmini\AppData\Local\Temp\ksohtml21516\wps7.png]] | ||
24 | |||
25 | 容量:按需要的服务级别和成本交付一致同意的性能所需的一种本领。 | ||
26 | |||
27 | |||
28 | 容量管理:负责确保 IT 处理、存储和网络以最经济和及时的方式与发展中的业务需求相匹配。 | ||
29 | |||
30 | |||
31 | |||
32 | 容量数据库:用于存储容量管理流程中所采集的业务容量数据、服务容量数据、技术容量数据、财务数据的数据库,用以进行趋势分析、预测及规划。 | ||
33 | |||
34 | |||
35 | |||
36 | ===== **1.4 引用文件** ===== | ||
37 | |||
38 | 1. 《ISO/IEC 20000》 | ||
39 | 1. 《IT服务管理手册》 | ||
40 | |||
41 | |||
42 | |||
43 | === **2 职责** === | ||
44 | |||
45 | |||
46 | ===== **2.1 项目组** ===== | ||
47 | |||
48 | **2.1.1** 负责组织完成服务规划,参与容量计划的评审和改进。 | ||
49 | |||
50 | **2.1.2 **负责组织拟制容量管理计划,维护容量数据库,并组织服务容量的实施和评估。 | ||
51 | |||
52 | **2.1.3 **负责执行、监控生产系统的运作,采集容量数据,参与容量计划的评审和改进。 | ||
53 | |||
54 | |||
55 | |||
56 | === **3 流程图** === | ||
57 | |||
58 | |||
59 | [[image:微信图片_20240529104729.png]] | ||
60 | |||
61 | [[image:file:///C:\Users\Admmini\AppData\Local\Temp\ksohtml21516\wps10.png]] | ||
62 | |||
63 | |||
64 | === **4 具体内容** === | ||
65 | |||
66 | |||
67 | ===== **4.1 收集容量需求** ===== | ||
68 | |||
69 | **4.1.1 **项目组对容量信息进行收集、分类、整理。容量需求主要有: | ||
70 | |||
71 | 4.1.1.1 国家的法律、法规及上级主管部门对公司业务的要求。 | ||
72 | |||
73 | 4.1.1.2 与客户签署的服务级别协议。 | ||
74 | |||
75 | 4.1.1.3 事件、问题处理记录。 | ||
76 | |||
77 | 4.1.4.4 管理评审结果。 | ||
78 | |||
79 | 4.1.4.5 可用性和IT持续性分析。 | ||
80 | |||
81 | 4.1.4.6 服务成本的要求。 | ||
82 | |||
83 | |||
84 | ===== **4.2 容量分析及容量管理计划的制订** ===== | ||
85 | |||
86 | **4.2.1 **根据客户的要求,项目组与客户共同分析、讨论当前的业务需求、预测未来的增长,及对容量水平的规划要求,项目组分析当前容量并编制《项目策划书》中的〈容量分析〉,项目组依据容量分析结果编制《项目策划书》中的〈容量管理计划〉部分,主要包含: | ||
87 | |||
88 | 4.2.1.1 范围、目标、策略、角色和责任。 | ||
89 | |||
90 | 4.2.1.2 当前的容量绩效和预计的容量需求。 | ||
91 | |||
92 | 4.2.1.3 针对服务升级所定义的时间表,阀值和成本。 | ||
93 | |||
94 | 4.2.1.4 针对预期的服务升级、变更请求、容量方面新技术和新方法的评估。 | ||
95 | |||
96 | 4.2.1.5 预计外部变更的影响(如:法律、政策、标准等)。 | ||
97 | |||
98 | 4.2.1.6 能够执行预测性分析的数据和流程。 | ||
99 | |||
100 | 4.2.1.7 针对监控服务容量、调整服务性能和提供充分容量的方法、流程和技术。 | ||
101 | |||
102 | 4.2.1.8 为达到服务级别协议所要求的服务级别目标、可用性目标、连续性目标和业务需求所应具备的财务条件。 | ||
103 | |||
104 | 4.2.1.9 容量管理报告的频次和方式。 | ||
105 | |||
106 | 4.2.1.10 更新容量计划的条件。 | ||
107 | |||
108 | |||
109 | ===== **4.3 容量管理计划的实施与监控** ===== | ||
110 | |||
111 | **4.3.1 **项目组负责容量管理计划的实施。 | ||
112 | |||
113 | **4.3.2 **项目组应对当前容量运行数据定期进行采集和监控,汇总。项目组负责拟制《巡检记录》,并应明确:具体的收集内容、收集时间、收集人。 | ||
114 | |||
115 | |||
116 | ===== **4.4 容量趋势分析** ===== | ||
117 | |||
118 | **4.4.1** 对所收集到的容量数据进行分析,项目组应使用趋势分析、基线评价等技术,对IT基础架构的容量需求、IT服务需求及技术方面的最新进展进行分析,并考虑在未来服务级别需求的情况下可变更的配置项,制订《服务月报》。 | ||
119 | |||
120 | **4.4.2 **预测容量状况,分析容量趋势,判断能否满足现有需求,并指出将来可能会产生的问题点。 | ||
121 | |||
122 | **4.4.3 **当出现数据异常或波动,超过了标准的阀值时,项目组应及时收集例外信息,提交至问题管理程序。 | ||
123 | |||
124 | **4.4.4** 如果超过阈值,并且当前的容量水平无法满足容量需求时,则项目组应提出容量变更申请,提交至变更管理程序,通过变更流程改变现有容量。 | ||
125 | |||
126 | **4.4.5** 项目组应对容量状况进行持续的跟踪,对容量现状和使用需求保持时刻了解和掌握。 | ||
127 | |||
128 | **4.4.6** 根据对监控数据的分析,应用:趋势分析、基线评价等技术,对IT基础架构的容量需求、IT服务需求进行分析。 | ||
129 | |||
130 | |||
131 | ===== **4.5 定期容量管理** ===== | ||
132 | |||
133 | **4.5.1** 项目组根据容量管理的要求,每年对满足客户约定的、当前和未来的容量进行一次分析和评估,并在《项目总结》中编制〈容量报告〉的内容。容量报告的内容作为在下一年度有足够的容量能够保证合同约定范围内的服务质量,并兼顾到客户未来的业务需求。 | ||
134 | |||
135 | === === | ||
136 | |||
137 | === === | ||
138 | |||
139 | === **5 输出的文件和记录** === | ||
140 | |||
141 | |**文件和记录**|**文件属性**|**完成的部门/职位**|**备注** | ||
142 | |《项目策划书》|D|项目组| | ||
143 | |《UNIX小型机巡检报告》|D|项目组| | ||
144 | |《网络巡检报告》|D|项目组| | ||
145 | |《服务月报》|D|服务部| | ||
146 | |《项目总结》|D|项目组| | ||
147 | |||
148 | |||
149 | = = |