Resolution and Recovery

Investigation and Diagnosis

Note regarding Incident allocation

There may be many incidents in a queue with the same priority level – so it will be the job of the Service Desk and/or Incident Management staff initially, in conjunction with managers of the various support group s to which incidents are escalated, to decide the order in which incidents should be picked up and actively worked on. These managers must ensure that incidents are dealt with in true business priority order and that staff are not allowed to ‘cherry-pick’ the incidents they choose!

In the case of incidents where the user is just seeking information, the Service Desk should be able to provide this fairly quickly and resolve the service request – but if a fault is being reported, this is an incident and likely to require some degree of investigation and diagnosis.

Each of the support groups involved with the incident handling will investigate and diagnose what has gone wrong – and all such activities (including details of any actions taken to try to resolve or re-create the incident) should be fully documented in the incident record so that a complete historical record of all activities is maintained at all times.

Note: Valuable time can often be lost if investigation and diagnostic action (or indeed resolution or recovery actions) are performed serially. Where possible, such activities should be performed in parallel to reduce overall timescales – and support tools should be designed and/or selected to allow this. However, care should be taken to coordinate activities, particularly resolution or recovery activities, otherwise the actions of different groups may conflict or further complicate a resolution!

This investigation is likely to include such actions as:

• Establishing exactly what has gone wrong or being sought by the user
• Understanding the chronological order of event s
• Confirming the full impact of the incident, including the number and range of users affected
• Identifying any events that could have triggered the incident (e.g. a recent change, some user action?)
• Knowledge searches looking for previous occurrences by searching previous Incident / Problem Record s and/or Known Error Database s or manufacturers’/ supplier s’ Error Logs or Knowledge Databases.

When a potential resolution has been identified, this should be applied and tested. The specific actions to be undertaken and the people who will be involved in taking the recovery actions may vary, depending upon the nature of the fault – but could involve:

• Asking the user to undertake directed activities on their own desk top or remote equipment
• The Service Desk implementing the resolution either centrally (say, rebooting a server) or remotely using software to take control of the user’s desktop to diagnose and implement a resolution
• Specialist support group s being asked to implement specific recovery actions (e.g. Network Support reconfiguring a router)
• A third-party supplier or maintainer being asked to resolve the fault.

Even when a resolution has been found, sufficient testing must be performed to ensure that recovery action is complete and that the service has been fully restore d to the user(s).

NOTE: in some cases it may be necessary for two or more groups to take separate, though perhaps coordinated, recovery actions for an overall resolution to be implemented. In such cases Incident Management must coordinate the activities and liaise with all parties involved.

Regardless of the actions taken, or who does them, the Incident Record must be updated accordingly with all relevant information and details so that a full history is maintained.

The resolving group should pass the incident back to the Service Desk for closure action.

Дата добавления: 2014-12-23