Request priorities

Print Friendly, PDF & Email

I read an article this morning by Tom Limomcelli entitled “A System Administration Parable: The Waitress and the Walter Glass“. In this article it suggests that it would be a good idea to have a policy on what defines an Emergency. I thought this would be a good idea for us to have. As Systems Administration is largely interrupt driven this will help me and you the customer to understand when I will drop what I am doing to focus on the “Emergency”. I have over the years had some idea of what constitutes an emergency when it comes to services so perhaps it’s time to write it down.

In addition to this, as I use Request Tracker for a large proportion of work I do, in the 5 main types of request that I receive there are varying levels of priority and statuses set depending on the priority rules. Below I have attempted to list those properties which constitute a higher and lower priority.

General high priority rules

  1. A service outage which is affecting X people.
  2. A problem which has been reported by more than X people.
  3. A service outage which is putting important, sensitive or personal data integrity at risk.
  4. A service outage which is preventing X people from being able to do their job.
  5. A security threat which could contravene UK law or UoB policy.

X varies depending on the severity of the problem.

General low priority rules

For outages these 2 criteria may affect the priority:

  1. Nature of the support contract for the service which is affected by an outage.
  2. The service is considered low priority out-of-hours (depending on time zones).

Other general criteria

Timeliness of the request

If the request is made on the last day before a deadline for example it may not necessarily be considered a high priority. I will endeavour to do my best to help you as long as no other higher priority tasks exist at that time (such as leaving the office ;-)). Make sure at the project planning stage that all resources are considered well ahead of time and include me in the planning discussions where possible. Also, just giving me a “heads up” doesn’t magically give me the insights on what the project may require. So talk to me as early as possible, even if it’s to confirm you won’t need me.

Management override

I will generally obey my master in most situations, that is not to say that I will not argue my case that a task may not meet my emergency status criteria. Negation of a rule may occur if there is a business or political ramifications that I am not fully aware of.

Request Types

These are the classifications (loosely stolen from ITIL) I assign to requests in order of highest priority. These are normally logged in a custom field in RT tickets.

Emergency Change

This is when a change request meets more than one high priority rules. Because it is a change request, this means that to fix the problem, a change to how things work currently has to occur. For example, a configuration aspect is causing a web page to be unavailable, I may need to remove that aspect to rectify the problem.

Emergency Incident

An incident is similar to an Emergency Change but in this case we are experiencing a problem that under normal circumstances operates correctly. No change to the functionality or configuration is necessary to rectify the problem. I may also assign this status before I realise a change is required. I.e. a network cable is unplugged and the internet is broken.

Normal Incident

This type is similar to the Emergency Incident but does not necessarily mean that the request has been given a high priority. This may be given to something which is not dependant on a change but also does not hit the high priority criteria. A “Normal Incident” in is synonymous with a Request_Type of “Incident” in RT.

Normal Change

A normal change is a change request which would have potential ramifications for associated services or components. If not considered it may escalate into an Emergency Change to rectify the problem. Normal Changes in the context of ITIL would normally be passed to a Change Advisory Bureau (CAB). The CAB would look at the request and base a decision on whether the request is authorised and also whether it can be further classified as a Standard Change. In most cases (at this time) I am the CAB. For planned services outages I will usually consult with the service manager for a project or service before taking action, in which case the request will need to be authorised before it can be actioned. Normally this is given a higher priority due to the amount of time that may be involved in making the decision.

Standard Change

This is a change which has passed through the Normal Change and the CAB process, and has been marked as a change which can be made automatically. These sorts of requests in the context of a team of Systems Administrators would be a good candidate for delegation. It may also be considered for automation or devolution in the form of a self-help service. It holds a fairly level priority so may not be completed quickly, therefore; it would help to provide a time/date which the change would be needed by. I may also batch these sorts of requests together, e.g. perform project creation tasks on a particular day of the week.

Service Request

A service request is normally given to anything which has a system in place for automation (e.g. a service desk or control panel) to aid the task or where the requestor(sic) has already got permission or devolved responsibility to do it themselves but just needs a little help. These tasks will normally be given the lowest priority depending on other tasks and may sometimes be rejected with a RTFM response. ;-)

If I’ve missed anything let me know.