System Admin's Unit of Production?

RailGunSally writes "I am a (strictly technical) member of a large *nix systems admin team at a Fortune 150. Our new IT Management Overlord is a hardcore bean-counter from hell. We in the trenches have been tasked with providing 'metrics' on absolutely everything from system utilization to paper clip recycling. Of course, measuring productivity is right up there at the top of the list. We're stumped as to a definition of the basic unit of productivity for a *nix admin. There is a school of thought in our group that holds that if the PHBs are simple enough to want to operate purely from pie charts and spreadsheets, then we should just graph some output from /dev/random and have done with it. I personally love the idea, but I feel the need for due diligence, so I put the question to the Slashdot community: How does one reasonably quantify admin productivity?"

Unit of productivity

[orionpi]

Unit of Productivity = 1 / (hours of down time)

They are paying you to keep bad things from happening.

Metrics

[Codifex Maximus]

RailGunSally wrote:
>We in the trenches have been tasked with providing 'metrics' on absolutely everything from system utilization to paper clip recycling.

This pretty much says it all; your manager wants you to do HIS job. Shouldn't he develop his own metrics? He can ask you for ideas but he should do the work himself. As for metrics, I'd suggest downtime percentages for each machine. If the services are up and running and the machines are online providing service then that should be metrics enough.

You're only as good as...

[iminplaya]

They consider you only as good as your last mistake. The bosses don't want to know what goes on "under the hood". It just has to work. Anything less than 100% uptime is considered a failure in their eyes.

Re:The hammer priciple.

[servognome]

Nevertheless beancounters are stupid (also Beancounters are not accountants), they know the cost of everything and the value of nothing.

Beancounters who try to impose their metrics are stupid, as they really don't understand what to measure. Any worker should understand their job enough to put together metrics that demonstrate their value. In the original post the beancounter went about things the right way, ask the admin how they would measure their job.
 
Without metrics you leave yourself open to the opinions of others. For example if your company expands and the system slows down, some r-tard in accounting will complain it's taking longer for him to do his job. If you have a performance metric such as requests processed per hour, you can clearly demonstrate that while individual requests may take longer, the overall number of requests being processed is higher. It also lets you present data for additional resources, productivity improvements, etc.

Re:Time to find another job

[archen]

It also goes a bit more on a tangent when you think about it. Take sys admin A and B. A does 20% more of stuff that would be considered "productive". Sysadmin B spent 60% more time verifying backup scenarios and researching things. When things are just fine, then sure sysadmin A looks good on paper. When stuff goes wrong and critical business functions completely stop, then sysadmin A will not look so good. Likewise you would never want to "fully utilize" such a person anyway. If you are at 100% capacity for how much you can handle, and THEN the shit hits the fan; things will be dropped on the floor left and right and I.T. will look like a train wreck.

A lot of people also seem to be bringing up how much "uptime" you have. That's fine, but it is quite possible to have great uptime with everything strung together with duck tape and wire coat hangers - just waiting for the day when it does go wrong like wrong has never been done before. There is most certainly something to be said about the sys admin who takes the time to better understand systems, researches disaster response and proactively works on redundancy. These aren't necessarily things which count as "productive" but show their merits in any good I.T. environment.

I know there are bean counters who like to think that absolutely everything can be measured in some quantitative way in a master excel spreadsheet, but it simply isn't so - and honestly such thinking is quite dangerous. Some sys admin functions can be benchmarked but many computer related fields just can't be benchmarked overall in such a way. That's like benchmarking a programmer by how many lines of code he/she writes.

Dumb question even in management terms

[crmartin]

... because a system administrator isn't producing anything, any more than a safety engineer is. They're there to preserve certain non-functional properties of the system. The appropriate measure is how much of the time the system meets or exceeds the service level agreed to, and what the cost is in staff hours to do that.

Trying to turn it into a "productivity" measure will have the inevitable effect of maximizing whatever is being measured, whether it's LOC of scripts, service tickets closed per hour, or kumquats per fortnight.

Its control, not measurement, that you really need

[strangedays]

Get control.

