由 superadmin 于 2024/12/25, 15:38 最后修改
从版本< 21.1 >
由superadmin编辑
在2022/01/15, 13:01上
到版本
由superadmin编辑
在2021/12/16, 22:57上
< >
修改评论 该版本没有评论

Summary

Details

Icon Page properties
标题
... ... @@ -1,1 +1,1 @@
1 -02 事件管理实践
1 +ITIL 4事件管理实践中文版
Content
... ... @@ -25,10 +25,6 @@
25 25  
26 26  ----
27 27  
28 -{{box cssClass="floatinginfobox" title="**Contents**"}}
29 -{{toc/}}
30 -{{/box}}
31 -
32 32  = **1 关于本文件** =
33 33  
34 34  本文档提供事件管理实践实用指南。分为五个主要部分，内容包括：
... ... @@ -39,8 +39,11 @@
39 39  * 支持实践的信息和技术
40 40  * 对实践的合作伙伴和供应商的考虑。
41 41  
38 +
42 42  == **1.1 ITIL®4 认证方案** ==
43 43  
41 + [[image:file:///C:\Users\19805\AppData\Local\Temp\ksohtml\wps87EB.tmp.png]]
42 +
44 44  本文档的部分内容可以作为以下教学大纲的一部分以供检查：
45 45  
46 46  * ITIL专家：创建、交付和支持
... ... @@ -56,7 +56,7 @@
56 56  = **2 一般信息** =
57 57  
58 58  
59 -== **2.1** **目的和描述** ==
58 +== 2.1 **目的和描述** ==
60 60  
61 61  |(((
62 62  **关键信息**
... ... @@ -63,16 +63,19 @@
63 63  )))
64 64  |事件管理实践的目的是尽快恢复正常的服务运作，以尽量减少事件的负面影响。
65 65  
65 +
66 66  规范的服务运维通常是在服务级别协议（SLA）定义，或在服务质量规范的其他形式中定义的，因为这可以是服务提供者在内部达成的协议。规范可以包含比最初与客户达成的协议更多的质量准则。因此，事件管理实践包括恢复服务和资源的正常运行，即使服务使用者看不到它们的失效或偏差。在这种情况下，日常运维操作在配置项（CI）或服务技术规范中定义。但是，如果没有日常运维的书面规范，则可以使用专家意见来评估资源和服务的状况。如果需要，可以使用事件管理实践来纠正有故障的资源或服务。
67 67  
68 68  事件管理实践是服务管理的基本元素。服务的快速恢复是用户和客户满意、服务提供者的信誉，以及组织在服务关系中创建价值的关键因素。
69 69  
70 70  
71 -== **​​​​​​​2.2** **术语和概念** ==
72 72  
72 +== ​​​​​​​2.2 **术语和概念** ==
73 +
73 73  |**事件**
74 74  |服务的计划外中断或服务质量的降低。
75 75  
77 +
76 76  事件管理实践确保将计划外的服务不可用或降级的时间减至最少，从而减少对用户的负面影响。有两个主要因素可以实现这一点：早期的事件检测和快速恢复正常的运维。
77 77  
78 78  借助有效、高效的流程，自动化工具和供应商关系以及技术精湛且积极进取的专家团队，可以快速检测和解决事件。服务管理四维模型的资源被整合以形成事件管理实践。
... ... @@ -84,12 +84,12 @@
84 84  
85 85  尽管有些事件在服务运营和消费方面的影响相对较低，但其他事件却给服务消费者和服务提供者带来了严重后果，这些被称为重大事件，需要特别注意。
86 86  
87 -
88 88  |(((
89 - **定义：重大事件**
90 +**定义：重大事件**
90 90  )))
91 91  |具有重要业务影响的事件，需要立即协调解决。
92 92  
94 +
93 93  重要的业务影响并不是重大事件的唯一特征。例如，当有多个为高可用性设计的系统和服务时，单个故障不太可能导致严重的业务影响。故障将迅速且通常是自动检测并修复。重大事件通常与更高级别的复杂性相关。例如，如果多个看似微不足道的事件同时发生，则可能会升级并对服务使用者产生影响。诸如此类的复杂事件需要一些特殊的管理和解决方法。实施一个模型来管理所有事件将是有益的，尽管重大事件很少发生且通常具有不同的性质。重大事件的模型可能包括：
94 94  
95 95  * 清晰的准则，以区分重大事件与灾难及其他事件
... ... @@ -100,11 +100,13 @@
100 100  * 与用户，客户，监管机构，媒体和其他利益相关者进行沟通的机制
101 101  * 达成一致的评审与后续活动的规程。
102 102  
105 +
103 103  |(((
104 104  **定义：变通方案**
105 105  )))
106 106  |当事件或者问题无法彻底解决，而采取减少或消除事件或问题影响的变通解决方案。一些变通方案还可以降低事件发生的可能性。
107 107  
111 +
108 108  有时，可能找不到事件的系统性解决方案。在这些情况下，服务提供者可以应用变通方案。
109 109  
110 110  变通方案可以立即将服务恢复到可接受的质量。但是，变通方案可能会增加技术债务，并可能在将来导致新的事件。问题管理实践可用于减少事件解决方法创建的技术债务。在许多情况下，了解事件的原因可以帮助找到最佳解决方案。
... ... @@ -115,8 +115,9 @@
115 115  )))
116 116  |因选择变通方案而非系统性解决方案（需要花费更长时间），而累计的返工总量
117 117  
118 -== **​​​​​​​2.3 范围** ==
119 119  
123 +== ​​​​​​​2.3 **范围** ==
124 +
120 120  事件管理实践的范围包括：
121 121  
122 122  * 发现和登记事件
... ... @@ -151,13 +151,15 @@
151 151  |服务请求的管理和执行|服务请求管理
152 152  |灾难情况下，恢复正常操作|服务连续性管理
153 153  
154 -== **​​​​​​​2.4** **实践成功因素** ==
155 155  
160 +== ​​​​​​​2.4 **实践成功因素** ==
161 +
156 156  |(((
157 157  **实践成功因素**
158 158  )))
159 159  |相关联的一组事务的协同工作机制，是实践活动实现其目的所必需的。
160 160  
167 +
161 161  实践的成功因素（PSF）不仅仅是一项任务或活动，它包括服务管理四维模型的所有功能组件。在一项实践中，PSFs活动和资源的性质可能不同，但这些资源和活动共同确保实践有效。
162 162  
163 163  事件管理实践包括以下PSFs：
... ... @@ -166,6 +166,7 @@
166 166  * 快速有效地解决事件
167 167  * 不断改进事件管理方法。
168 168  
176 +
169 169  === **2.4.1 尽早发现事件** ===
170 170  
171 171  以前，实践通常是根据最终用户和IT专家的信息来报告大多数事件的。这种获取信息的方法仍被广泛使用，但是现在一个好的实践建议是自动发现和报告事件。可以在事件发生后和开始影响用户之前立即被发现。这种方法具有多种好处，其中包括：
... ... @@ -191,9 +191,11 @@
191 191  * 在复杂的情况下，事件的确切性质未知，但支持团队熟悉系统和组件，并且组织可以获取专家知识，因此通常会将事件分派到一个或多个专家组进行诊断和解决。有时，这可以帮助识别模式，并产生一个模型和/或解决方案，可以应用于未来的类似事件。
192 192  * 在非常复杂的情况下，很难或不可能确定专家区域和专家组，或者已确定的专家组找不到解决方案时，采用集体方法可能会有用。此技术称为“全功能团队”。
193 193  
202 +
194 194  |**全功能团队**
195 195  |解决各种复杂任务的技术方法。在全功能团队中，具有不同专业知识领域的多个人员一起完成一项任务，直到明确哪些能力最相关和最需要。
196 196  
206 +
197 197  通常，全功能团队有助于降低复杂度，使其可以切换到低复杂性环境中使用的技术。但是，全功能团队通常适用于性质未知的重大事件。在这种情况下，与仍未解决的事件造成的损失相比，将大量专用资源集中在一起更具有成本效益。
198 198  
199 199  全功能团队不需要举行实际会议。建立计划后，专家可能会独自工作以完成实验，设计脚本，并使用其他工具来发现正在发生的事情。为了应对这一事件，全功能团队使用正确的人员，而不是大量的人员。
... ... @@ -210,6 +210,7 @@
210 210  * 找到并纠正根本原因的能力
211 211  * 机器学习的可能性和质量。
212 212  
223 +
213 213  ==== **2.4.2.1 事件的优先级** ====
214 214  
215 215  事件应尽快解决。但是，参与事件解决的团队的资源是有限的，并且这些团队通常同时参与其他类型的工作。应该优先处理某些事件，以最大程度地减少对用户的负面影响。
... ... @@ -248,8 +248,9 @@
248 248  全面描述采取行动的原因与描述行动本身同样重要。
249 249  )))
250 250  
251 -== **​​​​​​​2.5 关键指标** ==
252 252  
263 +== ​​​​​​​2.5 **关键指标** ==
264 +
253 253  应该基于每个实践对价值流的贡献来评估ITIL实践的有效性和绩效。与任何工具的绩效一样，实践的绩效只能在其应用情境中评估。工具在设计和质量上可能会有很大差异，按照工具的用途使用时，这些差异定义了工具有效性的潜力或能力。关于度量标准，关键绩效指标（KPI）和其它技术的进一步指导，请参见度量和报告实践指南。
254 254  
255 255  事件管理实践的关键指标已映射到其PSF。它们可以用作价值流情景下的KPIs，来评估实践对这些价值流的效能和效率的贡献。表2.2中给出了一些关键指标的例子。
... ... @@ -292,12 +292,14 @@
292 292  事件解决的速度和有效性指标之间的平衡
293 293  )))
294 294  
307 +
308 +
295 295  ----
296 296  
297 297  = **3 价值流和流程** =
298 298  
299 299  
300 -== ​​​​​​​**3.1** **价值流贡献** ==
314 +== ​​​​​​​3.1 **价值流贡献** ==
301 301  
302 302  像任何其他ITIL管理实践一样，事件管理实践对多条价值流有帮助。重要的是要记住，价值流不是由单一实践形成的。例如，即使当价值流专注于事件解决时，也会涉及其他实践，例如服务台、监控和事态管理、服务配置管理、变更支持、供应商管理、基础设施和平台管理以及软件开发和管理。
303 303  
... ... @@ -309,6 +309,7 @@
309 309  * 改进
310 310  * 获取或构建。
311 311  
326 +
312 312  事件管理实践对服务价值链的贡献如图3.1所示。
313 313  
314 314  (% style="text-align:center" %)
... ... @@ -317,7 +317,7 @@
317 317  图3.1 事件管理实践对价值链活动的贡献热力图
318 318  
319 319  
320 -== **3.2 流程** ==
335 +== ​​​​​​​3.2 **流程** ==
321 321  
322 322  每个实践可以包含一个或多个过程和活动，这是实现这一实践目的所必需的。
323 323  
... ... @@ -327,11 +327,13 @@
327 327  )))
328 328  |将输入转换为输出的一组相互关联或相互作用的活动。过程接受一个或多个已定义的输入，并将其转换为已定义的输出。过程定义操作的顺序及依赖关系。
329 329  
345 +
330 330  事件管理活动分为两个流程：
331 331  
332 332  * **事件的处理和解决**。该流程的重点是从发现到关闭的单个事件的处理和解决。
333 333  * **定期事件评审**。该流程确保从事件处理和解决的过程中吸取教训，并确保持续改进事件管理的方法。
334 334  
351 +
335 335  === **3.2.1 事件处理和解决** ===
336 336  
337 337  该过程包括表3.1中列出的活动，并将输入转换为输出。
... ... @@ -352,6 +352,7 @@
352 352  |(% style="width:254px" %)问题记录|(% style="width:119px" %) |(% style="width:177px" %)
353 353  |(% style="width:254px" %)知识库|(% style="width:119px" %) |(% style="width:177px" %)
354 354  
372 +
355 355  图3.2展示事件处理和解决的工作流程图。
356 356  
357 357  
... ... @@ -368,11 +368,45 @@
368 368  
369 369  表3.2 事件处理和事件解决过程的活动
370 370  
371 -[[image:1642222461983-817.png]]
389 +|**活动**|**手动处理用户发现的事件**|**自动发现和处理事件**
390 +|事件发现|用户发现服务运营中的故障，并通过约定的渠道与服务提供者的服务台联系。服务台客服对该用户问询进行初始分类，确认该问询确实属于事件。|监控系统检测到事态，并基于预定义的分类将其标识为事件。
391 +|事件登记|服务台客服执行事件登记，将有效数据添加到事件记录中。|登记事件记录并将其与发现事态的CI关联。登记预定义的技术参数。必要时，给相关技术专家发送通知。
392 +|事件分类|(((
393 +服务台客服完成事件初始分类；这有助于确定事件的影响，确定为失效CI和/或服务确定责任团队，并将事件关联到其他过去和正在处理的事态，事件和/或问题。
372 372  
373 -[[image:1642222484248-277.png]]
395 +在某些情况下，分类有助于找到以前为此类事件定义的解决方案。
396 +)))|(((
397 +根据预定义的规则，将自动发现：
374 374  
399 +* 事件对服务和用户的影响
400 +* 可用的解决方案
401 +* 如果自动化解决方案无效或不可用，找到负责事件解决的技术团队。
402 +)))
403 +|事件诊断|(((
404 +如果分类没有关联到已知解决方案，
375 375  
406 +专家团队开展事件诊断。这可能涉及将事件升级到不同团队，或其他联合技术团队加入（如全功能团队）。
407 +
408 +如果由于配置项关联错误而导致分类错误，则应将此信息传达给负责配置管理的人员（请参阅服务配置实践指南）。
409 +)))|(((
410 +如果自动解决方案无效或不可用，则将事件上报给负责诊断的技术团队。可能涉及事件升级到不同团队，或其他技术团队加入（如全功能团队）。
411 +
412 +如果由于配置项关联错误而导致自动化解决方案失败，则应将此信息传达给负责配置管理的人员（请参阅服务配置实践指南）。
413 +)))
414 +|事件解决|找到解决方案后，相关专家团队将尝试按顺序或并行工作方式执行，这可能需要启动变更。如果解决方案不起作用，则再次诊断。|如果有可用的自动化解决方案，则实施它，并完成测试和确认。如果需要手动干预，则相关的专业团队尝试实施，这可能需要启动变更。如果解决方案不起作用，则再次诊断。
415 +|事件关闭|(((
416 +成功解决事件之后，可能需要一些正式的关闭过程：
417 +
418 +* 用户确认服务恢复
419 +* 计算解决方案成本并报告
420 +* 解决方案结算报价和发票
421 +* 问题调查启动
422 +* 事件评审
423 +
424 +完成所有必需的操作并更新了相应地事件记录后，事件正式关闭。这可以由产品负责人，服务负责人，事件经理或服务台客服完成，具体取决于商定的事件模型。
425 +)))|如果自动解决方案证明有效，则事件记录将自动更新并关闭。发送报告给负责的技术团队。如果在先前的任何步骤中已将有关事件的信息传达给其他利益相关者，则应向其传达事件关闭的信息。
426 +
427 +
376 376  === **3.2.2 定期事件评审** ===
377 377  
378 378  该流程的重点是持续改进事件管理实践，事件模型和事件处理程序。它可以定期执行，也可以由事件报告触发，该报告突显低效率和其他改进点机会。根据现有模型和程序的效果，每两到三个月或更短时间进行一次定期检查。
... ... @@ -399,6 +399,7 @@
399 399  |(% style="width:297px" %)连续性策略和计划|(% style="width:233px" %) |(% style="width:207px" %)
400 400  |(% style="width:297px" %)安全策略和计划|(% style="width:233px" %) |(% style="width:207px" %)
401 401  
454 +
402 402  图3.3 展示事件评审的工作流程图。
403 403  
404 404  
... ... @@ -424,12 +424,13 @@
424 424  
425 425  
426 426  
480 +
427 427  ----
428 428  
429 429  = **4 组织和人员** =
430 430  
431 431  
432 -== ​​​​​​​**4.1 角色，能力和责任** ==
486 +== ​​​​​​​4.1 **角色，能力和责任** ==
433 433  
434 434  实践指南不描述实践管理角色，如实践所有者、实践负责人或实践教练。相反，指南关注特定于每个实践的专家角色。每个角色的结构和命名可能因组织而异，因此不应强制，甚至不应推荐ITIL中定义的任何角色。记住，角色并非职位头衔。一个人可担任多个角色，一个角色也可以分配给多个人员。
435 435  
... ... @@ -445,6 +445,7 @@
445 445  |М|**方法和技巧专家 **设计和实施技术、文件化步骤、流程咨询、工作分析和持续改进
446 446  |Т|**技术专家**提供技术（IT）专业知识并执行基于专家经验的作业
447 447  
502 +
448 448  === **4.1.1 事件经理角色** ===
449 449  
450 450  在许多组织中，事件经理角色由专人担任，有时授予事件经理的职衔。在其他组织中，事件经理的责任由负责与事件关联的配置项，服务或产品的人员或团队承担；他可能是资源所有者，服务负责人或产品负责人。
... ... @@ -471,11 +471,103 @@
471 471  
472 472  表4.2负责事件管理活动的角色示例
473 473  
474 -[[image:1642222648578-782.png]]
529 +|**实现价值**|**负责角色**|**能力简介**|**具体技能**
530 +|(% colspan="4" %)**事件处理和解决流程**
531 +|事件发现|(((
532 +技术专家
475 475  
476 -[[image:1642222669993-827.png]]
534 +用户
535 +)))|TC|理解服务设计，资源配置和业务影响，了解事态的特征
536 +|事件登记|(((
537 +事件经理
477 477  
539 +服务台客服
478 478  
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 +
479 479  == **​​​​​​​4.2** **组织结构和团队** ==
480 480  
481 481  事件管理实践不推荐任何特定的组织模型。但是，组织结构会影响实践的执行方式，因为它涉及具有不同领域和专业水平的专家。专家分组的典型方法包括：
... ... @@ -505,6 +505,8 @@
505 505  * L3团队间协作，以取代多次重新分配和/或对专家和顶级人才的过度依赖。
506 506  )))
507 507  
655 +
656 +
508 508  === **4.2.2 团队动力** ===
509 509  
510 510  事件管理实践是团队动力的基础，它们影响着运维支持团队的职责履行。经常出现以下问题：
... ... @@ -538,7 +538,7 @@
538 538  = **5 信息和技术** =
539 539  
540 540  
541 -== **​​​​​​​5.1** **信息沟通** ==
690 +== ​​​​​​​5.1 **信息沟通** ==
542 542  
543 543  事件管理实践的有效性取决于所用信息的质量。这包括但不限于以下信息：
544 544  
... ... @@ -576,7 +576,17 @@
576 576  
577 577  表5.1 事件记录中包含的数据
578 578  
579 -[[image:1642222734298-342.png]]
728 +|**域**|**推荐内容**|**说明**
729 +|事件标题（简短说明）|观察到的降低或失效的功能或过程|带有清晰说明的解决方案搜索速度更快
730 +|用户|受影响的用户，被报告的用户|
731 +|当前影响|对用户/客户工作流程的实际影响的文字说明|创建上下文，允许排障组提供适当的变通或者解决方法
732 +|未来影响|如果事件持续下去，对客户的潜在影响的文字说明|创建上下文，允许排障组提供适当的变通或者解决方法
733 +|首次症状的时间|监控或用户体验中的日期和时间|诊断原因之前的准确时间点
734 +|最近一次正常状态的时间|验证功能正常的日期和时间|触发事态的准确时间点（此信息是人为添加还是自动记录的，可能会影响可信度）
735 +|受影响项目（功能，配置项，流程）的详细信息|资产ID号，应用程序和流程名称以及配置项索引|集中精力进行修复
736 +|未受影响的可比项目（如果有）的详细信息|未受影响的资产ID号，应用程序和流程名称以及配置项索引|缩小搜索范围
737 +|诊断详情（如果有）|诊断步骤和每步的结果|减少重复工作
738 +|分派|事件的个人或团队所有者|
580 580  
581 581  
582 582  == **​​​​​​​5.2** **自动化和工具** ==
... ... @@ -590,12 +590,49 @@
590 590  
591 591  表5.2 事件管理活动的自动化解决方案
592 592  
593 -[[image:1642222873598-155.png]]
752 +|**过程活动**|**自动化方式**|**关键功能**|**对实践有效性的影响**
753 +|(% colspan="4" %)**事件处理和解决流程**
754 +|事件发现|监控工具和事态相关引擎|早期的检测和事件关联，初始化事件管理实践|高
755 +|事件登记|用户查询管理和工作流程工具，以及协同工具|有效记录事件|高
756 +|事件分类|(((
757 +用户查询管理和工作流程工具，
594 594  
595 -[[image:1642222893312-806.png]]
759 +协同工具，
596 596  
761 +知识管理工具，
597 597  
763 +配置管理工具
598 598  
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 +
599 599  ----
600 600  
601 601  = **6 合作伙伴和供应商** =
... ... @@ -625,6 +625,8 @@
625 625  * 保持简单实用
626 626  * 优化和自动化。
627 627  
824 +
825 +
628 628  ----
629 629  
630 630  = **8 致谢** =
Icon 1642222461983-817.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -117.4 KB
Content Icon
Icon 1642222484248-277.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -68.3 KB
Content Icon
Icon 1642222648578-782.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -62.3 KB
Content Icon
Icon 1642222669993-827.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -46.5 KB
Content Icon
Icon 1642222734298-342.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -84.0 KB
Content Icon
Icon 1642222873598-155.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -72.6 KB
Content Icon
Icon 1642222893312-806.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -29.3 KB
Content Icon
深圳市艾拓先锋企业管理咨询有限公司