How Much Unix Knowledge For Helpdesk Staff? 24
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."
Standardize, standardize, standardize!!! (Score:1)
ore information can be found here:
Microsoft [microsoft.com]
First figure out the problems that are common ... (Score:1)
It sounds like a flame, but it is not intended to be one. If you don't want to waste time teaching them stuff they wouldn't need (or would be confused by), you first need to know what problems are likely.
Ideally, you would look at the records of past problems (you *do* keep logs of each call and the problem, don't you?) and solutions used to figure out what the common problems are. You say you're only using these guys as first line weeding, so hitting the ~80% of problems which get repeated over and over again is all they need.
But since it seems like you might be building things from the ground up, you may not have the usage history to do that. In this case, look at what others cover. If you're tech support for an ISP, look at ISP web pages for troubleshooting guides and FAQs. Look at help files on the programs/systems you use. (Not the official manuals, but the "I'm not associated with this project, but I wrote a help file for new users." ones)
Remember, you're not reading this for your own benefit. If you find yourself reading something for the fourth time, that should be a red flag that this is an important point to cover. Don't just skip over it as redundant.
Above all, remember iterative development. Track help cases and determine what the frequent/easily solved problems are. Keep a manual on these items, and require your support staff to stay up-to-date on it. Just because they passed through the first day's training doesn't mean that they've finished learning.
And another thing ... make your troubleshooting manual publicly availible. That way, when another person finds themselves in the same position you are in now, they can benefit from your wisdom.
Mein Gott (Score:1)
SPOON!!!
Internal IRC server (Score:1)
All your base are belong to us.
Re:Why not... (Score:1)
"Leave the gun, take the canoli."
Hard to say (Score:1)
Re:how about these (Score:1)
I would also add how to use top, how to kill a process, the Left Alt-sysRq sequence (LAlt-SysRq-r,s,e,i,u,and b) or whatever is used to proform an emergency shutdown, and emergency recovery procedures (how to deal with a failed filesystem check, the system hanging at boot, ect. and how to use a rescue disk, boot to a diffrent runlevel, ect.).
Just a hint (Score:1)
Re:Internal IRC server (Score:1)
Re:Recipe book and games. (Score:1)
Thats what they really need, its a if-this-is-the-problem, do this book.
*Not a Sermon, Just a Thought
*/
What to teach them? (Score:1)
UNIX (Score:1)
We now have had training in VAX/VMS, UNIX, and we primarily use Windows 2K. If you are looking into just getting some fundamentals, check the course listings at the local community college. Or buy a decent book.
Re:RHCE (Score:1)
RHCE (Score:1)
That should teach them quit bit,
thyen some minor training on other unices may be required.
And teach them to always, always, read the read-me or man page
Sounds like a university to me... (Score:1)
Even if I'm wrong, I'd bet that those "potential" (read: infrequent, inexperienced) users are after a very short list of features. Most questions probably center around permissions, html related things, network disk space, and email (Pine?). One thing that can be useful is setting up "joe user" accounts in way that forces them to use a specific sub-directory for their web documents. Then set the default permissions so that "joe" doesn't have to change them.
Also check out The HelpDesk Institute [helpdeskinst.com].
Re:Standardize, standardize, standardize!!! (Score:1)
Tailor to their interests... (Score:1)
I am saying this because I remember that the people who got unix accounts at my college were always the first to jump in and try to fix unix issues. The college, by the way, did teach a basics unix class. One near you would probably have a nice course outline.
Re:RHCE (Score:1)
tech support (Score:1)
Re:Why not... (Score:1)
You are right, though. Compartmentalizing would be bad in the case you described. I should have been more specific
well... (Score:2)
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 (Score:2)
- 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--
Recipe book and games. (Score:2)
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... (Score:2)
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.