服务管理功能
事件管理
本页内容
文档用途本指南为已经或正在考虑在数据中心或其他类型的企业计算环境中部署 Microsoft 技术的组织提供关于事件管理服务管理功能 (SMF) 的详细信息。这是 Microsoft® 操作框架 (MOF) 定义和说明的 20 余个 SMF 中的一个。该指南假设读者熟悉 MOF 的含义、背景和基本概念，以及所涉及的 Microsoft 技术。 “服务管理功能介绍”指南简要介绍了 MOF 及其配套技术——Microsoft Solutions Framework (MSF)。此概述性指南还提供了 MOF 所定义的每种服务管理功能的摘要信息。以下链接处的技术文章提供了有关各个框架的概念和原理的详细信息：http://www.microsoft.com/solutions/msm/. 摘要所有组织都经历过影响或可能影响业务正常运作的事件。随着企业日益依赖 IT 服务，迅速和有效地对负面影响 IT 服务或基础结构的任何事件做出反应的需要变得极为重要。 事件管理是一个很关键的流程，它为组织提供首先检测事件然后准确确定正确的支持资源以便尽快解决事件的能力。该流程还为管理层提供关于影响组织的事件的准确信息，以便他们能够确定必需的支持资源，并为支持资源的供给做好计划。 通过利用事件管理流程，组织能够确保他们的支持资源集中在最紧迫并且可能对业务产生最大影响的问题上。如果没有该流程提供的控制和管理信息，组织将无法确保他们在 IT 支持方面的投资（经常是很重大的投资）是否真正满足其目标。 事件管理的主要优点有：
本文档说明事件管理中涉及的流程和活动，以及事件管理如何与 Microsoft® 操作框架 (MOF) 流程模型中的其他解决方案管理功能 (SMF) 相关联。 流程与活动事件管理概述事件管理流程旨在确保检测到事件，然后记录服务请求。记录确保没有遗漏的事件或服务请求，允许记录得到跟踪，并提供帮助问题管理和活动计划的信息。该流程包括利用技术向客户提供自助服务的功能，为他们提供到支持功能的灵活和方便的接口，同时还降低支持服务台的工作负担和人员要求。 服务请求，例如变更请求 (RFC) 或批处理作业请求，也按照该类服务请求的相应流程进行记录然后处理。 事件经过分类以确保为它们安排正确的优先顺序并发送到正确的支持资源。事件管理包括初始支持流程，这些流程允许根据已知的错误和问题检测新的事件，以便能够快速定位任何以前确定的解决办法。 然后事件管理提供一个可以调查、诊断、解决并终结事件的结构。该流程确保事件在整个生命周期中得到控制、跟踪和监视。 有时可能会发生需要超出常规事件流程所提供的反应的重大事件。事件管理包含用于处理这些重大事件的流程，包括管理和功能上报、有效的沟通和正式的回滚计划。 目的与目标事件管理 SMF 的主要目标是尽快恢复正常服务运作，并最小化对业务运营的的负面影响，从而确保维持良好的服务质量和可用性级别。正常服务运作被定义为服务级别协定 (SLA) 限制内的服务运作。 事件管理的目标包括：
内容范围事件管理处理所有检测到的事件和所有可通过服务台引发的服务请求。 ITIL 将事件定义为：不属于标准服务运作的一部分并且导致或可能导致服务中断或服务质量降低的任何事件。 典型的事件可能包括：
IT 部门接收到的不同服务请求的范围可能因不同的组织而异。常见的服务请求可能包括：
取决于组织的规模和结构，其中有些请求将完全由服务台处理，而其他请求将由其他 SMF 或组织的其他部分中的流程处理。在后一种情况下，事件管理流程作为到相应流程的接口。这样的一个示例是可能传递给变更管理流程的 RFC。 关键定义下面是事件管理流程中的关键术语： 事件。不属于标准服务运作的一部分并且导致或可能导致服务中断或服务质量降低的任何事件。 初始支持小组。为处理事件和服务请求提供一级支持的小组。初始支持小组负责尽量在一线解决事件 — 通过确定已知解决办法、使用诊断脚本或他们自己的知识。在许多组织中，服务台充当初始支持小组。 已知错误。 已知其根源并且已确定临时的解决办法或永久的替代方案的事件或问题。如果存在业务案例，则会引发 RFC，但是在任何情况下，它都保持为已知错误，除非通过某个变更永久地解决。 重大事件 。具有高度影响或潜在的高度影响的事件，这样的事件需要的响应超出为常规事件所提供的响应。通常，这些事件需要整个公司的协调、管理上报、动员附加资源和加强沟通。 问题。一个或多个事件的未确诊根源。 问题解决小组。致力于解决初始支持小组自身无法解决的事件和服务请求的专家小组。支持小组结构因组织而异，有些使用分层结构（第二、第三层，等等），而其他使面向用平台或应用程序的小组（大型机小组、桌面小组、网络小组或数据库小组）。 服务台。提供客户、用户、IT 服务和第三方组织之间至关重要的日常联系点的功能。服务台不仅协调事件管理流程，而且提供进入其他 IT 流程的接口。 服务请求。针对新的或改动后的服务的请求。服务请求的类型因组织而异，不过常见的服务请求包括变更请求 (RFC)、信息请求 (RFI)、采购请求和服务宽限。 解决方案。也称为永久解决。已确定的解决事件或问题的手段，它提供根本原因的解决。 应对方案。已确定的解决特定事件的手段，它允许恢复正常服务，但是并未从源头实际解决导致事件的根本原因。 所有权、跟踪和监视下图显示从最初发生到确认问题已解决之后的事件终结的事件生命周期。 事件管理中的一个基本概念是事件的端对端的所有权、跟踪和监视。服务台实际拥有所有事件，并负责监视它们的解决进度。服务台应该经常更新事件记录（以便能够跟踪进度），并通知用户关于正在进行的进度情况。 在认为解决某个事件的进度已停顿的情况下，服务台需要授权继续，并在必要时上报事件以确保在服务指标内达到解决。工具允许服务台分析员在某段时间内未更新事件记录（这可能指示事件解决过程已停顿）时自动接到通知。 主要流程事件管理可以按照进度流程图的形式图形化地表示，流程图中标识了确保 IT 事件在业务需要的期限内由正确的支持资源做出反应所需要采取的行动。  图 2：事件管理流程流程图 事件管理中的主要流程包括： 检测、自助服务和记录。该流程通过各种不同的方法处理事件的初始检测。事件可由通过电话、传真或电子邮件联系服务台的人员报告。其他事件可能因为来自事件管理系统的警报而引发。 用户可以利用自助服务功能引发自己的事件，检查现有事件的进度，以及访问自助信息。 所有事件都要进行记录，以便能够在它们的整个生命周期中跟踪、监视和更新它们。然后可将该信息用于问题管理、报告、流程优化和规划。 服务请求的处理。该流程允许服务请求的处理和分发。不同类型的服务请求需要以不同的方式处理。服务台也许能够处理某些请求，但是需要将其他请求传递给其他流程（例如变更管理）进行处理。 分类和初始支持。 分类流程对事件划分类别，并使用关于影响和紧迫性的信息确定事件的优先级。 初始支持流程旨在为事件提供第一线解决。为实现这点，可以根据已知的错误、现有的问题和以前的事件进行检测，以便确定有文档记载的解决办法。 调查和诊断。 该流程处理事件的调查和诊断数据的收集。该流程的目标是确定如何能够尽快解决事件。 该流程允许管理上报或功能上报（如果其中任一种上报对于满足 SLA 指标变得必要）。 重大事件过程。 存在重大事件过程是为了处理那些需要超出常规事件过程所提供的响应的严重事件。虽然这些事件仍然遵循常规事件生命周期，但是重大事件过程的触发提供了这些高优先级的事件所需要的增强的协调、上报、沟通和资源。 解决和恢复。该流程涵盖解决事件所需要的步骤，经常是通过与变更管理流程配合以实施补救操作。在采取行动之后，将对解决的成功情况进行检查。 在解决事件（例如替换故障磁盘）之后，可能需要采取恢复操作，例如还原数据和重新启动服务。 终结。该流程确保在关闭事件记录之前客户对该事件的解决感到满意。 该流程还检查事件记录是否得到完全更新，并将其分配到某个终结类别。 检测、自助服务和记录检测若要管理事件，必须首先检测它们。传统上，绝大多数事件都是由在尝试执行日常任务时遇到问题的用户报告的。服务台通过充当用户和 IT 之间的单一联系点在这其中发挥了关键作用。该单一联系点帮助确保一致地处理所有报告的事件和服务请求，同时还最小化对支持团队的干扰，从而允许他们更有效地发挥功能。 事件也可能由 IT 团队、合作伙伴和供应商检测到。报告这些事件的方式可以是通过电话、传真、电子邮件、Internet、浏览器，或者只是由走进服务台办公区域的人员所报告。 事件管理系统的广泛使用现在提供了被检测到的事件的另一个来源。这些系统连续地监视系统和网络基础结构，并且能够在超出预先确定的阈值或组件不可用时进行识别。然后事件管理系统向事件管理流程发出警报。 技术说明存在广泛的事件管理系统正在组织中使用。这其中包括自主开发用于提供单一系统或应用程序的基本监视的脚本、商业性的系统管理产品和复杂的企业管理解决方案。 有些解决方案针对特定的平台，而其他解决方案则提供多平台功能。选择正确的工具对组织来说至关重要，因为这些工具就成本和安装而言通常代表着重大的投资。许多工具最初是为特定的平台设计的。虽然它们现在提供多平台支持，但是该支持的质量可能不如原先的平台。 应该对战略平台使用业界认可的高质量事件管理系统。优秀的跨平台管理系统应该能够合并来自一个或多个产品的事件，以减轻不堪重负的操作员的负担。一经购买，它们还能为如下系统提供监视，这些系统可能未被视为对保证他们自己的自定义监视工具具有足够的战略性。 需要对被监视的阈值进行仔细考虑。不同的用途可能需要不同的阈值。一个必然的指标可能具有对应于 SLA 中的指标集的阈值，以便能够识别对 SLA 的违背情况。但是，事件管理需要更低的警报阈值，以便能够在违背 SLA 之前采取行动。通常，需要一段时间的微调才能确定允许预留采取行动的时间的阈值，但是该阈值不应在正常操作期间频繁被触发。 自助服务概述自助服务功能为 IT 客户提供增强的灵活性和对如何以及何时联系支持部门的控制。在自助服务的环境中，客户能够使用各种方法联系服务台和经营业务。该选择可能包括传统的电话设备、无线设备和传统的键盘设备，并使用浏览器技术或对服务台工具中嵌入的查询功能的访问。不管使用哪种方法，都需要准备好相关控制以确保一致的服务质量级别。存在一些需要在处理不同的访问方法时识别并为之作计划的差别，并且要使概念可行，仔细的设计是必不可少的。 为了使这成为有效的策略，服务台需要识别他们处理的请求的类型，决定哪些请求类型适合自助服务解决方案，然后开发该解决方案。如果进展顺利，组织能够将技术资源解放出来，使之集中在更复杂或特殊的问题上。 例如，如果接收到的请求的 30% 是针对密码重置，那么开发一个允许用户回答身份验证问题然后重置他们自己的密码的功能是值得的。如果随后发现其余的大部分请求都是“如何做”类型的问题，则可以着手开发一个常见问题 (FAQ) 信息功能。关键是要确定当前正在使用大量初始支持资源，但是作为自助服务解决方案也可以工作得很好的请求类型。这样允许将资源集中在其余的请求类型上，例如服务器或网络问题。必须了解请求的概况才能正确地瞄准自助服务解决方案。应该构造一个类似如下的矩阵。 表 1 自助服务矩阵
从上面显示的矩阵中可以观察到，用于密码重置、FAQ 和进度更新的自助解决方案是值得的投资。这样允许初始支持资源有更多的时间尝试解决当前正在传递给二级或三级问题解决小组的一些更复杂的事件。在实施和推广新的自助服务功能之后，更新后的矩阵可能如下所示： 表 2 新的自助服务功能矩阵
该矩阵表明自助服务功能现在已经从支持团队那里取走了很大一部分请求。这样允许每一层将更多的时间集中于以前由于缺乏资源而需要上报的更复杂的事件。注意由初始支持资源所解决的请求百分比降低了；这是因为他们现在处理比简单的进度更新或密码重置花更长时间的请求类型。将时间花在更复杂的事件上提高了团队的工作满足感，同时还降低了对更高层资源的日常影响。这样允许团队将精力集中在更战略性的问题上。 有些类型的请求不适合自助服务方法。由于其性质，请求或者需要来自专家支持人员的响应，或者需要进行跟踪并收集其指标。 高优先级事件通常不应该通过自助服务机制进行报告，而是应该直接向服务台分析员报告。这样有助于确保正确地对所有高优先级事件进行分类，并从事件发源地收集必要的详细信息。 由于通过使用自助服务功能收集关于正在解决的请求的指标更加困难，因此在大多数情况下，这些指标的内容应该针对回答“如何做”类型的请求而不是解决故障。 联系方法若要使自助服务解决方案取得成功，它必须易于使用，以便用户有信心使用它，并相信它会为他们提供通过其他途径联系服务台的替代办法。 不管客户如何进入自助服务环境，他们的进入需要接受验证并且需要收集相关指标。这包括进行的查询的趋势分析（同时包括成功和失败）、进行的联系的容量、自助服务环境的性能以及联系方法方面的更改。该信息有助于识别服务方面的改进，但是也证明了服务的有效性，并提供关于投资回报的信息。 要收集的关键数据包括：
取决于环境，可能需要进行各种授权检查以确保请求者有权访问功能和数据。对于支持许多客户的外包组织尤其是如此，这些客户不应该能够查看彼此的支持请求。授权检查可能涉及正确回答一个或多个安全问题（例如密码或母亲的娘家姓）。需要建立用于收集、安全地存储然后维护该安全验证信息的过程。 技术说明要在验证检查期间使用的安全信息需要安全地存储在数据库中。该信息可能链接到或构成服务台工具中的用户记录的一部分。初始检查可能涉及验证用户记录中包含的用户特定的信息，例如用户的身份证号码、家庭住址或电子邮件地址。 功能的类型进入模式确定了对查询者可用的功能。如果基于计算机，例如键盘，则应该提供标准 Web 界面和搜索引擎。这些可以与服务台工具集成或基于某个第三方工具。 如果进入模式是电话样式的键盘，则需要部署更明确和基于脚本的交互，并且可能需要语音识别技术。 还需要考虑和适应其他进入模式，例如电子邮件，其中预定义的任务表格可能适合用于登记新的服务请求或请求进度更新。这种沟通方法对于提供动态帮助可能不太成功。 典型的高容量但是相对简单的请求可能涉及密码重置。使用基于脚本的自助服务解决方案，服务台分析员不再需要卷入密码重置。需要重置其密码的员工可以访问某个自助服务功能，回答若干身份验证问题，并通过一个引导流程继续重置他们自己的密码。在执行密码更改时，向请求者发送咨询电子邮件作为安全预防措施始终是明智的。 通过自助服务功能进行的新请求需要在服务台系统中捕获，并像其他所有请求一样被分配一个事件编号，以提供审核跟踪和启用后续的进度监视。当自助服务允许请求者更改数据或密码时，与服务台的这种联系尤为重要。然后它可以确保自动将自助服务包括在趋势分析中。该数据的明确分析允许改进服务，并使趋势分析尽可能全面。 可用的信息取决于查询的样式。如果查询基于计算机或基于 Web，则对各种数据源的访问是可能的，其中包括：
信息的内容、准确性和和时间性需要谨慎管理。需要定义并一致同意清楚的角色和职责以确保没有歧义。通过任何形式的自助服务功能可用的信息需要密切监视和审核，以确保符合地区法规 — 尤其要注意数据保护和保密协定。 技术说明使用浏览器技术支持自助服务可能增加组织的网络上的流量，因此监视网络及其组件的容量很重要。语音识别技术正在不断地改进，在自助服务功能中使用的可能性不断增加。 访问自助信息如果用户选择使用自助功能，应该为他或她提供快速查找答案的每个机会，并且尽可能具有最少的混淆。如果用户发现该体验并不愉快，他们今后就可能不会使用它。与其他任何产品一样，用户需要“喜欢”它，然后才会“购买”它。 自助系统通常是有用信息和经验的数据库。用户向该系统提供某个信息，希望能找到与他们的问题“匹配”的信息。该信息可以是错误代码、错误消息或任意格式的问题描述。 如果找到匹配的信息，该信息通常以和最初的查询相同的格式返回。但是，用户也可能要求打印的响应。例如，用户可能希望获得某个 FAQ 的副本，因此可能需要提供包括向请求者发送自动化的电子邮件的响应选项。 一旦返回请求的信息，用户需要有机会根据当前查询优化请求，以选择附加菜单选项或开始新的请求。在设计脚本时，执行完整测试以确保决不会使用户无有效或适当的选择可做是至关重要的；其中包括在任何时候返回到非自助选项的能力。 如果用户希望进行第二个请求，该流程应该为用户提供输入另一个查询而不必再次注册的机会。需要对这里可用的选项进行仔细评估，因为可能存在要考虑的安全问题。虽然自动化的系统一般可能受到更多的控制，因为必须准确满足安全验证，但是通过个人联系处理对应用程序的增加的访问请求也许更为可取。 如果用户无法找到他们正在寻找的内容，或者已到达可用选项的结尾，应该询问他们是否希望联系服务台。与服务台的联系包括从简单地留个话到针对所需信息的完整请求的范围。需要考虑用于监视和管理此类沟通的方法，但是记录该请求已经经历失败的自助请求是必需的，以便能够在可能的情况下对自助服务环境进行改进。 与事件和问题管理的紧密联系在这里明显是必需的，如果自助服务功能的重点是减少简单的常见支持请求（例如更换打印机墨粉盒）的数量，则情况尤其是如此。主要重点应该放在提供高效的、面向客户的查询功能上，这样的功能允许在不卷入服务台的情况下得到处理。必需经常检查该信息以确保它准确并反映支持（服务）信息的当前状态。 可伸缩性自助服务解决方案允许组织在遇到快速增长时实现非常灵活的响应。通常，可能要花数周时间招募和培训服务台团队才能适应增加的要求，例如企业合并所产生的要求。但是，自助服务技术能够满足增加的服务的许多要求而没有这样的时间限制，但是所使用的系统能够扩展以满足未来要求是很重要的。 由于所需要的人员，基于电话接线员的服务是提供支持的最昂贵方法。技术和设备的安装和维护也很昂贵，但是可能始终存在对基于电话接线员的服务的需要，以便处理例外而不是日常的支持请求。将自动化的响应作为主要响应方法需要重大的初始投资，但是也提供了快速和可实现的投资回报。当前的评估表明，设计良好的基于 Web 的自助服务的成本要比等效的传统支持低 5%。 大多数科学研究表明，人们宁愿与非人类的界面进行有限的交互（意味着很短的持续时间），而大多数人更喜欢人与人的接触。但是，正确定位、设计和销售的自助服务解决方案可能被客户视为是有利的 — 银行自动取款机 (ATM) 就是这样的例子。ATM 成功的关键原因是它们方便和易于使用，通过全天候的可用性延长常规服务，并且通常比排队等待人类出纳员提供更快的替代方法。引入自助服务的组织应该从这个例子中学习，并旨在提供同样方便和易于使用的解决方案，提供延长的服务，并且至少像等待与人接触一样快。 但是，随着组织转向自助服务，对复杂维护过程的需要将随之出现。如果要采用自助服务，必须从一开始就做得很好。 记录所有检测到的事件和服务请求都需要记录，以便能够跟踪它们以确保没有任何遗漏。记录所有联系还提供了开始操作和减少特定类型的请求所需要的信息。例如，服务台可能发现很大比率的传入请求都来自只是询问电话号码的人。调查可以发现内部电话目录本已经严重过时。然后可以做出在 intranet 上公布内部电话目录的决定，在 intranet 上可以更容易地维护电话目录。这种主动性不仅减少了针对服务台的请求数量，而且通过允许职员容易地访问最新信息提高了业务效率。如果没有记录电话号码请求，则问题的规模就难于确定，并且可能无限期的继续存在而未得到解决。 应该将事件详细信息记录在服务台工具中的数据库中。对于每个事件，应该使用下列信息填充事件记录：
对于服务请求，上面的许多基本信息仍然需要，不过应该将症状描述替换为所请求的服务的详细信息。有些类型的服务请求可能有自己的用于记录请求的工具（例如用于 RFC 的变更管理系统），而其他请求（例如唯一的批处理作业请求）不大可能有特定的存储库，因此应该作为事件记录进行记录以用于跟踪目的。 应该根据客户数据库中保存的记录检查请求发起人身份信息（例如姓名、部分、位置和联系详细信息），最好将该数据库作为配置管理数据库 (CMDB) 的构成部分。该过程允许包含客户详细信息的记录保持最新。取决于环境，该过程还可以包括提及关于商业详细信息（例如合同号）和安全验证的问题以确认身份。 每个事件或服务请求都应该被赋予一个唯一的参考 ID。应该为请求发起者提供此 ID，如果发起者再次请求更新该记录或检测进度，该 ID 可用于轻松定位正确的记录。在事件由于事件管理或监视工具中的事件或警报引发的情况下，应该将事件或警报参考号包括在事件记录中。这样允许调查事件的人员识别和查看最初的事件或警报。 服务台负责最初从请求发起者那里获得所有必需的信息。可能存在还需要某些澄清或附加信息的情况。在这些情况下，服务台应该联系请求发起者以获得该信息。 在整个事件生命周期中，事件记录在最后终结之前可能经历许多不同的状态。事件记录上的状态字段用于快速识别事件的当前状态。 状态类别的示例包括： 新收到。事件已记录，但是可能还需要澄清。已接受。事件已完全记录，现在已开始初始支持。已分配。事件已分配给问题解决小组，并正在等待解决。活动或进行中。解决事件的操作正在进行中。等待证据。操作已在等待获得附加证据时临时停止。已计划。在到达计划的时间之前不能执行进一步的操作。挂起或中断。操作已临时停止，直至某个事件或时间的到来。已解决。事件被认为已解决。服务台需要在终结事件之前与请求发起者确认解决方案。如果请求发起者对解决方案不满意，则将状态重置为“已分配”或“活动”。已终结。请求发起者已验证事件得到解决，因此该事件已被终结。 事件记录在整个事件生命周期中保持最新是很重要的，这样使所有支持人员都能看到当前正在发生的事情、谁当前正在处理该事件，以及先前曾尝试过什么和发现了什么。最新的记录还允许任何被联系的人员为请求发起者提供进度更新。让客户了解最新的进度情况是直接影响客户满意度的重要因素。更新应该定期提供，具体取决于事件的优先级。例如，高优先级事件可能需要每小时的更新，而中优先级事件每日接收更新，低优先级、长时间处理的事件需要每周甚至每两周的更新。 在记录流程之后，事件将经过分类和初始支持流程，而服务请求则被传递到“服务请求处理”流程。 技术说明事件记录应该在某个服务台工具中记录和跟踪，该工具最好是作为集成的服务管理工具集的构成部分。该工具应该在引发新的事件时提供最基本的事件记录。为了帮助提高效率，这些工具应该在输入请求发起者的姓名时，利用客户数据库自动填充诸如位置、部门和联系详细信息等字段。这些工具还可以使用计算机电话集成 (CTI) 根据传入的电话号码自动填充字段。即使是在已经使用这些技术的情况下，仍然应该在事件记录期间与客户核对诸如联系号码和位置等详细信息这样提供了对 CMBD 中保存的数据的例行审核，并给出了可能需要进一步调查或检查的区域的指示。 服务台工具应该使用必填的字段或脚本确保引发新的事件记录的人捕获所有必需的基本详细信息。 服务台工具可能允许与事件管理系统集成，以便能够在生成警报时自动引发事件。这种自动化从支持团队那里取走了手动填写事件记录的任务，从而提高效率。在警报之后手动或自动创建的事件记录需要包含足够的信息，以允许支持团队识别生成该警报的事件。如果事件或警报具有唯一的参考 ID，则应该将它们与受影响的配置项 (CI) 的详细信息一起包括在事件记录中。 下面的事件记录示例是自动生成的，并且提交者的参考字段已用于记录警报参考 ID。 在事件的生存其中，服务台工具可能根据事件优先级和组织的更新策略，在客户更新到达时自动向服务台分析员发出警报。该警报可能具有多种形式：
处理服务请求在处理服务请求时，第一个操作是识别和记录正在处理的服务请求的类型。正如前面提到过的，有些类型的服务请求具有它们自己的用于记录请求的工具，例如用于 RFC 的变更管理系统。其他请求（例如唯一的批处理作业）不大可能具有特定的存储库，并且应该作为事件记录进行记录以用于跟踪目的。 取决于服务请求的类型，可能需要来自发起者的不同信息。例如，计划唯一的批处理作业所需要的信息与采购请求所需要的信息截然不同。服务台需要确保已记录处理必需的服务请求所需要的所有信息。 接收的服务请求的类型随组织的不同而有显著的区别。应该有一个用于处理组织中的每种不同服务请求类型的过程或工作流。这样可以确保一致地处理特定类型的所有请求。如果开始出现新的请求类型，则应该编写、认可和分发对应的过程。 这其中许多过程可能是简单的界面，描述如何将新的请求注入正在由另一个 SMF 或业务部分执行的流程。这种类型的示例可能是 RFC 和采购请求。服务请求过程需要确保记录所有必需的详细信息，然后将它们传递给相关流程。 其他服务请求可能需要复杂得多的过程或工作流。一个示例就是为新雇员设置系统的请求。该流程可能涉及设置新的网络和电子邮件帐户、让该雇员对安全策略签名、授予对应用程序的访问、安排 IT 和安全入门培训、更新内部电话目录、更新 CMBD，以及采购和配置诸如便携式计算机和电话等新设备。 技术说明对于这些更复杂的请求，使用工作流管理系统对请求分类并跟踪各个工作操作是有益的，这其中有些操作可以并行执行，而其他操作则必须等待，因为它们依赖另外的操作。通过创建描述操作和依赖项以及执行每个操作和依赖项所需要的团队的流程图，工作流管理工具还可以帮助工作流过程的设计。 有些服务请求可由初始支持小组（通常是服务台）完全处理，而不必将请求传递给另一个流程或小组。这类请求的示例是在由 IT 部门运作的用户培训课程中注册某人的请求。该过程可能允许服务台检查可用性并完成注册，而不必联系培训部门。 在初始支持完全处理服务请求的情况下，他们应该执行必要的操作，通知发起者请求已经执行，确认发起者对解决方案感到满意，然后终结该请求，同时确保记录已经完全更新。 在已将请求传递给另一个流程或小组的情况下，初始支持负责获得处理此特定类型的该请求所需要的相关信息，并将它传递给其他流程或小组。 在绝大多数情况下（即使服务台已传递请求），如果请求发起者想要查询进度或修改请求详细信息，服务台仍然充当联系点。在这些情况下，服务台应该将请求分配给相关小组，然后跟踪并监视该服务请求的进度，从而充当发起者和其他流程之间的接口。如果请求的进度似乎放慢了，服务台将通过联系所涉及的小组确认当前状况，并在必要时上报事件以确保满足服务指标。如果在任何时候需要将请求重新分配给不同的小组，服务台将再次执行此操作。 一旦认为请求得到解决，服务台应该联系发起者并确认他或她对解决方案感到满意，然后终结该请求，同时确保记录得到完全更新。对于有些请求，通过电子邮件将请求已得到解决的信息发送给发起者，并在解决方案不令人满意时在服务台提供联系方式，这样可能是适当的。该电子邮件应该通知发起者：如果服务台未在给定的时间（例如三周）内收到反馈，则假设该解决方案是完满的，该请求将被终结。取决于服务台工具，在请求进入“已解决”状态时自动向发起者发送标准电子邮件，并在跟定的时间限制内没有输入任何更新时自动终结请求，这是可能的。 在不需要服务台跟踪（通常是因为已即时完成并通知发起者）的情况下，服务台将确保更新请求记录然后终结请求。 技术说明有些服务台请求类型具有用于记录和跟踪请求的特定工具。这些工具可以是自主开发的解决方案或第三方产品，或者独立于服务台工具或与服务台工具集成。下图是用于记录和跟踪变更请求的此类工具的示例。 没有特定工具的服务请求类型应该使用事件记录进行记录和跟踪。下图是该格式的批处理作业请求的示例。 分类和初始支持分类：概述必须对事件分类以便使用适当的解决方案尽可能有效地处理它们。分类是对给定的事件归类和进行优先级设置的流程，是事件管理中非常重要的第一阶段，因为它确定要采取的后续操作。分类用于：
大多数事件可能是经常遇到的（例如密码重置），因此它们的分类是已知的。其他事件需要调查才能分类，有许多技术可用于实现这个目的。
根据 CMDB 执行检查如果在根据 CMBD 执行检查时识别出差异，向配置管理部门引发异常报告以采取更正操作是很重要的。异常的事实可能指示未经授权的变更或变更流程中的故障。简单的异常报告可能如下： 日期：2002 年 4 月 1 日，CI 记录编号：Software1000 记录的数据：Excel 2000 8.5 版 报告的数据：Excel 2000 版本 7 技术说明服务台能够直接访问 CMBD（最好是通过集成的服务台工具集）是很重要的。当事件记录上仅记录了客户的姓名或电话号码时，集成允许自动填充来自 CMBD 的关键事件记录字段。除了允许服务台取得控制并从事件的最初阶段就保持主动（这样能够提高服务台效力和客户信心）外，它还提示验证 CMBD 数据和识别任何异常。 下图中的搜索针对目录 (CI) 编号，但是 CI 也可以按名称、所有者、提交者、部门或位置进行选择。 与 CMDB 集成的好处在于，它优化了数据访问的速度，确保术语和方法的一致使用，或许最重要的是确保单一的、受信任的信息源。多个或未集成的工具的使用给关键服务领域引入了一定程度的风险和低效率。 诊断脚本诊断或故障排除脚本为请求接受者在解决故障时提供协助，并且通常使用结构化的问题-响应-操作流程。如果必要，可以设置脚本处理常见类型的事件，以便在记录请求并将其移交给第二线小组之前执行第一线筛选和信息收集。 脚本还可用于提示操作员捕获特定于故障的附加信息。例如，“无法打印”可以自动提示输入打印队列和服务器名称，然后将它们作为请求细节的组成部分进行记录。一个示例“无法打印”脚本如下：
诊断脚本并不只是被动的。还可以将它们用作“专家工具”，其中对问题的响应将触发一个操作，以便在诊断流程中自动显示过程和其他文档。例如，如果脚本揭示用户配置设置不正确，则可以显示 CMDB 中的相关设置的关系图。类似地，对于“如何做”类型的查询，可以显示联机手册中的相关文档。 脚本还可以运行另外的 Microsoft? Windows 操作系统应用程序，例如“网络错误”脚本可以自动启动网络诊断工具集。 这些活动脚本的使用几乎是无限制的：它们促进由非专家团队实现的问题解决，以及最小化用于请求更多信息的回叫的数量。 归类和优先级所使用的分类类别随组织而异，但是它们始终应该在 IT 部门和业务部门之间达成一致。这些部门之间可能存在冲突，因为前者在性质上主要是技术性的，而业务部门可能不是。 如果分类类别过于基于技术，那么服务台分析员必须能够将业务用户描述的症状转换为技术上的等效项。这些情况下更可能出现匹配错误和问题，如果业务部门无法容易地理解他们的信息，则转向自助服务环境可能存在问题。 如果初始支持无法解决事件，谨慎选择类别将有助于准确分配问题解决小组，并且事件分类的一致性使得定位自助服务功能更加容易。 示例类别如下所示：
不管选择什么类别，最重要的方面在于，支持和业务用户代表应该参与初始设计阶段，因为随着关联的数据量的增加，分类变得更难于更改。 技术说明在选择服务台工具时，必须考虑到分类类别的设计，因为就这方面而言，有些工具不如其他工具灵活。如果使用不适当的分析工具，可能会将关键信息归入自由格式的文本字段，从而阻止趋势分析和自助服务开发。如果没有适当的 CMDB，则这一点尤为重要，因为所有分析都将记录在事件记录中。 服务台应该确定哪些服务和 SLA 会受所报告的事件的影响，因为这样将允许设置适当的优先级。在确定受影响的服务和 SLA 时，应该使用 CMDB 作为信息源。 优先级设置是管理事件的重要方面，因为它总结事件的特征并确定总体解决方法。 事件的优先级通常由事件的影响和紧迫性之间的关系确定，该关系反过来又影响目标解决时间。例如，高影响、高紧迫性事件将收到高优先级，而高影响、低紧迫性事件将收到低优先级，低影响、高紧迫性事件也是如此。不正确的优先级分类会妨碍有效地执行事件管理的能力。 事件优先级应该基于： 受影响或可能受影响的服务和 SLA。服务级别协定使服务提供商和客户群之间的关系形式化。必须将事件与正确的 SLA 相联系才能实现正确的分类。这样快速和准确地确立了事件的紧迫性及其对业务的影响，因为 SLA 标识了受影响的服务、该服务的用户和服务中断的后果。它还记录恢复正常的预期时间表和调用业务连续性计划的安排。还应该考虑任何关联的 OLA 和 UC。 与所分配的类别关联的任何相关优先级。类别可用于确定相关优先级以协助团队确定应该赋予每个事件的优先级。相关优先级应该作为在确定要赋予事件的实际优先级时的起点。 表 3 事件类别和优先级
但是，此视图并未区分业务领域，因此所有电子表格故障都被分配相同优先级，这样或许是错误的。下表显示一个与业务领域匹配的更紧密的替代视图。 表 4 业务领域和优先级
业务影响和危急程度。事件的影响通常由它对组织的业务影响确定，通常称为“业务影响”。这种方式的业务影响确定只有在 SLA 制定期间与业务部门达成一致的情况下才能有效地进行。影响危急程度的因素包括：
请求的紧迫性。这与需要按照其影响解决事件的速度相关。高影响的事件也可能是紧迫的，但并不始终是这样。事件可能对组织具有高影响，但是如果组织在 6 个月内不需要该应用程序可用，则该事件也是低紧迫性的。或者，事件也可能具有高紧迫性但是具有低影响，例如主管的秘书之一的个人计算机问题。同样地，紧迫性会随着时间而改变：例如在 1996 年，2000 年问题具有非常高的影响，但是紧迫性并不高，到 1997 年，它具有更高的影响并变得更加紧迫，到 1998 年，其紧迫性再次提高，依此类推。 下表显示一个基于影响和紧迫性的示例优先级编码系统。 表 5 影响与紧迫性优先级编码系统
目标解决时间事件的目标解决时间是 IT 组织需要解决事件以便保持在协商的服务级别内的截止时间。事件的不同优先级将具有不同的目标解决时间。 分配给事件的优先级可用于确定目标解决时间，如下表所示： 表 6 示例优先级代码和目标解决时间
目标解决时间需要进行设计，以便与协商的服务指标相对应。然后可以根据这些目标解决时间设置自动上报时间。重大事件没有显示目标解决时间，因为根据其性质，这些事件已超出所认为的“常规”，因此解决时间千差万别。重大事件期间的上报是重大事件经理的职责。 初始支持初始支持是服务台能够令客户满意地解决事件而无需涉及其他任何支持领域的流程。通过将报告的事件与已知错误进行匹配，并向客户提供已知解决方案或变通办法的详细信息，服务台也许能够实现这个任务。在这种情况下，必须将事件记录链接到已知错误记录，以便能够在永久性的解决方案可用时识别所有受影响的用户，并在检查用于解决已知错误的优先级时提供帮助。 或者，服务台分析员也许能够根据个人经验或通过规定的培训计划获得的专业经验提供解决方案详细信息。当其中任一种情况都不可能时，服务台分析员可能需要搜索知识库以匹配客户描述的症状。如果其他来源提供了解决方案建议，则应该更新已知错误数据库，并根据事件记录记录解决方案的完整详细信息。通知配置经理以便 CMDB 也能得到更新也许是适当的。 已知错误是以前报告并解决的事件的记录。如果没有完整的解决方案，也至少存在一种可用的变通办法。当存在已知错误数据库时，它应该对所有服务台分析员可用，并且必须小心维护。可能存在这样的情况，即临时提供一个变通办法，而完整的解决方案正在开发中，或正在等待软件的新版本发布。这可能要花一些时间，错误可能影响许多用户。使用 SLA 中记录的详细信息，服务台能够识别有风险的业务用户并采用主动的方法，给出潜在问题的警告并通知变通办法的存在。 技术说明知识库可由组织内部开发（或许是使用数据库或专家 CRM 工具），或者由供应商使用浏览器技术提供。如果是内部开发，则设计注意事项应该包括必填字段的定义、关键词用法和搜索方法。应该建立单一所有点以控制内容，并整合访问者跟踪以便能够监视使用情况。随着该功能的开发，它将被使用得更加频繁，并且跟踪使用程度和范围很重要，因为这样提供了用于趋势分析的有用数据。 如果依赖供应商提供的数据，则可能存在关于这些标准的约束，虽然影响内容也许是可能的。 必须谨慎处理用户组信息，因为它可能包括与一系列发布版本有关的成分，并且对术语、结构或内容的控制很少。用户组信息通常基于公告牌或讨论组方法，但可能是当前经验的理想来源。最好将它们的使用限制到服务台和问题解决小组而不是整合到自助服务环境中。 实现变通办法是完全可接受的事件处理方法。变通办法可能是开发更永久的解决方案时的临时响应，或者可能就是永久解决方案本身。 如果变通办法解决了事件，则服务台分析员可以继续采取事件终结操作。如果这次未成功而以前成功了，则事件匹配不正确，必须取消链接并返回初始支持，并作为事件管理流程中的下一阶段与现有的问题进行匹配。 如果事件能够与某个现有的问题匹配，则遵循用于已知错误的相似流程。如果找到匹配的问题，则必须将事件链接到该问题记录，如果存在变通办法，则必须实现该变通办法、确认解决方案然后采取终结操作。如果未实现解决方案，则必须取消事件与该问题的链接，并返回以进行进一步的调查。 如果事件已链接到现有的问题，但是问题管理仍在努力寻求变通办法，则应该将问题记录参考和状态通知发起者。然后问题管理应该继续处理问题，并在确定变通办法或解决方案时通知事件管理。 未能与已知错误或现有问题记录匹配的事件可与以前的事件进行比较。历史事件记录经常是很好的信息源，它们提供过去如何解决类似事件的详细信息。这里就是需要完全更新事件记录的地方，对症状和采取的操作的清晰而简练的描述变得极为重要。 如果事件匹配一个或多个以前的事件，则可能指示存在一个根本性的问题。如果存在任何疑问，应该通知问题管理。然后决定是否创建新的问题记录就是问题管理的职责了。 技术说明如果使用集成的工具，则事件、问题和错误的匹配可以最有效地执行。即使部署了集成的工具，如果未在整个组织中一致地使用，其好处也会丧失。如果事件、问题和已知错误以受控和一致的方式进行记录，则结果数据将允许更高效的匹配和报告。维护工具的所有权并实施控制，对于确保访问该工具的所有各方按照规定过程中的定义一致地使用它是至关重要的。在理想的情况下，对工具的这种一致和受控的使用应该在最初部署时就准备就绪，因为一旦团队分别按照各自的标准使用该工具，重新建立使用策略就非常困难了。 如果组织使用本地服务台，则匹配通常只能在本地完成，从而限制了共享正在工具集中逐步增加的累积知识的潜力。全球性组织在实现集成时将遇到更多困难，因为成本、语言和基础结构考虑事项可能使得单一工具的使用很困难或者不可能。此外，有些业务流程可能集中于特定的国家并具有有限的通用性，从而使得集成不是很有价值。 初始支持团队也许能够使用他们自己随时间累积的隐性知识解决事件。通过提供让业务团队进入支持部门的机会，从而引入他们的业务流程和应用程序经验，组织可以提高服务台可用的隐性知识的水平。还可以使用正式的培训提高在一线解决的事件的比率。但是，时间像知识一样在这里也是一个问题。通常，初始支持团队可能觉得他们有知识进一步钻研特定的事件，但是由于传入请求的压力而必须将该事件移交给问题解决小组。决定应该在事件的初始支持上花多少时间是服务台的一个关键容量问题，并在整个支持链中都有牵连。 在可能的情况下，团队应该通过提供解决方案建议尝试在初始支持期间解决事件，只要这不影响答复和处理传入请求的目标。“在一线成功解决请求”是一个有价值的指标，并且是客户满意度和成本削减的关键组成部分。在认为已经达到解决时，应该将事件推进到终结流程。 在初始支持未能解决事件的情况下，应该根据事件分类将事件分配给问题解决小组。取决于事件的类型，问题解决小组可能是内部团队或外部供应商。在任一种情况下，服务台都要保留事件的所有权，并负责监视和跟踪事件进度。 初始支持团队需要能够访问任何企业支持协定的详细信息，包括签约的服务级别、合同详细信息、服务时间和预期的响应时间。在将事件上报到外部供应商时，联系供应商的支持团队拥有所有必需的详细信息是至关重要的。对于每个外部合同，都需要生成和维护将在记录请求时索取的信息的列表。该信息通常包括合同或协定编号、站点 ID、受影响的产品的详细信息（硬件型号和序列号或软件版本和补丁级别）以及来自供应商的需要的优先级别建议。有些合同可能只允许按命名的合同记录新请求。如果是这种情况，则命名的合同的列表必须是最新的并且随时可用。 技术说明用于向外部供应商传递事件的接口比使用电话或传真联系供应商更加集成。两种常见的方案为：
成功实现这种集成水平的关键因素为：
调查和诊断如果初始支持未能解决事件，则它将移交给调查和诊断流程。这是从将事件分配到问题解决小组是开始的。问题解决小组可能包含广泛的 IT 团队，包括支持和开发人员、其他 SMF、组织中的其他单位、外包提供商、合作伙伴和其他第三方。 问题解决小组的数量和规模取决于组织。通常，支持组织使用下列方法之一构成：
该结构需要满足各个组织的需要，但是要记住增加的复杂性将增加成本。单独的支持团队的数量越高，共享信息和提供技能重用就更加困难 — 更可能的是需要在处理复杂事件时进行仲裁来决定职责。在解决事件的职责出现争议的情况下，服务台应该与参与各方讨论该问题以确定是否能够达成协议。在无法容易地达成协议的情况下，问题管理应该负责仲裁。 不管问题解决小组的数量和复杂性如何，都必须对该结构进行清楚的文档记录，以便所有人员都了解应该向每个团队分配哪些请求类别，以及在必要时的上报路线是什么。没有清楚定义的支持结构将增加成本、沮丧和解决时间，同时降低客户满意度。 服务台工具应该具有用于每个问题解决小组的队列。监视其队列并推进分配到该队列的事件是问题解决小组的职责。支持团队成员可以登录服务台工具并查看他们的队列中定期刷新的事件列表。 技术说明可以使用广泛的工具协助问题解决小组进行队列管理。这其中包括使用大屏幕监视器或专门设计的电子显示牌在问题解决小组的办公区内显示队列状态。可以配置大型电子显示牌显示来自许多不同系统的关键输出，包括服务台系统和事件管理系统。 如果浏览器不支持内联框架，请点击此处 查看单独的页。图 15 问题解决小组队列的示例 许多支持团队是移动的，需要能够从不同的位置看到他们的队列。这可以通过允许支持团队通过 Internet 浏览器从组织中的任何个人计算机连接到服务台来实现。无线技术允许为支持团队配备个人数字助理 (PDA),这些设备可与服务台系统同步以显示最新队列以及更新现有的事件。必须采取一些步骤，确保这卸系统的安全。 在团队无法连续监视队列的情况下，同样可以采用技术在新的事件被分配到队列时为他们提供通知。通知可以采用弹出框、电子邮件或移动文本消息的形式。 当事件被放在问题解决小组队列中时，然后应该将它分配给小组成员以进行处理。维护事件记录（使用最新状态、所采取的操作和进度来更新它）是小组成员的职责。 应该使用所采取的每个操作的下列信息更新事件记录：
如果在任何阶段觉得需要将事件分配给不同的问题解决小组，则当前问题解决小组应该将事件重新分配回服务台，后者又将进行新的分配。这样减少了请求在问题解决小组之间连续推诿的可能性，并允许服务台准确发现需要仲裁的情形，从而更有效地协调事件管理流程。 不应该允许问题解决小组自己终结事件。一旦认为事件得到解决，则应该将其置于“已解决”状态并将其分配给服务台。然后服务台分析员应该在终结事件之前确认发起者对解决方案感到满意。 一旦将事件分配给问题解决小组中的团队成员，他或她应该评估到目前为止的详细信息，并收集任何需要的事实。 技术说明配置管理数据库 (CMDB) 可能是事件调查期间用于查明事实的重要工具。该数据库可用于查看受影响的配置项 (CI) 的详细信息（例如加载的软件版本和这些 CI 的历史记录），以及检查涉及那些 CI 的任何支持合同或担保的详细信息，并确认它们的位置。 CMDB 还可用于识别与受影响的 CI 相关的 CI，以便能够通过重新发送或重新配置相关 CI，从而采取步骤最小化事件的影响。 CMDB 的另一个用途是识别与发生故障的 CI 完全相同的其他 CI，以便能够将它们用于比较目的，寄望于揭示导致事件的差别。 一旦支持团队完成任何事实收集，他们应该考虑到目前为止所收集到的信息是否表明这是某个已知错误的实例。已知错误可能来自各种来源 — 例如，问题管理维护的公司已知错误数据库、供应商提供的已知错误数据库以及 Internet 站点（包括供应商站点和相关新闻组）。 技术说明供应商提供的知识库中的可用信息财富使得它们成为支持团队的至关重要的工具。这些知识库可通过供应商网站或作为 CD/DVD 包获得，通常是具有站点或单独许可证的可购买件。 知识库包含各种各样的信息，包括已知错误、修复、更新的驱动程序、白皮书、常见问题 (FAQ) 技术文章。 供应商提供的知识的巨大优势在于，组织能够从事件在其他站点上发生时累积的诊断和解决方案信息中获益，如果组织遇到相同或类似的事件，这通常会导致更快的解决。 供应商通常还以联机帮助文档和搜索功能的形式提供他们的产品中的大量帮助信息。在有些情况下，可以从特定于产品的资源工具包获得附加文档和有用的实用工具。 有些系统管理工具还包含知识库，以便在生成警报时能够提供附加诊断和/或解决方案建议。与所有供应商提供的知识库一样，需要准备用于确保获得定期更新的机制，以使所提供的关于已知解决办法和修复的信息保持最新。 组织还可以累积他们自己的公司知识库。这些公司知识库可以包含与支持组织的 IT 基础结构有关的任何信息。供应商提供的知识库可能包含大量与特定组织不相关的材料，而公司知识库可被构造为包含特定于组织运营的信息。公司知识库可使用自主开发的数据库或设计用于该目的的第三方工具进行构造。 如果事件确实与某个现有的已知错误匹配，则应该更新事件记录以将其与该已知错误记录关联。取决于所使用的工具，这可能涉及在集成的工具集中链接两个记录。但是对于独立的工具，它可能只是意味着在事件记录中包括已知错误 ID（以及空间所允许的任何附加详细信息），并在可能的情况下更新已知错误记录上的事件计数。然后应该将事件推进到解决和恢复流程，可以在那些流程中应用在已知错误中确定的变通办法或解决方案。 然后应该对照现有问题检查未能与已知错误匹配的事件。现有问题是问题管理当前已知但是尚未确定针对根源的解决办法的问题。现有问题可能有也可能没有已确定的变通办法。如果事件匹配现有问题，并且存在已确定的变通办法，则应该将事件与该问题记录关联（通过链接或交叉引用），然后推进到解决和恢复流程以应用该变通办法。 如果认为事件与某个现有的但是还没有确定变通办法的问题相匹配，则应该将事件记录移交给问题管理。确认事件是否与该问题匹配，以及是要接受该事件（将它与相关问题记录关联）还是在发现匹配不正确时将其退回到事件管理，这是问题管理的职责。问题管理继续处理现有问题，并在找到具有关联的事件记录的问题的变通办法或解决方案时负责通知事件管理。一旦接到通知，解决、恢复和终结任何未完成的事件就是事件管理的职责。 将事件与已知错误和问题进行匹配的流程继续贯穿于事件的调查和诊断过程中。随着进一步的诊断证据的收集（例如新的事件 ID 或错误代码），应该将该新信息注入到匹配流程中。作为调查流程的组成部分，还可以检查以前的事件记录以确定过去是如何解决任何类似的事件的。 事件管理通常集中于尽快恢复正常服务。对此的例外是怀疑有恶意企图的情况。在这些情况下，支持团队应该与安全团队合作，并依照安全团队的策略和过程处理安全事件。确保保留所有可用的证据以便在法律或纪律程序中使用通常是很关键的。安全小组应该协助证据收集和存储，并提供关于哪些证据可采纳和需要包括哪些上下文详细信息（计算机 ID、日期和时间戳）的指导。取决于事件导致的影响，可能需要做出是在活动系统上解决问题（可能改写关键证据）还是切换到备用连续性安排直至肯定所有可用的证据都已收集的决定。 调查和诊断阶段包括支持团队首先清楚了解正常服务是如何受影响的，然后识别导致该影响的原因，最后确定如何进行变通或解决。 在最初报告事件时，关于问题的性质、程度和总体影响的信息可能非常有限。事件记录应该包括来自发起者的尽可能多的信息，但是该信息通常受到个人视角和知识水平的限制。为了使支持团队能够解决事件，他们必须首先找到关于事件的更多信息。这应该包括找到所产生的确切错误消息或事件代码，确认在事件之前采取的任何操作，以及确认事件的范围 — 例如它是只影响报告事件的单个用户还是影响该服务的所有用户。支持团队应该查看日志文件和事件日志，并在可行的情况下尝试重现问题以便能够实地观察它。 实际拜访用户以观察问题的难易程度随地理位置而异。因为即使访问本地用户也要花时间，所以目标应该是远程解决尽可能多的事件。正如前面所陈述的，事件管理的目标是尽快恢复正常服务，因此如果可以远程完成而无需旅行时间，那么这是符合该目标的。但是，如果在事件生命周期中的任何阶段拜访客户会可能会带来更快的解决（尽管有旅行时间），那么这也是应该考虑的。注意事项中的部分内容还包括根据花更长时间解决事件的影响来调整拜访所涉及的成本。虽然策略是应该最小化旅行过程中所花的时间开销，但是组织需要确保这不会阻止合理的拜访从而拖延事件。 还应该考虑支持组织的结构以及支持团队是应该处于集中位置还是跨站点分布。一般情况下，分布增加了复杂性，从而增加支持组织的成本。但是，经常必须设计该结构以便满足议定的服务级别。例如，如果议定的服务级别要求一小时的现场响应，并且该现场离其他支持位置很远，则某种形式的本地存在将是必需的。取决于所涉及的成本、安全性质、招募的容易性和需要的支持等级，组织可以考虑外包远程位置的现场支持。 技术说明可以使用远程支持工具帮助最小化对现场访问的需要。这些工具包括允许远程查看日志的实用工具和针对远程计算机运行的管理实用工具。始终应该采取一些步骤确保这些系统的安全（避免未经授权的使用）。 使用允许支持人员查看用户正在远程系统上的经历的体验（并在必要时接管系统以调查事件彬并应用任何解决方案操作）的远程工具，这样可以实现增加的功能。当支持团队负责位于远程或无人照管的房间中的系统时，这些工具也是很重要的。 一旦支持团队了解了事件，他们需要确定事件发生原因以及如何解决或绕过该问题。事件管理对事件的直接原因而不是导致问题管理感兴趣的可能的根本原因感兴趣。关于这点的一个示例在于，事件管理可能将事件根源确定为被“锁定”或“冻结”的文件服务器并重新启动它以解决事件，而确定这是否为独立的事件或者是否存在导致该服务器（以及其他服务器）锁定的根本问题则是问题管理的职责。 尽管有彻底的更改和发布管理流程，但是仍然可能由于已应用的变更而发生某些事件。当事件发生而无法确定直接原因时，支持团队应该检查最近发生的变更以确定是否有任何相关性。正式的变更管理不仅旨在防止由于变更而发生进一步的事件，而且还确保在这样的事件确实发生时，能够获得关于已做出的变更的完整细节。 在排除复杂的事件时，支持团队应该研究所有可用的证据，然后将证据划分为更简单的单元。为了确保有组织和和合乎逻辑的方法，通过在纸张或白板上绘制或使用软件工具将问题作为图形表示形式呈现出来将是有用的。它可以是流程图、数据流图或网络关系图的形式。适当的图形表示可以帮助识别所涉及的组件和接口，从而识别潜在的故障点。此时可能需要自由讨论会以确定所有可能的故障点。如果存在若干个潜在的故障点，可以应用加权来评估每个故障点成为事件的直接原因的感觉可能性和检查每个故障点的难易程度。然后该加权还允许设置调查操作的优先级。 为了允许支持团队重现事件并在现场环境之外测试变通办法，他们应该访问尽可能紧密地镜像现场环境（或其部分）的测试环境。虽然不大可能准确重现现场环境的规模和工作量，但是仍然可以从缩小的测试环境获得重要好处。论证测试环境的合理性可能是一项困难的任务。然而，应该做出这笔投资以防止这样的无限循环：为解决一个事件所做的变更（使用变更和发布管理流程）由于未在现场环境中做出变更之前执行足够的测试而导致另一个事件。 为了帮助故障的诊断，支持小组可以使用诸如监视和会诊等技术。 监视可由更资深的个人（可能来自支持结构的更高层）向初级支持团队提供。一旦完成事件诊断，较资深的团队可以提供关于如何调查特定事件以及如何解决它的建议和指导。这样具有增加初级团队的知识和经验的好处，同时还减少需要分配给较资深的团队的事件数量，从而使他们有更多时间处理更复杂和更战略性的问题。这种知识共享是应该提倡的。然而，如果团队觉得对于满足服务指标是适当的，则仍然应该上报事件。 定期的正式会诊可由小组成员主持。在这些会议期间，可以讨论任何未完成的事件的详细信息，以便其他团队成员能够提供建议或提供他们自己的经验的好处。同样，这是一种知识共享形式，它利用小组成员对基础结构和环境的隐性知识。当团队在地理位置上不同时，可见电话会议或视频会议功能用于这些会议。 有时采用的一个不同的知识共享形式是使用特定于主题的电子邮件列表提问题。当个人具有关于某个特定主题的问题时，他或她可以向相应的分发列表发送电子邮件，以确定该列表上是否有任何人能够提供建议或解决方案。例如，可能存在一个包括具备数据库知识的所有职员的电子邮件列表，另一个用于消息产品，还有一个用于基础操作系统知识。 取决于正在调查的事件和组织中的经验，通过在基于 Internet 的相关论坛上张贴问题来从外部寻求知识可能是适当的。可用的论坛很多，它们通常针对特定的平台或应用程序，其中提供了与其他组织中正在使用相同产品的职员讨论问题和共享知识的机会。 技术说明有些服务台工具允许将诸如日志文件、事件记录或作业流水帐等电子证据附加到事件记录。然后处理事件的团队直接从事件记录中打开附件文档而不是搜索它们。 一旦确定了可能的变通办法或解决方案，则应该在可能的情况下在现场环境之外进行测试。过去，为解决一个事件所实施的变更导致其他许多事件是司空见惯的事情。为避免这点，支持团队应该尽可能彻底地测试建议的变通办法或解决方案，然后通过变更和发布管理流程移交用于实施的任何必需的配置项 (CI) 变更。 当测试表明某个建议的解决方案无效时，调查和诊断流程应该继续，直至确定成功的解决方案。如果测试成功，就可以在解决和恢复流程中推进该解决方案。 在事件调查和诊断期间的任何时候，宣布一个重大事件可能是必要的。重大事件具有高度影响或潜在的高度影响的事件，这样的事件需要的响应超出为“常规”事件所提供的响应。通常，这些事件需要整个公司的协调、管理上报、动员附加资源和加强沟通。虽然某个事件在最初检测时可能被怀疑是“重大”的，但是支持团队需要在开始重大事件过程之前确认该事件的范围和影响。应该使用高优先级记录怀疑的重大事件并通知相关的问题解决小组，以便他们能够尽快确认范围和影响。 组织应该编制用于标识重大事件的标准 — 例如，零售银行可能决定影响 20 个以上的分理处的正常服务的事件应该分类为重大事件。然后应该向值班事件经理标记怀疑的重大事件，该经理负责根据证据并在咨询相关各方之后决定是否开始重大事件过程。 在重大事件期间，调查、诊断、解决、恢复然后终结的流程仍然会继续。但是，重大事件过程监督这些活动并提供增强的协调、资源和沟通。 如果事件不是重大事件，可能仍然需要某种形式的上报。上报是协助事件在议定的服务指标内得到解决的机制。存在两种形式的上报：管理（或分层）上报和功能上报。 如果认为事件无法满意或及时解决地，管理（或分层）上报可以在事件生命周期中的任何阶段执行。一旦发现无法实现满意或及时的解决方案就立即将事件上报管理是服务台中的职员的职责。上报应该尽早开始，以便管理仍有时间评估情况并实施更正操作。更正操作可能是分配附加资源或从其他地方寻求专门技能（或者在组织内或者在组织外）。 还应该在事件的整个生命周期中考虑功能上报。功能上报涉及将事件转移到不同的支持团队，他们配备有更好的资源以推进事件并在议定的服务指标内实现解决方案。在分层的支持结构中，这可能涉及将事件从二级小组移交到三级小组；而在基于平台的结构中，这可能是分配给小组中更资深的人员或分配给不同的小组，因为事件类别与最初认为的类别不同。功能上报还包括将事件上报到外部支持资源和供应商。 所有上报操作都应该在事件记录上进行记录。 技术说明服务台工具允许根据所花的时间和到达服务指标的剩余时间进行自动上报。在需要仔细计划上报时间以便不会超出服务级别指标的同时，又需要为较低层的支持提供合理的时间以解决事件，从而减少对更昂贵的“较高层”资源的影响。 组织可以决定根据时间因素实施自动管理和功能上报。自动操作在许多情况下可能只是涉及通知相关人员关于特定事件的上报已到达，以便他们能够采取适当的操作。当事件处于某些状态时，工具可以允许“上报时钟”停止 — 例如“等待证据”，其中支持团队已要求进一步的证据，并正在等待联系人提供证据；或“已解决”，其中事件被认为已解决，但是服务台分析员正在终结事件之前等待发起者确认解决方案。在进度正在等待发起者的这些情况下，可以停止“上报时钟”。然而，事件经理应该执行监视以确保支持团队没有通过请求进一步的、难以获取的证据消磨时间，从而增加他们调查问题所必需的时间。 重大事件过程。重大事件过程在如下情况下提供附加的跨公司协调、资源、管理参与和沟通：即这些情况下的事件影响或潜在影响使得超出常规事件管理流程所提供的响应变得必要。 关于事件是否足以调用重大事件过程的决定取决于值班事件经理，虽然应该在做出决定之前咨询涉及到的所有各方。可能需要联系事件中涉及的支持团队、服务经理、业务经理、合作伙伴和其他 IT 经理，以确保值班事件经理完全了解所处的情形和潜在的牵连。 组织应该编制许多标准作为决定什么事件应该被视为重大事件的指导原则。标准将特定于业务，但是可能涉及： 财务影响。潜在影响可能超出规定数据的任何事件。基于服务。关键业务服务的任何停用，其中快速的解决方案可能不会出现。基于站点或用户。不只影响指定数量的站点或用户的任何事件，其中快速的解决方案可能不会出现。基于指标。可能导致违背特定的服务级别指标的任何事件，尤其是可能导致重大财务损失的情况。基于健康或安全。认为在达到解决之前健康和安全直接面临风险的任何事件。基于安全性。认为已经蒙受重大损失或影响的任何安全事件，或已经保暴露重大缺陷的情况。基于声誉。需要迅速和/或有效地响应才能维持或最小化对组织或品牌声誉的影响的任何事件。 这些标准需要确保在面临严重业务影响的威胁时调用重大事件过程，同时防止在不需要这种响应级别时进行过多不必要和成本昂贵的调用。这些标准只应该用作指引；是否调用该流程取决于值班事件经理的判断。值班事件经理应该根据灵活的常识性方法作出决定，并考虑事件的独特特征和确保将事件标记为重大事件的标准不致太严格。调用重大事件过程通常会有中断影响和动员额外资源的成本，因此必须谨慎以确保仅在严格必要时才使用它。 组织中的任何人都应该能够就他或她认为现在应被视为重大事件的事件联系值班事件经理。虽然这种联系在许多情况下来自于服务台或问题解决小组，当时没有理由阻止诸如服务经理或业务经理（他们通常经了解潜在的影响）等其他职员联系事件经理。为了确保这成为可能，需要将重大事件过程与联系值班事件经理的方法一起公布。 如果事件经理决定某个事件当前不足以调用重大事件过程，则需要向涉及的各方说明理由，然后需要在正常推进事件时对情况进行监视。一旦向值班事件经理标记了某个事件，即使认为它当前不是重大事件，事件经理仍然应该继续定期监视该事件，以防情况发生变化。 一旦确定某个事件时重大事件，事件经理应该立即通知涉及的所有各方：问题管理、可用性管理、服务级别管理、服务连续性管理、IT 管理、受影响的业务经理以及值班服务台经理。 必须有人承担重大事件经理的角色，负责在重大事件期间协调计划、资源和沟通。取决于组织的规模、潜在的影响和威胁以及遇到的重大事件的数量，这可能是个永久性的职位或在需要时由适当的职员担当的职位。在为多个客户提供支持的服务组织中，可能存在对多个永久性的重大事件经理的需要。如果要昼夜不停地处理事件，则可能需要向单个事件分配多个重大事件经理。 如果重大事件经理的角色将是兼职的，那么取决于组织，该职位可由问题经理、可用性经理或服务经理担当。 扮演重大事件经理角色的职员需要满足下列条件：
一旦指派了重大事件经理，他或她就应该收集到目前为止可用的所有信息，并确认当前状况。然后重大事件经理将负责组建恢复小组。 调查和解决重大事件所涉及的技术团队称为“恢复小组”。该小组通常包含一个或多个技术人员。取决于组织的规模和性质，可能有技术人员长久地“待命”，等待响应重大事件。如果是这样，这些人员应该是同时经过技能培训和问题解决技术培训的资深职员。这个核心小组应该接受使用中的所有关键战略技术的培训，当时如果特定事件要求不同的技能，可以由其他支持人员提供补充。资深支持人员应该在临时分配的基础上在整个核心小组中轮流。 如果资源不允许维持“待命”的核心小组，或者如果重大事件的数量和可能性不足以进行这项投资，则需要在识别出重大事件时由重大事件经理组建“按需”恢复小组。 重大事件经理应该主持一次与恢复小组、已经参与处理事件的任何团队成员、受影响的经理和其他任何相关技术专家进行的初始计划会议。如果职员在地理上分散，该会议可以采用电话会议或视频会议的形式。该会议的目标应该是同时就恢复计划和沟通计划达成一致。 恢复计划的目标是提供用于服务恢复的有计划和协调的方法。该计划应该由重大事件经理所有，并且应该对需要采取的操作、谁应该执行操作以及应该在何时完成操作等事项进行文档记录。应该在重大事件的整个生命周期中定期更新该计划，确保保留旧版本以用于审核目的。 恢复计划应该包含以下内容：
本文档的附录 E 中包括一个示例恢复计划模板。 重大事件经理应该与包含 IT 经理、受影响的业务经理和合作伙伴以及客户管理的管理小组一起定期复查进度。管理小组会议的目的应该是向所有各方通气，讨论进度，并在需要时提供管理上报。在主持管理审查会议之后，应该同意并签发进度更新声明。 管理小组和恢复小组审查会议通常应该保持独立，以便每个小组集中于与他们的角色相关的问题。恢复小组应该讨论技术问题，然后为管理小组提供进度报告，后者然后可以集中于资源、上报和沟通问题。这些会议保持独立最小化了个人花在会议中（而不是实际花在解决事件上）的时间，同时还允许每个小组集中于他们自己的讨论。 在重大事件期间，沟通的处理本身经常变得非常困难。沟通计划的目标应该是在事件生命周期中提供所有沟通的协调。沟通计划应该由重大事件经理所有，并在每次管理小组审查会议时讨论和更新。该计划应该包括：
应该开发一个模板沟通计划和适当的电子邮件分发列表以便在重大事件期间使用；但是，还必须注意在特定媒体（例如电子邮件）不可用的情况下的备用沟通方法。 本文档的附录 E 中包括一个示例沟通计划矩阵。 一旦同意了沟通计划和恢复计划，则应该分配任何需要的附加资源。所有资源都应该能够访问恢复计划，以便他们能够看到截止目前已完成的操作和他们以及其他资源现在应该做的操作。 重大事件经理应该确保支持人员的任何必要的旅行安排得到批准。 一旦重大事件过程已在进行中，计划已得到同意，资源已完成分配，就应该遵循调查、诊断、解决、恢复和终结的标准事件生命周期。重大事件的不同之处在于事件由重大事件经理所有并紧密协调，并在整个事件生命周期中定期审查和维护恢复和协调计划。 恢复小组应该以定期间隔支持审查会议以讨论进度、更新恢复计划并签发恢复小组进度报告。重大事件经理可以出席这其中某些审查会议，但是不一定要全部出席。审查会议之间的间隔视发生的活动量而定。例如，在调查的紧张阶段，该会议应该比职员只是等待确认解决操作成功时的后续阶段更加频繁。 还应该主持定期的管理小组会议以便向所有各方通气、讨论进度，并决定何时需要管理上报。重大事件经理应该出席所有管理小组进度会议。同样，审查会议之间的间隔应该视活动量而定。 在重大事件期间执行管理上报可能变得必要。随着事件变得更加关键，随着管理上报在合作伙伴和客户中的进行，沿管理链往上上报事件情况是必要的。这样可以避免诸如高级经理或主管首先从合作伙伴或客户组织的同行那里了解到事件的情况。 沟通计划应该随着管理上报或恢复小组成员变更而更新。重大事件经理负责在发布之前同意或获得所有沟通更新陈述的协议。 随着重大事件的推进，重大事件经理应该确保定位、分配和协调任何附加资源要求。 有些重大事件可能使得调用组织的业务连续性和服务连续性计划变得必要。必须考虑到重大事件过程和服务连续性计划如何合作以及职责如何划分。在重大事件期间，重大事件经理应该决定何时以及是否应该调用服务连续性计划，以便恢复服务或保留恶意企图情况下的证据。通常，重大事件经理应该继续负责协调恢复操作、沟通和诸如收集证据和实施临时变通办法等活动。 取决于规模和需要，组织可以为处理重大事件进行不同级别的准备。人事问题（例如是否有全职的重大事件经理和“待命”的核心恢复小组）已经提到过了，但是有些组织可能额外准备专用的“战备房间”，其中配备了个人计算机、通信设备和白板。许多组织认识到关于他们如何处理重大事件的公众意识与他们如何处理媒体直接相关，于是投资于培训以确保发言人和高级管理人员能够“应付媒体”。显而易见，投资于处理重大事件的准备工作的合理性取决于组织的规模和组织的经营条件，但是每个组织都应该仔细考虑可能出现的潜在影响以及它们对组织、职员和客户意味着什么，同时还要认识到重大事件迟早会发生。这不是“假设”，而只是“时间”问题。 重大事件过程应该继续伴随常规事件管理流程，直至重大事件终结。在事件的最后阶段，当已经采取解决操作时，解除恢复小组的部分任务也许是可能的，不过要了解到如果解决方案被证明不成功，他们将被重新召集。 在重大事件终结时，应该通知问题管理，因为执行重大事件后的审查是他们的职责。 技术说明负责响应重大事件的职员需要有相应的装备。沟通通常是困难的，因为职员在远程站点工作并且要在旅行中花时间。移动通信技术是确保职员保持联络所必需的，并且能够检索至关重要的、通常是快速变化的信息。 为了帮助沟通计划，可以设置用于电子邮件和文本消息的分发列表。诸如数字显示牌、闭路电视和室内无线广播系统等设施可用于为所有坐办公室的职员提供关于重大事件的信息。 支持团队可能需要在远程工作时查看和更新事件记录。应该部署允许通过浏览器或电子邮件远程查看和更新事件的服务台工具。必须采取一些步骤，确保这卸系统的安全。 处理重大事件的重大事件经理和其他职员需要能够从他们所在的任何位置同时访问沟通计划和恢复计划。可以使用允许授权职员进行远程浏览器访问的门户解决方案提供该信息。 解决和恢复解决和恢复流程负责确保按照变更和发布管理流程实施任何已确定的变通办法或解决方案，并确保采取任何附加恢复操作。 解决操作是解决事件的直接原因所需要采取的操作，例如替换故障硬盘或向数据库应用程序安装热修复以防止表损坏。 恢复操作是在完成解决操作并且所有组件都恢复正常工作秩序之后仍然需要采取的操作。在故障硬盘的情况下，解决操作是替换磁盘，它解决事件的原因。但是，仍然需要还原磁盘内容的恢复操作。在数据库应用程序的情况下，应用热修复是解决事件的解决操作；但是，仍然需要恢复操作以便将数据回滚到某个一致点并重新启动数据库服务。取决于具体的事件，解决和恢复操作可能需要由不同的小组执行。 事件可能由于在调查和诊断阶段中确定的变通办法或解决方案，或者由于问题管理找到了与一个或多个未完成的事件关联的问题的变通办法或解决方案，而到达解决和恢复阶段。在后一种情况下，问题管理负责确定和测试问题变通办法或解决方案，然后将详细信息通知事件管理。然后事件管理负责实施与该问题关联的所有事件的解决、恢复和终结。 一旦确定了解决操作，事件管理职员通常需要配合变更管理流程，实施解决事件所需要的任何变更。这样确保对变更进行正确的测试和文档记录，并确保考虑到撤消计划。事件管理应该通过变更和发布管理流程监视解决操作的进度。 有些事件可能无需引发 RFC 就能得到解决。当事件由“人为错误”或没有正确遵循过程所导致时，通常还有一些程序性问题。 一旦完成解决操作的执行，事件管理将负责确认解决操作的成功。如果没有成功，应该检查的第一件事情就是验证是否所有变更都已正确地实施。如果发现变更没有正确地实施，则应该使用变更管理流程撤消失败的变更并计划新的实施。 如果所有 RFC 都已正确地实施，但是事件仍未解决，则应该将事件传回调查和诊断流程。事件管理职员应该决定是否需要使用变更管理流程撤消已实施的变更。在许多情况下，已实施的变更可能不需要撤消，因为它们本身就是有益的。例如，可以执行最新服务包的安装以试验和解决特定事件。如果该操作未解决特定事件，保留最新的服务包仍然是合理的，因为这样应该会解决或防止其他事件。 一旦解决操作已成功实施，则应该执行任何恢复操作。这些恢复操作经常涉及在解决导致事件的问题之后使服务重新对用户可用。恢复操作应该执行至正常服务已得到恢复的状态。 如果当前事件被视为重大事件，则重大事件过程应该继续伴随解决和恢复流程，从而提供增强的协调、沟通和计划水平。 在执行解决和恢复操作之后，应该将事件记录置于“已解决”状态，并将其分配给负责与发起者确认解决方案的服务台分析员。 技术说明集成的服务管理工具集允许配置管理数据库 (CMDB) 与服务请求、事件记录、问题记录、已知错误、服务级别指标和 RFC 的集成，为组织提供了用于支持他们在服务管理流程方面的投资的重要工具。 这些工具提供的集成级别允许实现服务管理的全部好处。虽然 MOF SMF 可以独立实施，但是通过更广泛的实施，并引入一组相互支持和加强的完整的流程，能够更全面地实现其优点。 这些工具还允许事件管理团队引发与事件记录链接或关联的 RFC，从而允许通过单一界面跟踪进度，而不必登录多个应用程序并重新输入基本信息。 终结事件管理流程的终结阶段负责与发起者确认事件已得到解决，确保对事件的详细信息和解决方案进行记录，并对终结归类然后关闭事件记录。 终结事件是服务台分析员的职责。一旦事件得到解决，问题解决小组应该将事件记录状态更新为“已解决”，然后将记录传回服务台小组。 服务台分析员应该确保事件记录已使用在整个事件生命周期中采取的操作的详细信息来填充。在认为信息缺乏或不清楚的地方，服务台分析员应该联系相关问题解决小组以便获得更新。在适用的情况下，服务台分析员应该检查收费细节（例如成本中心）和花在事件上的时间量已在事件记录上进行记录。 如果认为该事件可能再次发生或者已经发生多次，但是没有对应的问题或已知错误记录，则服务台分析员应该联系问题管理以请求创建一个记录。问题管理应该考虑该请求，并创建一个新记录或解释当前不需要这样一个记录的原因。 服务台分析员还应该确保已将事件分配到某个终结类别。该终结类别应该反映事件的直接原因。所使用的实际终结类别应该与问题管理达成一致，并在足够的详细级别上创建，以便能够获得有用的指标和报告。例如，如果存在一个“错误配置”终结类别，并且据报告，上个月有 50 个事件是由此类别导致的，则问题管理就没有多少可依据的内容了。但是，如果进一步细分此终结类别以显示“错误 PC 配置”、“错误服务器配置”、“错误帐户配置”、“错误网络配置”等，则信息将更加有用。问题管理现在也许能够看到 50 个事件中的 45 个是由错误的帐户配置导致的，从而为他们提供了识别根源的更好起点。 技术说明可以配置服务台工具向更新事件记录的职员提供可能的终结类别的列表。终结类别字段应该是必填的，以确保在终结之前选择某个终结类别。 终结类别的列表保持全面并得到很好的维护是至关重要的。如果职员无法找到与他们正在处理的事件匹配的类别，他们很可能养成选择一个随机类别以便能够终结该事件的习惯。由于这个原因，不应该为终结类别字段提供默认值。可以设置一个“无相关类别”终结类别，为职员在无法找到与事件匹配的类别时为他们提供一个选择。为避免此类别被当作通用类别，应该严格追踪其使用实例。可以为事件经理和问题管理职员自动生成定期报告，其中显示选择了“无相关类别”的实例。每个实例都应该进行调查，并采取适当的操作以设置新类别或将原本应该使用的终结类别通知相关职员。 应该对这种情况进行监视以确保正确使用终结类别。 最后，服务台功能应充当“独立”检查，以检验发起者对接收到的支持感到满意并同意事件已解决。该检查可以防止如下情况发生：即发起者请求检查仍在影响他们的事件的进度，却被告知该事件已经由于支持职员认为已解决而终结。这些情况不仅使支持组织难堪，而且还对客户满意度产生很坏的影响。 服务台分析员应该监视正在被置于“已解决”状态的事件，然后联系发起者以确认解决方案。取决于正在处理的事件的数量，该检查可通过电话或电子邮件进行。通常可以使用两者的组合 — 电话用于高优先级事件或敏感服务，而电子邮件用于标准的日常事件或难于通过电话联系的用户。 技术说明一旦完成解决和恢复操作，就应该将事件记录置于“已解决”状态。 可以配置工具在将事件置于“已解决”状态之后自动向事件发起者发送电子邮件（使用标准电子邮件模板）。该电子邮件应该包含事件参考号、登记日期和时间的详细信息以及对最初记录的事件症状的简要说明。该电子邮件应该解释事件现在被认为已解决，但是如果不是这样或者发起者对解决方案不满意，他或她可以回复电子邮件或通过电话联系服务台。该电子邮件应该声明：如果在一段时间内（或许是数周以涵盖发起者正在休假的情况 — 举例而言）未收到任何答复，则该事件将被终结。如果在指定的时间段结束时未收到任何答复，工具应该自动终结事件。 工具应该自动将已标记为重大事件的任何事件通知问题管理。这可以通过电子邮件轻松地完成。 在发起者报告事件未得到满意解决的情况下，服务台分析员应该更新事件记录，包括优先级（如果现在已不同），然后将事件重新分配给问题解决小组或上报该事件。可能存在支持团队已经竭尽所能地利用当前资源，但是发起者仍然对结果不满意的情况。性能问题就是这方面的典型例子 — 发起者对所获得的响应时间不满意，但是支持团队已做的任何调整措施收效甚微或没有效果，因为瓶颈是当前网络基础结构，需要重大投资才能改进它。在这种情况下，将事件传回问题解决小组没有多大意义，服务台分析员应该将事件上报到负责的服务经理（如果有）或直接上报到问题管理。显然，在这种情况下，具有针对响应时间的议定服务指标将能提供帮助 — 只要已在达成一致之前正确确定它们的可实现性。 在重大事件的情况下，重大事件过程应该与终结过程并行进行，从而确保增强的协调、沟通和计划级别。应该在终结重大事件时通知问题管理，因为执行审查以便同时确定根源和是否能够以不同的方式处理该事件是他们的职责。问题管理应该寻求确定如何防止该事件或类似的事件再次发生。 角色与职责事件管理的主要角色和他们的关联职责已按照行业最佳实践进行定义。依据具体的规模、结构以及 IT 部门与其上级企业间的基础服务级别协议，组织可能需要整合一些角色。 请记住这些是角色，不是作业描述，这一点很重要。 事件管理流程所需的角色有：
事件经理事件经理的角色包括事件管理流程的端对端所有权的职责，以确保按照优先级状态一致地推进所有事件。否则，各个问题解决小组可能按照他们自己的优先级工作，从而导致成本昂贵和低效的支持工程。在不存在端对端可见性和职责的情况下，组织最终可能让每个支持层按照他们自己的优先级代码集和目标解决时间工作，而没有关于如何处理、更新或上报事件的指导结构。通常，这样会导致小组之间的争议，从而导致降低客户满意度和增加成本和职员沮丧心理。 在许多组织中，事件经理和服务台经理角色由同一个人承担。通常向该角色分配负责管理一级或一级和二级支持小组的职位。 为了在需要时上报事件，事件经理在服务时间内应该始终在位。在关键事件期间，事件经理负责决定是否要调用重大事件过程。 事件经理还应该负责监视事件管理工程的绩效，并寻求不断地改进该流程。 表 7 事件经理职责
服务台分析员服务台分析员负责事件管理流程中的许多任务。在事件生命周期的初始阶段中，他们负责确保对事件进行正确的记录、分类并提供初始支持。在初始支持期间，他们负责在时间允许的范围内，尽可能解决最多的事件。他们在这个阶段的行为将直接影响到客户的满意度，而且将决定剩下的支持链处理事件的具体方式。 服务台分析员负责将未在初始支持流程中解决的事件分配给问题解决小组。但是他们的职责并非到此为止，他们应该保留事件的所有权，仍然负责确保按照服务级别指标继续推进和上报事件。 该分析员负责在整个事件生命期中向客户提供进度更新。 一旦事件得到解决，分析员应该在终结事件记录之前确认发起者对事件解决方案感到满意。 表 8 服务台分析员职责
服务台分析员的角色将在“服务台 SMF”中进一步描述。 重大事件经理重大事件经理的角色在发生重大事件期间很关键。当重大事件发生时，应该立即向该事件分配重大事件经理。从此时起直至事件终结，重大事件经理负责确保协调的跨公司反应、向恢复小组分配资源、管理上报以及与涉及到的所有各方的沟通管理。 重大事件经理负责确保同时产生恢复计划和沟通计划，并在整个事件过程中维护它们。 该角色需要由深入了解组织运作并具有做出决定的政治权力的高级管理人员担任。该角色涉及与客户的许多交互，并且可能经常充满压力。它同时需要在压力下工作的能力和与内部 IT 及所有级别的组织职员以及外部合作伙伴和客户沟通的能力。 需要的重大事件经理的数量以及他们的职务是全职还是兼职取决于组织的规模和性质。应该考察历史重大事件作为起点：解决重大事件所花的时间、发生重大事件的频度、位置、同时发生的数量以及是否要昼夜不停地解决。 表 7 重大事件经理职责
支持技术员Microsoft 操作框架将 IT 环境划分为一组层级：每个层级都依靠一个坚实的基础，以便有效运作。对于 IT 部门，具体的层级有：
每个层级都有一个支持技术员角色，负责在该层级遇到事件的任何时候参与问题解决小组。他们还积极识别问题和已知错误。 IT 组织中的许多团队可能会解决各种问题及已知的错误。这些“问题解决小组”应该在问题管理工具中分别有一个队列，需要他们的专业知识的问题将分配到该队列。并非所有问题解决小组都是“技术”小组，但是他们全都可看作是执行某种形式的专家支持功能。“非技术”问题解决小组的示例可能是负责培训、处理 RFC 或处理针对议定的服务级别的变更请求的专家或小组。这些团队中的成员担当着专家支持角色。专家支持团队不一定非得是内部队伍，因为外部供应商也可能组成许多问题解决小组。 担任问题支持角色的团队成员不大可能具备涉及 IT 基础结构方方面面的深层知识，尤其因为新技术层出不穷。担任专家支持角色的成员负责提供专家知识，以协助调查和解决问题所涉及的问题管理。 确定了具体的解决措施后，专家支持团队应在变更和发布管理流程的控制下，执行这些措施。一旦解决完毕，他们就应更新问题记录，并传回给问题支持团队以终结问题解决过程。 专家支持团队还应努力识别基础问题，并就有关问题发出问题管理通知。 表 8 支持技术员职责
与其他流程的关系服务台服务台充当许多 IT 流程的初始入口，包括事件管理流程。对于许多其他 IT 流程，服务台只是向它们传递请求；但是对于事件管理流程，服务台和事件管理流程之间的联系要紧密得多。 服务台充当业务和 IT 之间的接口，在此处是充当业务和事件管理流程之间的接口。 服务台经理负责事件管理流程的日常协调。服务台执行记录、分类和事件管理的初始支持阶段。然后，当事件分配到问题解决小组时，服务台通过监视和跟踪所有事件保留所有权职责。 如果服务台运作成功，则许多服务请求和事件可以得到处理和解决而无需越过服务台功能之外。 就事件管理流程的客户满意度而言，服务台是一个关键组件。 问题管理事件与问题管理关系密切，但是在支持组织内，各自的侧重点却大相径庭。 事件管理关注尽可能快地还原常规服务，而问题管理却侧重于识别并解决基础问题及其根本原因。 事件管理为问题管理提供识别根本问题的存在性所需要的许多信息。问题管理会分析事件统计数字，从而识别所发生的多个事件或特定类型的事件的增长趋势。 相应地，问题管理寻求解决这些事件的根本原因以防止它们再次发生。 问题管理还会维护有关现有问题和已知错误的信息，包括已知的应对方案和解决办法。事件管理利用该信息提供更快的事件解决。 问题管理还负责在主要事件得到解决后，对其进行审查。在这些审查期间，目标是识别根本原因根源以便防止任何事件重现，识别可用于对任何事件重现给出提前警告的触发因素，以及识别事件的解决质量以便改进今后的反应。 变更管理当事件管理识别出需要配置项变更的解决操作时，这些变更将在变更管理流程的控制下进行部署。 变更管理流程提供的控制可减少所需撤销的更变数量，并能确保在需要时，记录有关的撤销计划。协调的变更测试减少了由变更部署导致的后续事件的机会。 变更管理还为事件管理提供关于最近的变更、受影响的配置项和变更原因的有用信息。 配置管理配置管理提供在整个事件管理流程中使用的至关重要的信息。配置管理数据库 (CMDB) 包含可用于以下用途的信息：
|
