Company is hiring a new sysadmin. Because we growing more rapidly, I'm transferring my sysadmin duties over so I can concentrate on managing and leading the development team. How can I make this transition go smoothly? What are some good initial steps to take? The new sysadmin will need to have access to all the server and DB management resources and I'm a bit concerned about how to give him all these responsibilities securely. And what are some usual protocols and policies to set up once the new sysadmin is onboard?
Asked
Active
Viewed 163 times
1
-
What exactly do you mean you're concerned about how to give him all these responsibilities securely? – joeqwerty Sep 02 '13 at 05:11
-
@joeqwerty there are lots of passwords and sensitive user information that needs to be transferred over. – lamp_scaler Sep 02 '13 at 05:15
-
OK. What's the concern? – joeqwerty Sep 02 '13 at 05:19
-
@joeqwerty Before all of this information I have in my head and now I'm transferring it over to someone else. Are passwords supposed to be documented somewhere in the future? How to do that securely? What if the sysadmin leaves in the future? Are user info supposed to be visible to the sysadmin or does it need some type of barrier for protection? – lamp_scaler Sep 02 '13 at 05:40
-
> "Before all of this information I have in my head ... " ... yezzyezz ... classical. do a training-on-the-job and let the new guy do all the necessary documentation. – that guy from over there Sep 02 '13 at 06:31
-
This question appears to be off-topic because it is essentially an HR question, not a technical one. That said, if you have concerns about security being maintained, just make sure you ensure he's trustworthy, do a background check, and treat him right. Transfer credentials in person where possible and craft policies according to business needs. – Falcon Momot Sep 02 '13 at 06:41
-
2Personally, I should be sorry if this question were closed. "Best practice" questions have been good in the past around these parts, and I've almost always learned something from the way other responsible sysadmins do things at their sites. And although I can see Falcon's point that this might be an HR question, I don't think the OP is asking about exit interviews, or TUPE regulations, or anything like that; it's "how do I best transfer sysadmin duties while making the company more resilient to changeovers in the future". – MadHatter Sep 02 '13 at 06:42
-
@MadHatter Yes. It's not an HR issue at all. I'm delegating my sysadmin responsibilities over to a new person and I'm solely responsible for if anything goes wrong. – lamp_scaler Sep 02 '13 at 06:58
-
7`all of this information I have in my head...` - You are doing it wrong. Someone else should be able to maintain your network if you get run over by a bus. Start documenting things. Start here. http://serverfault.com/questions/46273/getting-started-with-documentation – Zoredache Sep 02 '13 at 07:36
2 Answers
7
If you are asking these kinds of questions, then you need to buy one particular book NOW and read it through.
Do not wait. Do not pass Go. Do not collect $200.
Buy The Practice of Network and System Administration and read it.
Magellan
- 4,431
- 3
- 29
- 53
4
We know it happens to a degree no matter what you do, but the problem here is that the information is inside your head, not inside a documentation system of some kind. The links below are examples, not product recommendations
There are countless wiki and blog programs you could run internally to document this knowledge if you don't fancy/need one of the sophisticated helpdesk systems that also does documentation, in which case you should still be looking at the simpler helpdesk systems, because tracking this is important too.
As for passwords, these need to be more closely held of course. There are lots of secure password management programs around for that info that let you track who accessed this or changed that.
The main problem here is time management. It's difficult in an expanding company where everyone is already busy but you need to start things off right with your new sysadmin employee by introducing the mantra that documenting what you've done on a job is part of doing that job and therefore part of the time allocated to doing that job (and by which I mean increase the time allocated, not expect people to work faster!), rather than something that gets done on a 'when I have time' basis.
