Importance Levels - A Simple Example

When you’re first introduced to an environment you’ll have the ever fun task of working out which machines should get the most time; and that order seldom matches which machines actually need the most attention. To help me prioritise I’ve worked out a simple importance rating system to show where I spend my time.

Below is a simplified version. I use it to assign a single importance number to each machine, and then I allocate a certain amount of time each day to work on the issues, requests and improvements I’ve got in my todo list for that level. When I’ve run out of time I move down a number and start working on anything related to machines rated at that importance. The amount of time I put aside for each level decreases as I work towards one.

5: Customer facing systems that generate revenue.

This is my no brainer. Pretty much everything is secondary to keeping the money coming in.

Examples: customer database, webservers and databases related to customer payments.

4: Internal Money Makers and Customer Visible Systems.

I normally put customer facing systems that don't make money in this bracket. An online presence and reputation for availability have been important to most of the companies I've worked at. It sounds horrible but it's a lot easier to save face and beg forgiveness from a five day internal outage than a one day external one; well, sorta. If you're a blogger watched company then this is even more important.

I also put internal money makers at importance 4. “Cash is king” should be true in all departments, including those where Sysadmins dwell. I’ve only ever had simultaneous problems with both types of importance four systems a couple of times. Each time had circumstances that made the priorities clear.

Examples: corporate website, company blog, invoicing systems, time-sheets at month end.

3: Systems that stop a number of staff working.

I typically put machines that don't directly contribute to the bottom line but are required for the company to continue in this bracket. A short outage of any machines at this level can be survived for a little while but it'll slow a lot of staff down, cause frustration and (after a while) cause major damage.

Examples: internal request tracking/ticketing, bug tracking, build machines, version control

2: Systems that hinder small numbers of staff.

This is another level that I use to cover two types of machine. The first type slows or hinders a number of staff but can be lived without. You can think of these as convenience or favour systems that make tasks easier or more pleasant. You'll often get a disproportionate amount of queries when one of these goes down. This is a good sign and shows you understand what your users care about.

When I’m asked to help with desktop support I lump single user problems here. Although it’s frustrating to have a single person unable to work it’s often not as bad as any of the higher levels. I put a lot of special cases and caveats here (sales people on presentation days, QA engineers before a release) but the most sensible workaround is to separate desktop and sysadmin roles. You can typically hire desktop support staff cheaper than a sysadmin and give them the opportunity to train with the sysadmins when things are quiet.

Examples: Web front-end to a version control server, centralised log shares for debugging, departmental wikis, individual laptops or desktops.

1: Play / scratch machines that no one really cares about.

Not much lives in this level, if no one cares if it's up or not then you should seriously consider turning it off. The smaller and simpler your environment the easier it'll be to manage.

Examples: sysadmin “play” lab environment, company jukebox

And now some warnings - these categories are (obviously) not perfect. The ratings are host-centric (but can be pulled up a level and applied to clusters or groups of identical machines), it doesn’t factor in office politics (some systems are loved by certain members of management and should be treated like one of their loved ones).

It’s also worth noting that some systems rise in importance at certain times; examples are month end batch reports, time-sheet systems when invoices are due etc. It shouldn’t be too hard to work out most of these (typically cyclical) requirements after speaking to the other staff. Asking about their requirements is always a good way to help build bridges and show you do understand that the systems are there for a reason; to be used.