Form a union or form a company. Go off site with the other sysadmin colleagues and either form or join a union or form a company.

If union: Form it legally. Then negotiate for better pay, recognition and benefits. Take legal actions as necessary to achieve your collective bargaining objectives. Use the "unreasonable" demands for undefined metrics as justification. Cite the beancounters by name.

The basic problem with current IT Sysadmins and Janitors (which is what they think you are) is that no one has the balls our grandparents had to join together to stand up to PHB's. Collective bargaining is a reasonable and effective strategy, if you let them divide you, they will win.

Are you really so naive as to believe that MBA classes are about how to measure things and how to "listen" to employees. ROFL. Grow up will ya. MBA's are about how to obtain and wield power to become personally wealthy. It's that simple.

Part of their strategy is hiding behind smoke screens and FUD, using HR and other gullible people types to deploy change. Measurement of things where the units are intrinsically undefinable is an old and effective technique. Play their game, their way, and you will lose.

If "form a company": This is a much better alternative (if you are a small group of Sysadmins they need and can reach a practical agreement). Form your own services company. Then all quit on the same day and immediately offer your services (on reasonable terms) to the same company. The terms should offer no loss of continuity or support and an effective SLA, based on Your Metrics This is quite legal and reasonable, it's how many companies start, it's called free enterprise. Hopefully during the few days it takes to complete the negotiations, none of their systems fail catastrophically. But if so... why would you care... Somebody else's problem.. right. Either your worth paying for your services, or your not. The real question is do you have the testosterone to really find out?

The only question any MBA cares about, is who dies with the most toys. Ethics is a course taken so they know what to avoid doing by accident.

The only option for working practitioners is either collective bargaining (poor and outdated) or running your own services company (better imho, but takes real organization and balls)

So... have you got a pair?

What part of "Get Control", don't you guys understand?

Nmber of times the SysAdmin has to be consulted

[bokmann]

The metric should be 'number of times the sysadmin has to be consulted', and it should be driven as close to zero as possible.

I might get moded 'funny', or 'flamebait', but I'm serious.

Think about it. When is a sysadmin needed? When there is some kind of crisis. "I can't get to the internet", "I can't check m email", "My computer thinks I might have won a million dollars", "I lost that important project file". A good sysadmin will prevent these things from ever happening, and when they do happen will have them resolved quickly, without a lot of technobabble or attitude (like the SNL skit guy), and will fade into the woodwork. Ironically, the middle-of-the-road IT guys are often thought of as heroes by the staff they support. They might be thought of as the firefighters, but unfortunately, they are also often the pyromaniacs.

Other useful metrics:

If you don't already have a ticket support system, get one. It will generate useful metrics for you. Some useful things out of it would be:

- The AGE of the OLDEST OPEN SUPPORT TICKET. Proves you aren't dilly-dallying

- Number of Priority 1 Tickets opened per quarter (see above - should be as low as possible)

- Everything you do, you should open a ticket for. Upgrading that linux box? Ticket it. Updating anti-virus definitions? ticket it. From this you will get:

- Nunber of tickets open per day

- Nunber of proactive vs. reactive tickets (tickets you opened vs. someone else opened. You should get credit for fixing things before they become an issue someone notices.

And if the bean counter needs some big numbers to justify things, just count up stuff that the logs on public boxes find. Seriously - have you ever looked at the stuff from logwatch? Just yesterday I had 2163 unique failed attempts to log in as root, not to mention all of the other assorted hackery it catches. "Number of successfully defended intrusion attempts" is a metric that will scare a bean counter enough that he won't take the liability of getting rid of you.

Compare it to other similar jobs

[koehn]

Part of the problem is that the sysadmin job is somewhat reactive (like the plumber who responds to problems), somewhat preventative (like the security guard keeping the bad guys out), and somewhat prescriptive (like the carpenter adding on another 20000 SF of building). Try to divide the general role into these different categories and come up with metrics for each. Coming up with a single metric will be nearly impossible because of the diversity of the responsibilities of the job.

Find other jobs that have similar, "preventing the negative" jobs. How would you measure the security guard's efficacy?