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/%E4%BD%93%E7%B3%BB%E6%96%87%E4%BB%B6/]] 阅读下一篇 | ||
| 2 | |||
| 3 | = = | ||
| 4 | |||
| 5 | = **问题关系管理程序** = | ||
| 6 | |||
| 7 | |||
| 8 | === | ||
| 9 | **1 简介** === | ||
| 10 | |||
| 11 | |||
| 12 | ===== **1.1 目的** ===== | ||
| 13 | |||
| 14 | 主动识别、处置对IT服务造成影响的因素或潜在原因,以减少对IT服务运营的影响。 | ||
| 15 | |||
| 16 | |||
| 17 | ===== ===== | ||
| 18 | |||
| 19 | ===== **1.2 适用范围** ===== | ||
| 20 | |||
| 21 | 适用于公司通过对问题原因的识别、分析及管理,最小化对业务影响的服务管理活动。 | ||
| 22 | |||
| 23 | |||
| 24 | ===== ===== | ||
| 25 | |||
| 26 | ===== **1.3 术语表** ===== | ||
| 27 | |||
| 28 | |||
| 29 | |||
| 30 | 问题: | ||
| 31 | |||
| 32 | 引发一个或多个事件的未知因素。 | ||
| 33 | |||
| 34 | 问题通常具有如下特征: | ||
| 35 | |||
| 36 | * 一组具有一定关系的已结束的事件 | ||
| 37 | * 一个重大事件 | ||
| 38 | |||
| 39 | 问题的根本原因找出后即成为已知错误;许多事件往往是有一个问题引起的。 | ||
| 40 | |||
| 41 | 问题管理流程的输出有: | ||
| 42 | |||
| 43 | * 变更请求 | ||
| 44 | * 变通方法 | ||
| 45 | * 预防性措施 | ||
| 46 | |||
| 47 | |||
| 48 | 已知错误: | ||
| 49 | |||
| 50 | [[image:file:///C:\Users\Admmini\AppData\Local\Temp\ksohtml18460\wps3.png]]查明事件原因并且已有临时、应急处理措施的问题。 | ||
| 51 | |||
| 52 | |||
| 53 | [[image:file:///C:\Users\Admmini\AppData\Local\Temp\ksohtml18460\wps4.png]] | ||
| 54 | |||
| 55 | 主动问题管理: | ||
| 56 | |||
| 57 | * 通过改进基础设施以及提出变更请求来阻止可避免事件的发生。 | ||
| 58 | * 通过找出基础设施中的薄弱环节来阻止事件的再次发生,以及提出消除这些薄弱环节的建议。 | ||
| 59 | * 分析基础设施的运行趋势并找出那些潜在事件以防止其发生。 | ||
| 60 | |||
| 61 | |||
| 62 | |||
| 63 | ===== **1.4 问题分类** ===== | ||
| 64 | |||
| 65 | 由于用户提供信息的不完整,可能导致开始的分级/分类与最终的分级/分类有很大的差别。 | ||
| 66 | |||
| 67 | |||
| 68 | |||
| 69 | |||
| 70 | ====== **1.4.1 分类** ====== | ||
| 71 | |||
| 72 | 问题的分类,原则上与事件的分类相一致。 | ||
| 73 | |||
| 74 | |编号|一级分类|二级分类|描述 | ||
| 75 | |(% rowspan="8" %)1|(% rowspan="8" %)合同服务|视讯系统|包括视频会议、视频监控系统线路及外围设备 | ||
| 76 | |网络| | ||
| 77 | |PC终端| | ||
| 78 | |PC服务器| | ||
| 79 | |小型机| | ||
| 80 | |存储系统| | ||
| 81 | |应用软件|公司自主开发软件或由公司提供服务的第三方软件 | ||
| 82 | |基础设施|电源、空调、门禁、KVM | ||
| 83 | |(% rowspan="9" %)2|(% rowspan="9" %)工程售后|视讯系统| | ||
| 84 | |全球眼| | ||
| 85 | |网络| | ||
| 86 | |PC终端| | ||
| 87 | |PC服务器| | ||
| 88 | |小型机| | ||
| 89 | |存储系统| | ||
| 90 | |应用软件| | ||
| 91 | |基础设施| | ||
| 92 | |(% rowspan="4" %)3|(% rowspan="4" %)公司资产维护|硬件送修| | ||
| 93 | |PC机| | ||
| 94 | |网络| | ||
| 95 | |前端应用系统|公司协同办公、MIS系统服务 | ||
| 96 | |4|业务咨询| | | ||
| 97 | |5|单次收费服务| | | ||
| 98 | |||
| 99 | |||
| 100 | |||
| 101 | |||
| 102 | ====== **1.4.2 分级** ====== | ||
| 103 | |||
| 104 | 给问题分配优先级,以保证支持组对问题必要的重视。分级应基于是问题的紧急程度和影响面。 | ||
| 105 | |||
| 106 | 问题的严重程度定义如下。问题的分级,原则上与事件的分级相一致。 | ||
| 107 | |||
| 108 | |(% rowspan="2" %)事件级别|(% colspan="3" %)级别定义 | ||
| 109 | |影响业务范围|影响业务程度|业务修复紧急程度 | ||
| 110 | |一级事件|客户业务中断,无法工作|80%以上客户业务受影响|非常紧急 | ||
| 111 | |二级事件|客户业务性能严重下降|50%以上客户业务受影响|紧急 | ||
| 112 | |三级事件|客户业务性能下降|20%以上客户业务受影响|普通 | ||
| 113 | |四级事件|问题请求,业务性能无下降|客户业务可能有潜在影响|与客户协商确定 | ||
| 114 | |||
| 115 | |||
| 116 | |||
| 117 | ===== **1.5 问题状态分类** ===== | ||
| 118 | |||
| 119 | 为方便问题状态的跟踪和查询,对问题状态定义如下。 | ||
| 120 | |||
| 121 | |编号|状态|描述 | ||
| 122 | |1|已登记|问题已进行登记 | ||
| 123 | |2|处理中|问题正在处理过程中 | ||
| 124 | |3|拒绝|问题分派被拒绝 | ||
| 125 | |4|已知错误|问题根本原因已找出 | ||
| 126 | |5|RFC|已提交变更请求(RFC) | ||
| 127 | |6|结束|问题已结束 | ||
| 128 | |7|没有解决|问题没有解决 | ||
| 129 | |||
| 130 | |||
| 131 | |||
| 132 | ===== **1.6 引用文件** ===== | ||
| 133 | |||
| 134 | 1. 《ISO/IEC 20000》 | ||
| 135 | 1. 《IT服务管理手册》 | ||
| 136 | |||
| 137 | |||
| 138 | === | ||
| 139 | **2 职责** === | ||
| 140 | |||
| 141 | |||
| 142 | ===== **2.1 技术组组长** ===== | ||
| 143 | |||
| 144 | 2.1.1 根据服务台提供的信息找出问题,与专项工程师一起探讨发现IT系统基础平台中存在的技术问题。 | ||
| 145 | |||
| 146 | 2.1.2 确定并协调必要资源来处理所有(潜在)影响服务级别的所有类型问题,最小化问题的负面影响。 | ||
| 147 | |||
| 148 | 2.1.3 领导专项技术小组,制定清晰有效的工作流程和准则,确保员工的积极性、技能水平和绩效表现。 | ||
| 149 | |||
| 150 | 2.1.4 发现造成问题的可能原因,将问题分派给有能力将其解决的IT职能部门。 | ||
| 151 | |||
| 152 | 2.1.5 跟踪问题解决的过程,必要时进行升级以及问题升级后的协调工作。 | ||
| 153 | |||
| 154 | 2.1.6 将关键问题的解决状态及时地通报给事业部管理层。 | ||
| 155 | |||
| 156 | 2.1.7 提出变更请求来消除事件和问题的根本原因。 | ||
| 157 | |||
| 158 | 2.1.8 确保使事件发生时把它的影响降到最小,同时确保根除事件的根本原因从而防止事件的再次发生。 | ||
| 159 | |||
| 160 | 2.1.9 与内部和外部支持部门就问题的解决方案和防范进行讨论,并确保与他们的良好关系。 | ||
| 161 | |||
| 162 | 2.1.10 通过对历史和现有环境的有效分析以确保IT服务的主动性。 | ||
| 163 | |||
| 164 | 2.1.11 提供关于IT服务和客户支持的正确有效的管理信息, 生成有效的管理报表。 | ||
| 165 | |||
| 166 | 2.1.12确保所有相关人员都足够程度地引入到问题管理的流程中。 | ||
| 167 | |||
| 168 | |||
| 169 | ===== **2.2 专项技术工程师** ===== | ||
| 170 | |||
| 171 | 2.2.1 通过在某一方面的专业知识和技能(网络或应用)来支持事件管理的一线工程师和技术组组长,确保事件的快速解决和IT服务的快速恢复。 | ||
| 172 | |||
| 173 | 2.2.2 接受来自问题管理经理分派的问题。 | ||
| 174 | |||
| 175 | 2.2.3 基于影响度/优先级和分类代码执行问题分析,在规定的时间范围内调查可能的事件根本原因,测试解决方案,同时确保问题得以解决。 | ||
| 176 | |||
| 177 | 2.2.4 在需要时请其它技术专家介入,以确保问题得以及时解决。 | ||
| 178 | |||
| 179 | 2.2.5 协调变更管理功能,实施解决方案.。 | ||
| 180 | |||
| 181 | 2.2.6 不但使事件发生时把它的影响降到最小,也使用根除事件的根本原因从而防止事件的再次发生。 | ||
| 182 | |||
| 183 | 2.2.7 利用现有IT环境分析历史数据来改善IT系统和工作方法从而避免潜在问题的发生。 | ||
| 184 | |||
| 185 | 2.2.8 在必要时修正事件或问题的影响度和分类编码。 | ||
| 186 | |||
| 187 | 2.2.9 在需要时与外部供应商作接口。 | ||
| 188 | |||
| 189 | 2.2.10 参与升级流程。 | ||
| 190 | |||
| 191 | 2.2.11 在服务中断时,尽快提供临时解决方案,帮助客户尽快恢复正常工作状态。 | ||
| 192 | |||
| 193 | 2.2.12 提供问题的正确状态、进展和历史信息。 | ||
| 194 | |||
| 195 | \\ | ||
| 196 | |||
| 197 | === **3 流程图** === | ||
| 198 | |||
| 199 | |||
| 200 | **[[image:微信图片_20240529134111.png]]** | ||
| 201 | |||
| 202 | [[image:file:///C:\Users\Admmini\AppData\Local\Temp\ksohtml18460\wps5.png]] | ||
| 203 | |||
| 204 | |||
| 205 | === | ||
| 206 | **4 具体内容** === | ||
| 207 | |||
| 208 | |||
| 209 | ===== **4.1 问题来源** ===== | ||
| 210 | |||
| 211 | **4.1.1 ** 服务部负责在生产系统日常维护过程中问题的记录和监控,问题的来源主要有: | ||
| 212 | |||
| 213 | 4.1.1.1 事件没有得到解决,需要升级为问题进行进一步分析处理时,应创建问题。 | ||
| 214 | |||
| 215 | 4.1.1.2 事件虽然得到解决,但可能存在未知错误时,应创建问题。 | ||
| 216 | |||
| 217 | 4.1.1.3 重大事件,无论是否得到解决,为防止再次出现,应创建问题。 | ||
| 218 | |||
| 219 | 4.1.1.4 在事件分析报告中提出的存在趋势或潜在隐患的可能问题,例如事件类型或数量的趋势分析存在问题。 | ||
| 220 | |||
| 221 | 4.1.1.5 对基础设施和服务的主动性问题检查。 | ||
| 222 | |||
| 223 | 4.1.1.6 供应商提供的已知产品缺陷、已知错误。 | ||
| 224 | |||
| 225 | **4.1.2 ** 与信息安全有关的安全事件或安全风险也应作为问题来管理。 | ||
| 226 | |||
| 227 | |||
| 228 | ===== **4.2 问题的接收记录和分类** ===== | ||
| 229 | |||
| 230 | **4.2.1** 对出现的问题,项目经理负责收集、识别,并填写《问题记录表》。其中应包括: | ||
| 231 | |||
| 232 | 4.2.1.1 问题编号。 | ||
| 233 | |||
| 234 | 4.2.1.2 记录日期和时间。 | ||
| 235 | |||
| 236 | 4.2.1.3 记录人。 | ||
| 237 | |||
| 238 | 4.2.1.4 问题来源。 | ||
| 239 | |||
| 240 | 4.2.1.5 问题类别。 | ||
| 241 | |||
| 242 | 4.2.1.6 症状描述和任何错误代码。 | ||
| 243 | |||
| 244 | 4.2.1.7 已经产生的影响或可能导致的影响等级。 | ||
| 245 | |||
| 246 | 4.2.1.8 问题处理进程的状态。 | ||
| 247 | |||
| 248 | **4.2.2** 问题的分级/分类 | ||
| 249 | |||
| 250 | 4.2.2.1 在接受和记录问题之后,服务台首先根据1.4的问题分级分类准则,对受理的问题进行分级和分类以方便后续的监视和报告。 | ||
| 251 | |||
| 252 | 4.2.2.2 在问题进行分级/分类后,项目经理将问题转给相应的专项工程师。 | ||
| 253 | |||
| 254 | |||
| 255 | ===== **4.3 问题调查和诊断** ===== | ||
| 256 | |||
| 257 | |||
| 258 | **4.3.1** 专项技术工程师根据判断发现问题应该由其他组分析解决,将《问题处理报告》发回技术经理,注明拒绝理由并推荐组名。 | ||
| 259 | |||
| 260 | 4.3.1.1 如果问题确应由本人或本小组解决接受分派的问题,在调查诊断问题后,如有必要成立问题分析小组,举行问题根本原因分析研讨会议并确定问题的潜在原因。必要时更新问题状态。 | ||
| 261 | |||
| 262 | 4.3.1.2 如找到根本原因的得以确定,将问题转化为已知错误。 | ||
| 263 | |||
| 264 | |||
| 265 | ===== **4.4 变更请求(RFC)及临时措施** ===== | ||
| 266 | |||
| 267 | **4.4.1 **专项技术工程师找出问题的根本原因后,根据实际情况制定变通方法或根本性解决方案,并确保这些方法或方案将降低或消除问题的发生率或影响度,更新问题记录。 | ||
| 268 | |||
| 269 | **4.4.2** 技术组组长根据专项技术工程师提交的解决方案或变通方法决定是否需要进行变更,进入问题关闭,否则提交变更申请。 | ||
| 270 | |||
| 271 | |||
| 272 | ===== **4.5 问题关闭** ===== | ||
| 273 | |||
| 274 | **4.5.1 **变更结束后(如果有变更),确认问题已经解决,根据是否需要问题回顾选择相应的结束状态,更新问题状态,关闭问题记录。负责处理问题的工程师向项目经理提交《问题处理报告》。 | ||
| 275 | |||
| 276 | **4.5.2** 对于重大问题,进行问题回顾,找出可能改进的机会,包括问题的解决方案和管理流程方面,如改进升级规则、改进事件监测、找出技能差距和文档资料改进等。负责处理问题的工程师向项目经理提交《问题处理报告》。 | ||
| 277 | |||
| 278 | |||
| 279 | ===== **4.6 问题的评价和监控** ===== | ||
| 280 | |||
| 281 | **4.6.1 **项目经理在问题解决后,负责监控、评价和反馈问题解决的绩效,在《问题处理报告》单上填写问题跟踪表记录。如仍存在问题,应重新填写《问题处理报告》,按原流程提交处理;如问题已解决,应及时检查原《问题处理报告》相关内容完整性,关闭问题。 | ||
| 282 | |||
| 283 | **4.6.2** 对暂时无解决方案的问题,项目经理负责组织对问题发展趋势的跟踪和监控,及时了解问题的影响及风险,视对SLA的影响情况组织对问题重新分析,并按原处理流程执行。 | ||
| 284 | |||
| 285 | **4.6.3** 问题在得到解决后,专项工程师应及时更新问题知识库;对涉及配置项的变更,专项工程师应在问题解决后及时更新;对涉及质量标准的变更,项目经理组织更新有关的质量标准和流程文件。 | ||
| 286 | |||
| 287 | |||
| 288 | ==== **4.7 分析和评估报告** ==== | ||
| 289 | |||
| 290 | **4.7.1** 服务部负责监控生产系统日常的运营,拟制《服务月报》,并将报告提交事业部总监审批。其中与问题相关的内容应包括: | ||
| 291 | |||
| 292 | 4.7.1.1 问题分类、数量及性质。 | ||
| 293 | |||
| 294 | 4.7.1.2 对业务的影响。 | ||
| 295 | |||
| 296 | 4.7.1.3 解决成本。 | ||
| 297 | |||
| 298 | 4.7.1.4 重大问题分析。 | ||
| 299 | |||
| 300 | 4.7.1.5 改进措施。 | ||
| 301 | |||
| 302 | === | ||
| 303 | **5 输出的文件和记录** === | ||
| 304 | |||
| 305 | |**文件和记录**|**文件属性**|**完成的部门/职位** | ||
| 306 | |《问题处理报告》|D|专项工程师 | ||
| 307 | |《问题记录表》|D|项目经理 | ||
| 308 | |《服务月报》|D|服务部 | ||
| 309 | |||
| 310 | |||
| 311 | |||
| 312 | == **附录** == | ||
| 313 | |||
| 314 | == 附录A-文件流转表 == | ||
| 315 | |||
| 316 | |**文件名称**|**文件编号**|**拟制**|**审核**|**批准**|**收文人员** | ||
| 317 | |《问题处理报告》| |技术组|事业部总监|/| | ||
| 318 | |《问题记录表》| |项目组|二级部门经理|/| | ||
| 319 | |《服务月报》| |服务部|事业部总监|/| | ||
| 320 | |||
| 321 |