incident160management(编辑修改稿)

incident160management(编辑修改稿)内容摘要：

cidents and service requests are processed consistently and that none are lost.  To direct support resources where most required.  To provide information that allows support processes to be optimized, the number of incidents to be reduced, and management planning to be carried out. 6 Incident Management Scope Incident management handles all detected incidents and all service requests that can be raised through the service desk. ITIL defines an incident as: Any event that is not part of the standard operation of a service that causes, or may cause, an interruption to, or a reduction in, the quality of service. Typical incidents could include:  A service being unavailable.  Software corruption.  A hardware failure.  The detection of a virus. The range of different service requests received by the IT anization varies between different anizations. Common service requests can include:  Requests for change (RFCs).  Requests for information (RFIs).  Procurement requests.  Batch job requests for a specific purpose.  Service extension requests.  Password resets. Depending on the size and structure of the anization, some of these requests will be wholly processed by the service desk, while others will be handled by processes within other SMFs or other parts of the anization. In the latter case, the incident management process acts as an interface to the relevant process. An example of this is an RFC that might be passed to the change management process. Key Definitions The following are key terms within the incident management process: Incident. Any event that is not part of the standard operation of a service and causes, or may cause, an interruption to, or a reduction in, the quality of service. Initial support team. The team that provides the very first line of support for processing incidents and service requests. The initial support staff is responsible for trying to resolve incidents at first contact—by identifying known workarounds, using diagnostic scripts, or their own knowledge. In many anizations, the service desk acts as the initial support team. Known error. An incident or problem for which the root cause is known and a temporary workaround or a permanent alternative has been identified. If a business case exists, an RFC will be raised, but—in any event—it remains a known error unless it is permanently fixed by a change. Major incident. An incident with a high impact, or potentially high impact, which requires a response that is above and beyond that given to normal incidents. Typically, these incidents require crosspany coordination, management escalation, the mobilization of additional resources, and increased munications. Problem. The undiagnosed root cause of one or more incidents. Service Management Function 7 Resolver groups. Specialist teams that work to resolve incidents and service requests that initial support cannot resolve themselves. Support team structures vary between anizations, with some using a tiered structure (second, third, and so forth), while others use platform or applicationoriented teams (mainframe team, desktop team, work team, or database team). Service desk. A function that provides the vital daytoday contact point between customers, users, IT services, and thirdparty anizations. The service desk not only coordinates the incident management process, but also provides an interface into many other IT processes. Service request. Requests for new or altered service. The types of service requests vary between anizations, but mon ones include requests for change (RFC), requests for information (RFI), procurement requests, and service extensions. Solution. Also known as a permanent fix. An identified means of resolving an incident or problem that provides a resolution of the underlying cause. Workaround. An identified means of resolving a particular incident, which allows normal service to be resumed, but does not actually resolve the underlying cause that led to the incident in the first place. 4 Processes and Activities The following figure shows the incident life cycle from the initial occurrence through to closure of the incident following confirmation that the issue has been resolved. Detectedandreco rde dClassifiedInve sti gat edanddiagnosedResolve dandreco vere dClosedIn ciden toccursNormal s ervic eresumedEnd to end owne rship, track ing, and monitoring Figure 1. The incident life cycle A fundamental concept within incident management is the endtoend ownership, tracking, and monitoring of incidents. The service desk effectively owns all of the incidents and is responsible for monitoring their progress towards resolution. The service desk should frequently update the incident records (so that progress can be tracked) and inform the users about the progress being made. Where it is believed that progress in resolving an incident has stalled, the service desk needs the authority to pursue and, if necessary, escalate the incident to ensure that resolution is achieved within service targets. Tools allow the service desk analysts to be automatically notified when incident records have not been updated for a certain period, which may indicate that the incident has stalled. Process Flow Summary Incident management can be graphically presented in the form of a process flow diagram, which identifies the activities needing to take place in order to ensure that IT incidents are being reacted to by the correct support resources, within the timescales required by the business. 10 Incident Management The following figure is a process flow for incident management. Detection , selfservice, andrecordingCla ssification andini tial supp ortInvestigation anddiagnosisResol ution andrecoveryClo sureNew incide ntsResolve d inc。