How to measure a sysadmin's workload? [closed]

Solution 1:

Is your job closing tickets or working as a sysadmin?

I'm of the opinion that a sysadmin does more then handling tickets and using the ticketing system as primary time accounting and job justification would be the wrong tool for the job.

As a manager or team lead you should already know what consumes most resources/time/money/effort. If you have some "fat on the bones" you can do a little bit more with the same team or do the same with slightly fewer people but typically if you need to save money you're simply going to do less.

Save 30% and you're not going to get after hours support even when your CEO drops his blackberry in the loo.

Typically there's routine work, incidents, project work and overhead and you use tickets for only incidents and if you can't avoid it; routine work.

Routine work scales more or less linearly with the number of systems/clients/applications i.e. for every # number of .... we need one additional sysadmin. By spending effort in automation and "expectation management" you can often increase that # number of ... significantly. Regardless keeping things up and running takes time and effort. Doing routine work well prevents tickets being raised in the first place.

Creating tickets for routine work often introduces more overhead and delays and while it gives you accounting you won't get ahead.

Example: each new server takes e.g. 16 hours of work to unpack, rack, cable, install OS, burn in, configure OS/monitoring/backup/SAN/deal with DOA's/ etc. 20 new and replacement servers each month equals two junior sysadmins. Buy a complete cabinet with those 20 servers and their switch loaded and pre-wired and get that shipped to your datacenter instead and engineer an imaging server and you could do the same easily within a single workweek or less.

Logging of incidents is typically a good thing, because by definition they're not planned. Common/recurring incidents can be found and engineered away but you need some justification to make that effort. Incicents and the more complex problems can take serious effort and time to resolve and some accounting of time spent isn't a bad thing.

For project work you don't need tickets, you work with a predefined budget after you have given a quote based on e.g the high level design or a requirements document. After the project has been approved and budget allocated you use common project planning and accounting techniques and not a ticketing system.

Overhead is team meetings, talking to your management about the usefulness of ticketing etc. It doesn't close tickets but is still important.

Solution 2:

Since I don't have enough rep to answer in the comment section, I'm going to drop it as a solution.

The solution requires the admins and management to actually talk. Management should have some insight as to what a sysadmin does - regardless of platform. A sysadmin should have some professionalism and insight as to what problems are using up his time and is that a good thing.

Help-desk systems are great for management because the scope is often homogeneous i.e. tier 1 and 2 issues that impact a small department. A (good) sysadmins work will cover a wide range of impacts that are not always measurable and if they are, often require more than a ticket to quantify. Management has an issue and decided on a tool to measure something that they are unfamiliar with. I recommend having management sit down and talk to the sysadmins about what parts of their job having a significant or ROI in management speak, what parts of their job are an inefficient use of their time and agreeing on a way to measure that. Alternatively, management could talk the sysadmins and actually come up with a solution to the problem together.

I propose that a professional sysadmin would welcome the opportunity to unload scut work and work on things that have a significant impact. If their work truly does have an impact, then some sort of metric can be used - besides the almighty uptime - and management can have a greater insight into what a sysadmin does. If the sysadmin just wants to play firefighter and lifeguard all day and/or can't clearly communicate their importance to the organization, then that's a different conversation.