An incident is a help desk call, an issue that you have logged and needs to be fixed immediately or not as the case may be. Each incident will fit within a category of importance, that is how important the call is within the support matrix. This is to ensure that when Mike a derivatives trader screams that his computer is broken, a priority call is logged, but not at the level where all of IT and Business management get a text message saying “Mike’s pc is slow..”.

With that in mind therefore you log a call with the priority that you see fit.

But let’s go through and example where this can cause an issue: LONS484929 is a SQL cluster comprising of A node (live) and B node (backup in our bcp site). LONS484929b failed, it bluescreened, rebooted and left the cluster, meaning for the duration of the outage, there was no bcp functionality, had the A node failed we would have lost service.

With high priority incidents, like say a system failure, the intranet went offline kind of thing, an incident report might be issued stating what happened, who was involved in the resolution, what the fix, the long term strategy to avoid it happening again etc.

Is this an Incident Report? There was no direct impact to the user, granted there was an element of risk, albeit limited, do I issue a report? To answer this you need to look at your own procedures, how your work determines an incident, as well as report – my view? If Mike wants an incident report on his pc he can have one, however, it is normally the kind of thing a business line, an application team want as a line of defense, the interest to the end user is typically marginal, I don’t want a report, just fix it and tell me when its working.




No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Bookmark and Share

Leave a Reply