The problem with busy sysadmins

August 28, 2011

As I wrote yesterday, one of the reasons that I don't think we need a trouble ticketing system here is that we are not all that busy with requests; in fact, the average number of open requests is generally zero. I think that this is a good thing, and that frequently having more open requests than sysadmins or even having all of your sysadmins busy dealing with requests is an important danger sign.

It's a danger sign because it means that your sysadmins are too busy to do long-term work. Instead, they're either doing things that need to be automated, or spending their time running around throwing water on a succession of fires, or in general being reduced to being operations monkeys who carry out standard procedures (which is not a good way to keep good sysadmins, because frankly it's boring). In short, you're too busy dealing with the now to be building the future. This is not a good place to be in; the future always arrives sooner or later.

Sysadmins that are 'idle' from the perspective of a trouble ticketing system are sysadmins that have time to work on larger projects and to prepare for the future. And you need more than little bits of time here and there, for the same reason that developers need it; you need solid blocks of time where you can focus on a single thing instead of playing whack-a-mole with trouble tickets.

Thus I consider it an extremely healthy sign that we have so few requests that a 'level 1' mailing list setup can handle it. This is the kind of environment you need to produced things like cheap iSCSI based fileservers, upgrades of complex mail systems, and transitions of core routers in a complex network environment.

(My personal feeling is that trying to put long term development projects in a trouble ticketing system is not going to work really well. It's the kind of thing that I would only do if I had to use a TT system for everything because of some outside mandate.)

Comments on this page:

From at 2011-08-30 16:36:17:

We have a trouble ticketing system that allows for a ticket to be broken out into subtasks. This is perfect for tracking more long-range project work.

Also, we have reports and notifications of problems going to our ticketing system. This means that if a report requires manual review and intervention (check backup logs for failed jobs, check filtered syslog or spunk for "known problem" or anomalous messages) there is a paper trail, which can be shown to the audit folks and bean counters, to show that X item was indeed taken care of because some particular person signed off that it was reviewed or corrected.

Also, when you say that some of the smaller tasks normally stored in a ticketing system are those that should be automated, a ticketing system is a great way to keep track of those issues as well. Instead of closing the ticket with "disk full. Cleaned files", close it with "disk full. Implemented script to clean files and added weekly cron entry."

Written on 28 August 2011.
« Why we don't use a trouble ticketing system
Designing services for disengagement »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Aug 28 01:10:17 2011
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.