文档更改服务管理实践 - 02 事件
由 superadmin 于 2024/12/25, 15:38 最后修改
修改评论
Update document after refactoring.
Summary
Details
- Page properties
-
- 标题
-
... ... @@ -1,1 +1,1 @@ 1 - ITIL4事件管理实践中文版1 +02 事件管理实践 - 父
-
... ... @@ -1,1 +1,1 @@ 1 - Main.WebHome1 +00 服务管理实践.WebHome - Content
-
... ... @@ -1,8 +1,9 @@ 1 +如有[[ITIL认证>>url:http://www.itilchina.cn/achotsao/vip_doc/13354653.html]]、[[ITIL培训>>url:http://www.itilchina.cn/achotsao/vip_doc/13354653.html]]或[[ITIL考试>>url:http://www.itilchina.cn/achotsao/vip_doc/13354653.html]]需求,可[[点击了解详情>>url:http://www.itilchina.cn/achotsao/vip_doc/13354653.html]] 2 + 3 + 1 1 **申明:** 2 2 3 -本系列ITIL 4实践中文版本由ITIL先锋论坛专家委员会组织翻译,国内众 4 -多从事ITIL理论推广及落地实践的专家们参与,需要下载最新翻译版本请关注微信 5 -公众号:ITILXF,也可访问ITIL4中文知识库网站:itil4hub.cn。 6 +本系列ITIL 4中文版本由长河领导的ITIL先锋论坛专家委员会组织翻译,国内众多从事ITIL理论推广及落地实践的专家们参与。需要下载最新翻译版本请关注微信公众号:**ITILXF**,并回复“**事件管理**”或“**事件**”即可。 6 6 7 7 8 8 请注意,ITIL先锋论坛专家团队仅仅只是进行了这些著作的语种转换工作,我们并不拥有包括原著以及中文发行文件的任何版权,所有版权均为Axoles持有,读者在使用这些文件(含本中文翻译版本)时需完全遵守Axoles 和 TSO所申明的所有版权要求。 ... ... @@ -25,6 +25,10 @@ 25 25 26 26 ---- 27 27 29 +{{box cssClass="floatinginfobox" title="**Contents**"}} 30 +{{toc/}} 31 +{{/box}} 32 + 28 28 = **1 关于本文件** = 29 29 30 30 本文档提供事件管理实践实用指南。分为五个主要部分,内容包括: ... ... @@ -35,11 +35,8 @@ 35 35 * 支持实践的信息和技术 36 36 * 对实践的合作伙伴和供应商的考虑。 37 37 38 - 39 39 == **1.1 ITIL®4 认证方案** == 40 40 41 - [[image:file:///C:\Users\19805\AppData\Local\Temp\ksohtml\wps87EB.tmp.png]] 42 - 43 43 本文档的部分内容可以作为以下教学大纲的一部分以供检查: 44 44 45 45 * ITIL专家:创建、交付和支持 ... ... @@ -55,7 +55,7 @@ 55 55 = **2 一般信息** = 56 56 57 57 58 -== 2.1 **目的和描述** == 60 +== **2.1** **目的和描述** == 59 59 60 60 |((( 61 61 **关键信息** ... ... @@ -62,19 +62,16 @@ 62 62 ))) 63 63 |事件管理实践的目的是尽快恢复正常的服务运作,以尽量减少事件的负面影响。 64 64 65 - 66 66 规范的服务运维通常是在服务级别协议(SLA)定义,或在服务质量规范的其他形式中定义的,因为这可以是服务提供者在内部达成的协议。规范可以包含比最初与客户达成的协议更多的质量准则。因此,事件管理实践包括恢复服务和资源的正常运行,即使服务使用者看不到它们的失效或偏差。在这种情况下,日常运维操作在配置项(CI)或服务技术规范中定义。但是,如果没有日常运维的书面规范,则可以使用专家意见来评估资源和服务的状况。如果需要,可以使用事件管理实践来纠正有故障的资源或服务。 67 67 68 68 事件管理实践是服务管理的基本元素。服务的快速恢复是用户和客户满意、服务提供者的信誉,以及组织在服务关系中创建价值的关键因素。 69 69 70 70 72 +== **2.2** **术语和概念** == 71 71 72 -== 2.2 **术语和概念** == 73 - 74 74 |**事件** 75 75 |服务的计划外中断或服务质量的降低。 76 76 77 - 78 78 事件管理实践确保将计划外的服务不可用或降级的时间减至最少,从而减少对用户的负面影响。有两个主要因素可以实现这一点:早期的事件检测和快速恢复正常的运维。 79 79 80 80 借助有效、高效的流程,自动化工具和供应商关系以及技术精湛且积极进取的专家团队,可以快速检测和解决事件。服务管理四维模型的资源被整合以形成事件管理实践。 ... ... @@ -86,12 +86,12 @@ 86 86 87 87 尽管有些事件在服务运营和消费方面的影响相对较低,但其他事件却给服务消费者和服务提供者带来了严重后果,这些被称为重大事件,需要特别注意。 88 88 88 + 89 89 |((( 90 -**定义:重大事件** 90 + **定义:重大事件** 91 91 ))) 92 92 |具有重要业务影响的事件,需要立即协调解决。 93 93 94 - 95 95 重要的业务影响并不是重大事件的唯一特征。例如,当有多个为高可用性设计的系统和服务时,单个故障不太可能导致严重的业务影响。故障将迅速且通常是自动检测并修复。重大事件通常与更高级别的复杂性相关。例如,如果多个看似微不足道的事件同时发生,则可能会升级并对服务使用者产生影响。诸如此类的复杂事件需要一些特殊的管理和解决方法。实施一个模型来管理所有事件将是有益的,尽管重大事件很少发生且通常具有不同的性质。重大事件的模型可能包括: 96 96 97 97 * 清晰的准则,以区分重大事件与灾难及其他事件 ... ... @@ -102,13 +102,11 @@ 102 102 * 与用户,客户,监管机构,媒体和其他利益相关者进行沟通的机制 103 103 * 达成一致的评审与后续活动的规程。 104 104 105 - 106 106 |((( 107 107 **定义:变通方案** 108 108 ))) 109 109 |当事件或者问题无法彻底解决,而采取减少或消除事件或问题影响的变通解决方案。一些变通方案还可以降低事件发生的可能性。 110 110 111 - 112 112 有时,可能找不到事件的系统性解决方案。在这些情况下,服务提供者可以应用变通方案。 113 113 114 114 变通方案可以立即将服务恢复到可接受的质量。但是,变通方案可能会增加技术债务,并可能在将来导致新的事件。问题管理实践可用于减少事件解决方法创建的技术债务。在许多情况下,了解事件的原因可以帮助找到最佳解决方案。 ... ... @@ -119,9 +119,8 @@ 119 119 ))) 120 120 |因选择变通方案而非系统性解决方案(需要花费更长时间),而累计的返工总量 121 121 119 +== **2.3 范围** == 122 122 123 -== 2.3 **范围** == 124 - 125 125 事件管理实践的范围包括: 126 126 127 127 * 发现和登记事件 ... ... @@ -136,11 +136,12 @@ 136 136 137 137 表2.1 其他实践中描述的与事件管理实践相关的活动 138 138 139 -|**活动**|**实践指南** 140 -|调查事件原因|问题管理 141 -|与用户沟通|服务台 142 -|实施产品和服务的变更|变更支持 143 -| |((( 135 +(% style="width:364px" %) 136 +|(% style="width:204px" %)**活动**|(% style="width:157px" %)**实践指南** 137 +|(% style="width:204px" %)调查事件原因|(% style="width:157px" %)问题管理 138 +|(% style="width:204px" %)与用户沟通|(% style="width:157px" %)服务台 139 +|(% style="width:204px" %)实施产品和服务的变更|(% style="width:157px" %)变更支持 140 +|(% style="width:204px" %) |(% style="width:157px" %)((( 144 144 部署管理 145 145 146 146 基础设施和平台管理 ... ... @@ -151,20 +151,18 @@ 151 151 152 152 软件开发和管理 153 153 ))) 154 -|监控技术,团队和供应商绩效|监控和事态管理 155 -|改进计划的管理|持续改进 156 -|服务请求的管理和执行|服务请求管理 157 -|灾难情况下,恢复正常操作|服务连续性管理 151 +|(% style="width:204px" %)监控技术,团队和供应商绩效|(% style="width:157px" %)监控和事态管理 152 +|(% style="width:204px" %)改进计划的管理|(% style="width:157px" %)持续改进 153 +|(% style="width:204px" %)服务请求的管理和执行|(% style="width:157px" %)服务请求管理 154 +|(% style="width:204px" %)灾难情况下,恢复正常操作|(% style="width:157px" %)服务连续性管理 158 158 156 +== **2.4** **实践成功因素** == 159 159 160 -== 2.4 **实践成功因素** == 161 - 162 162 |((( 163 163 **实践成功因素** 164 164 ))) 165 165 |相关联的一组事务的协同工作机制,是实践活动实现其目的所必需的。 166 166 167 - 168 168 实践的成功因素(PSF)不仅仅是一项任务或活动,它包括服务管理四维模型的所有功能组件。在一项实践中,PSFs活动和资源的性质可能不同,但这些资源和活动共同确保实践有效。 169 169 170 170 事件管理实践包括以下PSFs: ... ... @@ -173,7 +173,6 @@ 173 173 * 快速有效地解决事件 174 174 * 不断改进事件管理方法。 175 175 176 - 177 177 === **2.4.1 尽早发现事件** === 178 178 179 179 以前,实践通常是根据最终用户和IT专家的信息来报告大多数事件的。这种获取信息的方法仍被广泛使用,但是现在一个好的实践建议是自动发现和报告事件。可以在事件发生后和开始影响用户之前立即被发现。这种方法具有多种好处,其中包括: ... ... @@ -199,11 +199,9 @@ 199 199 * 在复杂的情况下,事件的确切性质未知,但支持团队熟悉系统和组件,并且组织可以获取专家知识,因此通常会将事件分派到一个或多个专家组进行诊断和解决。有时,这可以帮助识别模式,并产生一个模型和/或解决方案,可以应用于未来的类似事件。 200 200 * 在非常复杂的情况下,很难或不可能确定专家区域和专家组,或者已确定的专家组找不到解决方案时,采用集体方法可能会有用。此技术称为“全功能团队”。 201 201 202 - 203 203 |**全功能团队** 204 204 |解决各种复杂任务的技术方法。在全功能团队中,具有不同专业知识领域的多个人员一起完成一项任务,直到明确哪些能力最相关和最需要。 205 205 206 - 207 207 通常,全功能团队有助于降低复杂度,使其可以切换到低复杂性环境中使用的技术。但是,全功能团队通常适用于性质未知的重大事件。在这种情况下,与仍未解决的事件造成的损失相比,将大量专用资源集中在一起更具有成本效益。 208 208 209 209 全功能团队不需要举行实际会议。建立计划后,专家可能会独自工作以完成实验,设计脚本,并使用其他工具来发现正在发生的事情。为了应对这一事件,全功能团队使用正确的人员,而不是大量的人员。 ... ... @@ -220,7 +220,6 @@ 220 220 * 找到并纠正根本原因的能力 221 221 * 机器学习的可能性和质量。 222 222 223 - 224 224 ==== **2.4.2.1 事件的优先级** ==== 225 225 226 226 事件应尽快解决。但是,参与事件解决的团队的资源是有限的,并且这些团队通常同时参与其他类型的工作。应该优先处理某些事件,以最大程度地减少对用户的负面影响。 ... ... @@ -259,9 +259,8 @@ 259 259 全面描述采取行动的原因与描述行动本身同样重要。 260 260 ))) 261 261 253 +== **2.5 关键指标** == 262 262 263 -== 2.5 **关键指标** == 264 - 265 265 应该基于每个实践对价值流的贡献来评估ITIL实践的有效性和绩效。与任何工具的绩效一样,实践的绩效只能在其应用情境中评估。工具在设计和质量上可能会有很大差异,按照工具的用途使用时,这些差异定义了工具有效性的潜力或能力。关于度量标准,关键绩效指标(KPI)和其它技术的进一步指导,请参见度量和报告实践指南。 266 266 267 267 事件管理实践的关键指标已映射到其PSF。它们可以用作价值流情景下的KPIs,来评估实践对这些价值流的效能和效率的贡献。表2.2中给出了一些关键指标的例子。 ... ... @@ -271,13 +271,14 @@ 271 271 272 272 表2.2 实践成功因素的关键指标示例 273 273 274 -|**实践成功因素**|**指标示例** 275 -|尽早发现事件|((( 264 +(% style="width:458px" %) 265 +|(% style="width:182px" %)**实践成功因素**|(% style="width:273px" %)**指标示例** 266 +|(% style="width:182px" %)尽早发现事件|(% style="width:273px" %)((( 276 276 事件发生到发现之间的时间 277 277 278 278 通过监控和事态管理发现的事件百分比 279 279 ))) 280 -|快速有效地解决事件|((( 271 +|(% style="width:182px" %)快速有效地解决事件|(% style="width:273px" %)((( 281 281 从事件发现到接受诊断之间的时间 282 282 283 283 派单次数 ... ... @@ -294,7 +294,7 @@ 294 294 295 295 用户报告之前已解决的事件的百分比 296 296 ))) 297 -|不断改进事件管理方法|((( 288 +|(% style="width:182px" %)不断改进事件管理方法|(% style="width:273px" %)((( 298 298 使用先前确定和记录的解决方案的事件解决率 299 299 300 300 使用事件模型解决的事件的百分比 ... ... @@ -311,7 +311,7 @@ 311 311 = **3 价值流和流程** = 312 312 313 313 314 -== 3.1 **价值流贡献** == 305 +== **3.1** **价值流贡献** == 315 315 316 316 像任何其他ITIL管理实践一样,事件管理实践对多条价值流有帮助。重要的是要记住,价值流不是由单一实践形成的。例如,即使当价值流专注于事件解决时,也会涉及其他实践,例如服务台、监控和事态管理、服务配置管理、变更支持、供应商管理、基础设施和平台管理以及软件开发和管理。 317 317 ... ... @@ -323,7 +323,6 @@ 323 323 * 改进 324 324 * 获取或构建。 325 325 326 - 327 327 事件管理实践对服务价值链的贡献如图3.1所示。 328 328 329 329 (% style="text-align:center" %) ... ... @@ -332,7 +332,7 @@ 332 332 图3.1 事件管理实践对价值链活动的贡献热力图 333 333 334 334 335 -== 3.2**流程** ==325 +== **3.2 流程** == 336 336 337 337 每个实践可以包含一个或多个过程和活动,这是实现这一实践目的所必需的。 338 338 ... ... @@ -342,13 +342,11 @@ 342 342 ))) 343 343 |将输入转换为输出的一组相互关联或相互作用的活动。过程接受一个或多个已定义的输入,并将其转换为已定义的输出。过程定义操作的顺序及依赖关系。 344 344 345 - 346 346 事件管理活动分为两个流程: 347 347 348 348 * **事件的处理和解决**。该流程的重点是从发现到关闭的单个事件的处理和解决。 349 349 * **定期事件评审**。该流程确保从事件处理和解决的过程中吸取教训,并确保持续改进事件管理的方法。 350 350 351 - 352 352 === **3.2.1 事件处理和解决** === 353 353 354 354 该过程包括表3.1中列出的活动,并将输入转换为输出。 ... ... @@ -369,7 +369,6 @@ 369 369 |(% style="width:254px" %)问题记录|(% style="width:119px" %) |(% style="width:177px" %) 370 370 |(% style="width:254px" %)知识库|(% style="width:119px" %) |(% style="width:177px" %) 371 371 372 - 373 373 图3.2展示事件处理和解决的工作流程图。 374 374 375 375 ... ... @@ -386,45 +386,11 @@ 386 386 387 387 表3.2 事件处理和事件解决过程的活动 388 388 389 -|**活动**|**手动处理用户发现的事件**|**自动发现和处理事件** 390 -|事件发现|用户发现服务运营中的故障,并通过约定的渠道与服务提供者的服务台联系。服务台客服对该用户问询进行初始分类,确认该问询确实属于事件。|监控系统检测到事态,并基于预定义的分类将其标识为事件。 391 -|事件登记|服务台客服执行事件登记,将有效数据添加到事件记录中。|登记事件记录并将其与发现事态的CI关联。登记预定义的技术参数。必要时,给相关技术专家发送通知。 392 -|事件分类|((( 393 -服务台客服完成事件初始分类;这有助于确定事件的影响,确定为失效CI和/或服务确定责任团队,并将事件关联到其他过去和正在处理的事态,事件和/或问题。 376 +[[image:1642222461983-817.png]] 394 394 395 -在某些情况下,分类有助于找到以前为此类事件定义的解决方案。 396 -)))|((( 397 -根据预定义的规则,将自动发现: 378 +[[image:1642222484248-277.png]] 398 398 399 -* 事件对服务和用户的影响 400 -* 可用的解决方案 401 -* 如果自动化解决方案无效或不可用,找到负责事件解决的技术团队。 402 -))) 403 -|事件诊断|((( 404 -如果分类没有关联到已知解决方案, 405 405 406 -专家团队开展事件诊断。这可能涉及将事件升级到不同团队,或其他联合技术团队加入(如全功能团队)。 407 - 408 -如果由于配置项关联错误而导致分类错误,则应将此信息传达给负责配置管理的人员(请参阅服务配置实践指南)。 409 -)))|((( 410 -如果自动解决方案无效或不可用,则将事件上报给负责诊断的技术团队。可能涉及事件升级到不同团队,或其他技术团队加入(如全功能团队)。 411 - 412 -如果由于配置项关联错误而导致自动化解决方案失败,则应将此信息传达给负责配置管理的人员(请参阅服务配置实践指南)。 413 -))) 414 -|事件解决|找到解决方案后,相关专家团队将尝试按顺序或并行工作方式执行,这可能需要启动变更。如果解决方案不起作用,则再次诊断。|如果有可用的自动化解决方案,则实施它,并完成测试和确认。如果需要手动干预,则相关的专业团队尝试实施,这可能需要启动变更。如果解决方案不起作用,则再次诊断。 415 -|事件关闭|((( 416 -成功解决事件之后,可能需要一些正式的关闭过程: 417 - 418 -* 用户确认服务恢复 419 -* 计算解决方案成本并报告 420 -* 解决方案结算报价和发票 421 -* 问题调查启动 422 -* 事件评审 423 - 424 -完成所有必需的操作并更新了相应地事件记录后,事件正式关闭。这可以由产品负责人,服务负责人,事件经理或服务台客服完成,具体取决于商定的事件模型。 425 -)))|如果自动解决方案证明有效,则事件记录将自动更新并关闭。发送报告给负责的技术团队。如果在先前的任何步骤中已将有关事件的信息传达给其他利益相关者,则应向其传达事件关闭的信息。 426 - 427 - 428 428 === **3.2.2 定期事件评审** === 429 429 430 430 该流程的重点是持续改进事件管理实践,事件模型和事件处理程序。它可以定期执行,也可以由事件报告触发,该报告突显低效率和其他改进点机会。根据现有模型和程序的效果,每两到三个月或更短时间进行一次定期检查。 ... ... @@ -434,24 +434,23 @@ 434 434 435 435 表3.3定期事件评审的输入、输出和活动 436 436 437 -(% style="width: 738px" %)438 -|(% style="width: 297px" %)**关键输入**|(% style="width:233px" %)**活动**|(% style="width:207px" %)**关键输出**439 -|(% style="width: 297px" %)当前事件的模型和程序|(% style="width:233px" %)事件评审和事件记录分析|(% style="width:207px" %)更新的事件模型440 -|(% style="width: 297px" %)事件记录|(% style="width:233px" %)事件模型优化的启动|(% style="width:207px" %)更新的事件处理程序441 -|(% style="width: 297px" %)事件报告|(% style="width:233px" %) |(% style="width:207px" %)事件记录442 -|(% style="width: 297px" %)策略和法规要求|(% style="width:233px" %)事件模型更新的沟通|(% style="width:207px" %)更新的事件模型和过程的沟通443 -|(% style="width: 297px" %)配置信息|(% style="width:233px" %) |(% style="width:207px" %)444 -|(% style="width: 297px" %)IT资产信息|(% style="width:233px" %) |(% style="width:207px" %)变更请求445 -|(% style="width: 297px" %)与消费者和供应商/合作伙伴的SLA|(% style="width:233px" %) |(% style="width:207px" %)(((390 +(% style="width:406px" %) 391 +|(% style="width:139px" %)**关键输入**|(% style="width:146px" %)**活动**|(% style="width:117px" %)**关键输出** 392 +|(% style="width:139px" %)当前事件的模型和程序|(% style="width:146px" %)事件评审和事件记录分析|(% style="width:117px" %)更新的事件模型 393 +|(% style="width:139px" %)事件记录|(% style="width:146px" %)事件模型优化的启动|(% style="width:117px" %)更新的事件处理程序 394 +|(% style="width:139px" %)事件报告|(% style="width:146px" %) |(% style="width:117px" %)事件记录 395 +|(% style="width:139px" %)策略和法规要求|(% style="width:146px" %)事件模型更新的沟通|(% style="width:117px" %)更新的事件模型和过程的沟通 396 +|(% style="width:139px" %)配置信息|(% style="width:146px" %) |(% style="width:117px" %) 397 +|(% style="width:139px" %)IT资产信息|(% style="width:146px" %) |(% style="width:117px" %)变更请求 398 +|(% style="width:139px" %)与消费者和供应商/合作伙伴的SLA|(% style="width:146px" %) |(% style="width:117px" %)((( 446 446 改进计划 447 447 448 448 事件评审报告 449 449 ))) 450 -|(% style="width: 297px" %)容量和性能信息|(% style="width:233px" %) |(% style="width:207px" %)451 -|(% style="width: 297px" %)连续性策略和计划|(% style="width:233px" %) |(% style="width:207px" %)452 -|(% style="width: 297px" %)安全策略和计划|(% style="width:233px" %) |(% style="width:207px" %)403 +|(% style="width:139px" %)容量和性能信息|(% style="width:146px" %) |(% style="width:117px" %) 404 +|(% style="width:139px" %)连续性策略和计划|(% style="width:146px" %) |(% style="width:117px" %) 405 +|(% style="width:139px" %)安全策略和计划|(% style="width:146px" %) |(% style="width:117px" %) 453 453 454 - 455 455 图3.3 展示事件评审的工作流程图。 456 456 457 457 ... ... @@ -466,24 +466,22 @@ 466 466 467 467 表3.4 定期事件评审流程的活动 468 468 469 -|**活动**|**示例** 470 -|事件评审和事件记录分析|事件经理与服务所有者和其他相关的利益相关者一起,对选定的事件(例如重大事件,未及时解决的事件或特定时期内的所有事件)实施评审,确定事件模型和事件处理程序的改进机会,包括事件处理和解决方案的自动化。 471 -|事件模型优化的启动|事件经理记录优化方案,它将通过持续改进实践或启动变更请求开始。(如果事件模型、程序和自动化包含在变更支持实践的范围内)。 472 -|((( 421 +(% style="width:434px" %) 422 +|(% style="width:106px" %)**活动**|(% style="width:326px" %)**示例** 423 +|(% style="width:106px" %)事件评审和事件记录分析|(% style="width:326px" %)事件经理与服务所有者和其他相关的利益相关者一起,对选定的事件(例如重大事件,未及时解决的事件或特定时期内的所有事件)实施评审,确定事件模型和事件处理程序的改进机会,包括事件处理和解决方案的自动化。 424 +|(% style="width:106px" %)事件模型优化的启动|(% style="width:326px" %)事件经理记录优化方案,它将通过持续改进实践或启动变更请求开始。(如果事件模型、程序和自动化包含在变更支持实践的范围内)。 425 +|(% style="width:106px" %)((( 473 473 事件模型 474 474 475 475 变更的沟通 476 -)))|如果事件模型成功地完成优化,这一事实将会传达给相关的利益相关者。这通常由事件经理和/或服务或资源所有者通过沟通过程完成。 429 +)))|(% style="width:326px" %)如果事件模型成功地完成优化,这一事实将会传达给相关的利益相关者。这通常由事件经理和/或服务或资源所有者通过沟通过程完成。 477 477 478 - 479 - 480 - 481 481 ---- 482 482 483 483 = **4 组织和人员** = 484 484 485 485 486 -== 4.1 **角色,能力和责任** ==436 +== **4.1 角色,能力和责任** == 487 487 488 488 实践指南不描述实践管理角色,如实践所有者、实践负责人或实践教练。相反,指南关注特定于每个实践的专家角色。每个角色的结构和命名可能因组织而异,因此不应强制,甚至不应推荐ITIL中定义的任何角色。记住,角色并非职位头衔。一个人可担任多个角色,一个角色也可以分配给多个人员。 489 489 ... ... @@ -499,7 +499,6 @@ 499 499 |М|**方法和技巧专家 **设计和实施技术、文件化步骤、流程咨询、工作分析和持续改进 500 500 |Т|**技术专家**提供技术(IT)专业知识并执行基于专家经验的作业 501 501 502 - 503 503 === **4.1.1 事件经理角色** === 504 504 505 505 在许多组织中,事件经理角色由专人担任,有时授予事件经理的职衔。在其他组织中,事件经理的责任由负责与事件关联的配置项,服务或产品的人员或团队承担;他可能是资源所有者,服务负责人或产品负责人。 ... ... @@ -526,103 +526,11 @@ 526 526 527 527 表4.2负责事件管理活动的角色示例 528 528 529 -|**实现价值**|**负责角色**|**能力简介**|**具体技能** 530 -|(% colspan="4" %)**事件处理和解决流程** 531 -|事件发现|((( 532 -技术专家 478 +[[image:1642222648578-782.png]] 533 533 534 -用户 535 -)))|TC|理解服务设计,资源配置和业务影响,了解事态的特征 536 -|事件登记|((( 537 -事件经理 480 +[[image:1642222669993-827.png]] 538 538 539 -服务台客服 540 540 541 -技术专家 542 -)))|AT|熟练掌握IT服务管理(ITSM)工具和程序 543 -|事件分类|((( 544 -事件经理 545 - 546 -服务台客服 547 - 548 -技术专家 549 -)))|TC|((( 550 -理解服务设计,资源配置和业务影响 551 - 552 -熟悉事件解决的要求和承诺 553 - 554 -熟悉事件模型 555 -))) 556 -|事件诊断|((( 557 -供应商 558 - 559 -技术专家 560 -)))|TC|((( 561 -理解服务设计,资源配置和业务影响 562 - 563 -具备事件模型、诊断工具、诊断方法的知识 564 - 565 -分析能力 566 -))) 567 -|事件解决|((( 568 -供应商 569 - 570 -技术专家用户 571 -)))|T|了解事件解决的方法和程序要求 572 -|事件关闭|((( 573 -事件经理 574 - 575 -服务台客服 576 - 577 -技术专家 578 -)))|ACT|((( 579 -理解服务设计,资源配置和业务影响 580 - 581 -熟悉事件解决的要求和承诺 582 -))) 583 -|(% colspan="4" %)**定期事件评审流程** 584 -|事件评审和事件记录分析|((( 585 -事件经理 586 - 587 -产品负责人 588 - 589 -服务负责人 590 - 591 -供应商 592 -)))|TCL|((( 593 -理解服务设计,资源配置和业务影响 594 - 595 -熟悉事件解决的要求和承诺 596 - 597 -具备事件模型、诊断工具,诊断方法的知识和分析能力 598 -))) 599 -|事件模型优化的启动|((( 600 -事件经理 601 - 602 -产品负责人 603 - 604 -服务负责人 605 -)))|TMC|((( 606 -理解服务设计,资源配置和业务影响 607 - 608 -熟悉事件解决的要求和承诺 609 - 610 -具备事件模型、诊断工具,诊断方法的知识 611 - 612 -熟悉组织的持续改进和变更管理实践 613 -))) 614 -|事件模型变更的沟通|((( 615 -事件经理 616 - 617 -产品负责人 618 - 619 -服务台客服 620 - 621 -服务负责人 622 -)))|CA|熟悉沟通程序和沟通工具 623 - 624 - 625 - 626 626 == **4.2** **组织结构和团队** == 627 627 628 628 事件管理实践不推荐任何特定的组织模型。但是,组织结构会影响实践的执行方式,因为它涉及具有不同领域和专业水平的专家。专家分组的典型方法包括: ... ... @@ -652,8 +652,6 @@ 652 652 * L3团队间协作,以取代多次重新分配和/或对专家和顶级人才的过度依赖。 653 653 ))) 654 654 655 - 656 - 657 657 === **4.2.2 团队动力** === 658 658 659 659 事件管理实践是团队动力的基础,它们影响着运维支持团队的职责履行。经常出现以下问题: ... ... @@ -687,7 +687,7 @@ 687 687 = **5 信息和技术** = 688 688 689 689 690 -== 5.1 **信息沟通** == 545 +== **5.1** **信息沟通** == 691 691 692 692 事件管理实践的有效性取决于所用信息的质量。这包括但不限于以下信息: 693 693 ... ... @@ -725,17 +725,7 @@ 725 725 726 726 表5.1 事件记录中包含的数据 727 727 728 -|**域**|**推荐内容**|**说明** 729 -|事件标题(简短说明)|观察到的降低或失效的功能或过程|带有清晰说明的解决方案搜索速度更快 730 -|用户|受影响的用户,被报告的用户| 731 -|当前影响|对用户/客户工作流程的实际影响的文字说明|创建上下文,允许排障组提供适当的变通或者解决方法 732 -|未来影响|如果事件持续下去,对客户的潜在影响的文字说明|创建上下文,允许排障组提供适当的变通或者解决方法 733 -|首次症状的时间|监控或用户体验中的日期和时间|诊断原因之前的准确时间点 734 -|最近一次正常状态的时间|验证功能正常的日期和时间|触发事态的准确时间点(此信息是人为添加还是自动记录的,可能会影响可信度) 735 -|受影响项目(功能,配置项,流程)的详细信息|资产ID号,应用程序和流程名称以及配置项索引|集中精力进行修复 736 -|未受影响的可比项目(如果有)的详细信息|未受影响的资产ID号,应用程序和流程名称以及配置项索引|缩小搜索范围 737 -|诊断详情(如果有)|诊断步骤和每步的结果|减少重复工作 738 -|分派|事件的个人或团队所有者| 583 +[[image:1642222734298-342.png]] 739 739 740 740 741 741 == **5.2** **自动化和工具** == ... ... @@ -749,49 +749,12 @@ 749 749 750 750 表5.2 事件管理活动的自动化解决方案 751 751 752 -|**过程活动**|**自动化方式**|**关键功能**|**对实践有效性的影响** 753 -|(% colspan="4" %)**事件处理和解决流程** 754 -|事件发现|监控工具和事态相关引擎|早期的检测和事件关联,初始化事件管理实践|高 755 -|事件登记|用户查询管理和工作流程工具,以及协同工具|有效记录事件|高 756 -|事件分类|((( 757 -用户查询管理和工作流程工具, 597 +[[image:1642222873598-155.png]] 758 758 759 - 协同工具,599 +[[image:1642222893312-806.png]] 760 760 761 -知识管理工具, 762 762 763 -配置管理工具 764 764 765 -和基于机器学习的分类引擎 766 -)))|快速、准确的分类和事件分派,已知解决方案的识别,重大事件的识别|非常高,尤其是在事件数量多的情况下 767 -|事件诊断|((( 768 -分析和诊断工具 769 - 770 -知识管理工具 771 - 772 -配置管理工具 773 - 774 -协同工具 775 -)))|快速、准确的定义和测试假设,多个专家/团队的有效协作|高,特别是在需要手动协作的复杂事件数量很多时 776 -|事件解决|((( 777 -远程管理工具 778 - 779 -自动化的部署系统, 780 - 781 -和协同工具 782 -)))|快速纠正失效的配置项并恢复服务|高,特别是提供远程服务时 783 -|事件关闭|用户查询和工作流管理工具,和协同工具|快速而全面的回顾事件生命周期|中 784 -|**定期事件评审流程**| | | 785 -|事件评审和事件记录分析|协同系统,分析和报告系统以及调查工具|((( 786 -远程协作,事件数据分析和用户调查数据 787 - 788 -分析和报告 789 -)))|中到高,尤其是对批量事件 790 -|事件模型优化的启动|工作流系统和待办项管理工具|优化的正式登记|低到中 791 -|事件模型更新的沟通|通信系统和协作系统|与受影响团队沟通更新|中到高,尤其当组织较大,更新较多时为高 792 - 793 - 794 - 795 795 ---- 796 796 797 797 = **6 合作伙伴和供应商** = ... ... @@ -821,8 +821,6 @@ 821 821 * 保持简单实用 822 822 * 优化和自动化。 823 823 824 - 825 - 826 826 ---- 827 827 828 828 = **8 致谢** =
- 1642222461983-817.png
-
- Author
-
... ... @@ -1,0 +1,1 @@ 1 +XWiki.superadmin - Size
-
... ... @@ -1,0 +1,1 @@ 1 +117.4 KB - Content
- 1642222484248-277.png
-
- Author
-
... ... @@ -1,0 +1,1 @@ 1 +XWiki.superadmin - Size
-
... ... @@ -1,0 +1,1 @@ 1 +68.3 KB - Content
- 1642222648578-782.png
-
- Author
-
... ... @@ -1,0 +1,1 @@ 1 +XWiki.superadmin - Size
-
... ... @@ -1,0 +1,1 @@ 1 +62.3 KB - Content
- 1642222669993-827.png
-
- Author
-
... ... @@ -1,0 +1,1 @@ 1 +XWiki.superadmin - Size
-
... ... @@ -1,0 +1,1 @@ 1 +46.5 KB - Content
- 1642222734298-342.png
-
- Author
-
... ... @@ -1,0 +1,1 @@ 1 +XWiki.superadmin - Size
-
... ... @@ -1,0 +1,1 @@ 1 +84.0 KB - Content
- 1642222873598-155.png
-
- Author
-
... ... @@ -1,0 +1,1 @@ 1 +XWiki.superadmin - Size
-
... ... @@ -1,0 +1,1 @@ 1 +72.6 KB - Content
- 1642222893312-806.png
-
- Author
-
... ... @@ -1,0 +1,1 @@ 1 +XWiki.superadmin - Size
-
... ... @@ -1,0 +1,1 @@ 1 +29.3 KB - Content