How Much Unix Knowledge For Helpdesk Staff?

Shisha asks: "I have to train IT helpdesk staff to be able to solve UNIX related problems. The trouble is I don't really know what will be most useful for them. I can't teach them all about shells, processes, deamons, sendmail, Xwindows etc. because that's just too complex. Another problem is in the slight differences between AIX, Solaris, Irix and Linux. The idea is that they should be able to solve simple problems, so that the really qualified people won't have to waste their time on them. We are talking about 16,000 potential users, on 5-10 multiuser servers and about 300 Xwindows workstations, so the number of problems daily is high. Also what commands would they need with root privileges (through sudo)? So the question is what should they know and what access rights should they have."

Comments

well...

[Clover_Kicker]

I don't know diddly about your environment, so it's a bit hard to give specific advice. The smartass answer is to teach your techs everything you can about Unix, but that probably isn't practical.

It's painful, but the only way to really identify where you need training is to log *all* your support calls/visits/escalations for a couple of weeks.

By looking at your calls, you can see what kinds of questions the techs are getting, and you can identify the most critical training needs for the techs, and maybe even justify some user training.

Repeat this process every 6 months or so. Logging everything is hell, but it does pay off.

Maybe you've already got a tech support ticketing system in place, in which case maybe you should be trolling your ticket database instead of surfing /.

how about these

[nomadic]

Like everyone else said, look at problem history, but they would probably find the following useful:

• ifconfig
• more and tail
• ps auxwww|more (orps -auxwww|more or whatever that unix flavor uses)
• ps auxwww|grep -i whatever
• How to kill and restart the X server (like control-alt-backspace then startx -- -bpp 24 or whatever the X startup script is for that box. Though of course your boxes might not go to a terminal if X is killed, just an X logon)
• top
• chmod, chown, chgrp and a little bit about file permissioning (wouldn't let them do that as su though)
  
  

I'd give them a rough overview of processes and pids, show them how to check network connectivity (with ifconfig, traceroute, etc), various configuration files in /etc, and maybe what messages to look for during bootup. And oh, reboot of course.
--

Recipe book and games.

[He Who Suffers]

In my early days in computer support, my manager kept a 'recipe book' of the things that commonly went wrong, and the fixes to them. Today this is known as the FAQ.

We were encouraged to add to this collective journal anything that we thought would help other helpdesk people, and to use it to help solve problems. This covered all the operating systems in use and any gotchas about making them interact.

As far as training goes, you need to know what problems you are trying to solve, then plan around those. The recipe book was a huge resource for the types of questions being asked and answered. We used the tools to raise our own questions, and try to solve the problems.

If you are supporting (for example) staroffice, then have the helpdesk people actually use it in their own work producing real output. Give them some time to work out problems among themselves. Don't pressure them do be as productive using the new tools as they were with their old favourites. This will give them a chance to apply any knowledge they may have of general principles from other office suites, and also highlight any needs to bring in expertise for training.

Another tool used by the same manager was to encourage game playing (and game writing) at suitable times on the systems that he wanted people to become familiar with. At different times, our team devised tetris for a dumb ascii terminal(!!) and an interactive game run in a spreadsheet(!!!) While all this was happening we were enjoying the pleasure of hacking while gaining useful (to the organisation) familiarity with systems that we otherwise may not have chosen.

Why not...

[JediTrainer]

Why not have each of your staff learn a particular area and learn it well, then have the users direct themselves to the "Expert" of the area in question. If by phone, a "Press 1 to speak to someone about x-windows video issues".

All of this is even easier on a web form, because you can just have a pull-down menu of the type of question, and that choice dictates who gets the first shot at answering the question.

Perhaps at that point, if the first person can't answer it, you can put it into a "pool" where the rest of the helpdesk staff can see it and try to respond. Generally, you would hope that this pool would only be used once in a while.

Just off the top of my head, a few suggestions. The point being, since the scope of what you're trying to teach them is so large, it might be a good idea to get them to specialize. Jack of all trades, master of none rule might apply here.