My theory on sysadmin mistakes is--   they will happen.   Hell, I'm a
senior SA-- many of us are, and I admit, there's still times when uh,
something doesn't go as planned.....

As far as that goes, my thought process always goes to--  "ok, that
happened...   and now that we've dealt with it, how can we prevent that
problem from ever occurring again?"

Example:  in my early days of sysadminning (a VMS server with a
disk-hungry mumps application) --  a database disk filled up overnight.
It was...   bad.    I dealt with it, got things running, and then to
prevent that from biting me again, I added proactive disk monitoring
alerts - so that if or when things got out of control, I could be
automatically paged to investigate and handle the errant process or
whatever, BEFORE bad things happened.   (In today's world, we all do
that with nagios/hobbit/whatever...).

My point being--   it's ok, in my opinion, for mistakes to happen (*).
ONCE.    Review, learn, manage, prevent further occurrances.   A good
boss will apply these rules to juniors too.   

Boy, we could discuss this forever.   Time to write a book.

(*) There is a difficult to describe line between "mistakes happen" and
"this broke because of poor planning".    A corollary to the "mistakes
happen" rule in my book is, sysadmins have privileges, and with that
comes great power to wreak great harm.  As such, before a sysadmin
(especially a junior) takes action - always always have a
backup/recovery plan.   Or two.   Or three.    

---------------------------------------------------------------------
Kent C. Brodie              
Department of Physiology   
(and) Human and Molecular Genetics Center
Medical College of Wisconsin
[email protected]                           +1 414 955 8590


-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf Of Richard Chycoski
Sent: Friday, July 16, 2010 10:26 AM
To: Paul Graydon
Cc: [email protected]
Subject: Re: [lopsa-discuss] How to improve a junior
sysadmin'sproblem-solving skills

Paul Graydon wrote:
> Brandon S Allbery KF8NH wrote:
>   
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 7/15/10 12:27 , Derek J. Balling wrote:
>>   
>>     
>>> I think there's certainly that fear. I mean, as I was a junior, I
had a mentor who was very understanding about the "junior guy making
mistakes"[1], but I've witnessed less understanding sysadmins berate a
junior guy for making the problem worse when "the problem was so simple
a [pejorative] could have fixed it".
>>>     
>>>       
>> A senior SA who does something like that should not be "senior".
>>   
>>     
> Agreed, but it's probably not surprising to any LOPSA member just how 
> often you come across them.
>
> Paul
Yes, it happens far too often. My first supervisor had a fiery temper  
that could be triggered by the simplest mistakes, and it was not fun 
getting blasted for making mistakes when learning something new. I 
eventually discovered that if I made a mistake and took the problem to 
him (rather than him tripping across the problem on his own) he was much

more amenable to helping me fix it, instead of blowing his top - but it 
was definitely trial-by-fire in my early days!

Don't do this to people. Be understanding, we all have to learn the
ropes.

Someone who is learning needs permission to make mistakes. You don't 
learn if you don't make mistakes (or at least you're not learning as 
much as you could!). There are different ways that this can be 
accomplished - not making the junior admin's first job be to work on the

most-business-critical system that you own, is a good first step.

Encourage the admin to ask questions, and let them know that no question

is 'too trivial' or 'beneath you' to answer. There are no stupid
questions!

Whenever possible, provide a safe (non-business-impacting) environment 
for the admin to experiment in. For Unix/Linux issues, my favourite is 
to use virtual machines. I have a couple of lab boxes running VMware 
that my team uses for 'what if?'. They understand the value of 
checkpoints and 'groundhog day'. It only takes me a few minutes to 
trigger the building of new VMs that can be tossed away when no longer 
needed, and anyone can have root on their machines to try any kind of 
simulation - my team (who are not sysadmins) are learning a lot about 
systems administration, debugging, and developing without the shadow of 
failure being an issue.

Encourage success! When the admin does something correctly they need 
positive feedback - more than they need negative feedback when they fail

Praise in public, correct in private. Praise them in front of their 
manager (if that's not you) and their team! Take any corrective 
discussions away from others' ears. This is especially true if you are 
much more senior than they are, but you should even do this if you are 
at the same level or below the person who is being praised or corrected.

You'll be developing a environment of trust, which is essential to good 
working relationships.

- Richard
_______________________________________________
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/

Reply via email to