Thursday, April 6, 2017

Template for creation of Runbooks

Purpose of Runbooks is to create a 'How-To' document. This type of document is very useful to be used as a documented process for resolving key or repeatable issues.



Document Name : Provide name of the document
Ticket# (If Any)  : Most of the issues have a ticket, or enhancement request. Any reference which 
                                 can be useful to tie back to a production issue
Created By : Author name
Creation Date : Date the resolution was documented

Issue Summary: Describe the problem statement in detail. Provide details about how or why the issue occurred. Additional details are if this was a user, process or system failure

Root Cause: Provide details about the root cause of the incident

Resolution: Provide detailed steps to arrive at a resolution. Add any supporting documents, SQL scripts as necessary.

Access Required: Provide details about the roles and access required to complete these steps

Navigation steps: Provide step-by-step resolution, including necessary screenshots. Also provide necessary do’s and don’ts, if applicable. E.g.check for any conditions or error messages

Sunday, October 16, 2016

Incident Intake and Management Process


Purpose: This process will help with intake and management of incidents assigned to various IT groups. It is intended as a guide to help IT provide enhanced service to their users (business and IT)
Incident Flow:

1.    Service Desk assigns ticket to a group based on type of issue
2.    Every team triages tickets daily. There may be a lead assigned in every team to triage the tickets, or everyone in the team does may review and assign.  Triage can be done twice, morning or afternoon, or as needed.
3.    Review the incident and make sure it is assigned correctly to you/ your group.  If not, follow the “Warm transfer” process defined below.
4.    Perform initial reach-back to the incident creator (user) to understand and confirm the issue and priority. Determine if this is a break-fix or enhancement. Setup expectation with the user regarding resolution effort and time (per SLA). Let the user know how to follow-up for status update – it is recommended that business users reach out to Service Desk for updates.
5.    Once incident is assigned to you, start making notes, from acceptance till resolution. While working on the incident, it is important update the incident status details. Incident status is added to the “Incident Details” area – do not add updates to “Incident Resolution” unless you are ready to close the ticket.
6.    Any resolution must be documented on the incident in the “Incident Resolution” field - make sure it is a non-technical summary – this information goes back to user when the ticket is closed.  Before closing the ticket, confirm with the user the incident is resolved
7.     “Warm transfer” must happen when assigning an incident to other support groups. This means making sure to add details about any initial analysis performed, and the reason for transfer.
o    If follow-up action is required from any other group (Ex: DBA) to resolve the issue, add a note stating what is needed and transfer to that group. It will also be useful to add what action you have taken so far.
o    “Warm transfer” includes the person the incident is being transferred to acknowledging they are taking ownership of the incident.
o    If incident is incorrectly assigned to you/your group, add a note and transfer to the correct group. If not clear which group to assign to, send it back to Service Desk group for review and correct re-assignment.