We tackle this a few different ways, generally (although I can't say we've had huge numbers of interns in here).
1.) Give them something new and experimental to install/ setup. There are always a few projects that teams put in the "we'll get to that... eventually..." bucket that tend to fall into new development, r&d, etc. With these projects, they'll typically only need root access to the boxes they're setting up, which are presumably not mission-critical boxes if you're doing r&d on them. :) Testing out new versions of software, trying completely new apps, etc. work well here. 2.) Have them do grunt work. There's a certain amount of grunt work required, that no one likes doing. Updating the hardware inventory. Cleaning up cables. Checking ports. Cleaning up documentation. Checking on monitoring. There's a limit to how much of this you can get away with, but there's certainly plenty of non-root work that can be farmed off to interns (or junior admins or whatever). 3.) Give them a specific project that no one has the skillset (or potentially the time) to do. Bring in a development intern to build some automation, or write that apache module you've always wished you had but couldn't justify spending the time on. Have them do something you know you ought to be doing, but that keeps on getting de-prioritized, like doing a penetration test on your network. Have them set up a purchasing system, or write up process documentation, or user-facing documentation. Maybe they've got a decent database background and can help set up some asset reporting against your CMDB or help optimize the queries that you use to look up tickets. Finally, the least structured but easiest thing: 4.) Have them play the gopher role. They can shadow an admin, and help them get whatever they're doing done. If they're racking a stack of servers, a second set of hands helps. If they're building machines out, a second set of hands helps. If they're reviewing monitoring, a second set of eyes helps. When emergencies strike, they can potentially keep on going (or at least "maintain state") on whatever project their assigned admin was working on. If there are shifts, maybe they can work across two shifts and help with the knowledge sharing. Nicholas On Tue, Sep 14, 2010 at 10:11 PM, Justin Lintz <[email protected]> wrote: > Last year at work I got our group an intern for the summer and once he > started I realized we were having a hard time finding the right projects for > him. Generally internships are from 6-8 weeks and a lot of sys admin > related work requires root to perform the tasks. With development > internships you can just give them a small coding project or some bugs to > correct in code and gently introduce them into the environment, with a sys > admin position a lot of the tasks and basic routine tickets required root. > We ended up taking him out to the datacenter a few times, showing him the > cage setup, walked him through the ropes of getting a new server up and > running from the cabling into the kickstart. His Linux knowledge was shaky > so I spent time with him showing him the ropes of the command line, > explaining the permissions of the files,taught him the basics of configuring > an IP on a test linux desktop we gave him and installing apache and getting > a hello world page. The 6 weeks flew by real fast and I felt bad for not > having a well thought out program for him or being able to give him any > substantial projects. He was very appreciative of the opportunity even if > it was a lot of job shadowing to learn about the job role and high level > introductions to things. I'm curious as to how the rest of the group > handles sys admin internships and what sort of programs they have laid out > for a time frame of 6-8 weeks for someone. Do you give them the keys to the > car and shadow them while they are doing tasks? Do they have only access to > the staging or development environments where if something goes wrong its > not that big of a deal? > - Justin Lintz > > _______________________________________________ > Discuss mailing list > [email protected] > http://lopsa.org/cgi-bin/mailman/listinfo/discuss > This list provided by the League of Professional System Administrators > http://lopsa.org/ > > _______________________________________________ Discuss mailing list [email protected] http://lopsa.org/cgi-bin/mailman/listinfo/discuss This list provided by the League of Professional System Administrators http://lopsa.org/
