Documentation Woes..

TechJunky

Ugh, I am tired of documenting/producing documents for upgade paths and improvements...

Does anyone else here do more documentation than administration? I feel like an engineer now.

cbigbrick

I learned along time ago in construction that it doesn't mean sh$t if it aint on paper...aka documented. It's just the world we live in now a days. Everyone is CYA all the time. I just plug in the iPod and go to my own world.

networker050184

cbigbrick wrote:

I learned along time ago in construction that it doesn't mean sh$t if it aint on paper...aka documented. It's just the world we live in now a days. Everyone is CYA all the time. I just plug in the iPod and go to my own world.

+1

If you don't document it down it never happened.

Pash

Change control documents for restarting the print spooling service on one of our servers. I **** you not.

Im all for project documentation that are required by the customer as part of the work sure......but im not for creating pointless documents for basic things when a few minutes later im asked to start clearing the calls off the database

Thing is my old man is a quality manager for Ford R&D UK, so he knows all about change control and documentation - he has a basic knowledge about IT and when i told him that was our customers requirement he was like....well bollocks to that.

cacharo

Pash wrote:

Change control documents for restarting the print spooling service on one of our servers. I **** you not.

Wow...

RTmarc

Try working for a financial institution. EVERYTHING has to be documented.

TechJunky

Wow, its lunch already! Atleast it made the day go by quickly.

tiersten

RTmarc wrote:

Try working for a financial institution. EVERYTHING has to be documented.

Yup. Every so often an auditor will come around and check that you've documented it as well.

The users don't like it but you have to refuse to do anything without a change control form.

RTmarc

tiersten wrote:

RTmarc wrote:

Try working for a financial institution. EVERYTHING has to be documented.

Yup. Every so often an auditor will come around and check that you've documented it as well.

The users don't like it but you have to refuse to do anything without a change control form.

You aren't kidding. Loads and loads of fun!!

HeroPsycho

Pash wrote:

Change control documents for restarting the print spooling service on one of our servers. I **** you not.

Honestly, if there's a special procedure you have to do it, or if you need to do it as a regular maintenance (as in not for troubleshooting, but preventative maintenance activity), it should be documented! If not, agreed, that's ridiculous. Next thing you know, you'll be documenting how to hit the power button to turn the server on.

Dude, remember, engineers are higher in the food chain than admins. Do as an engineer would do, and soon, you'll be treated and paid like one.

tiersten

HeroPsycho wrote:

Next thing you know, you'll be documenting how to hit the power button to turn the server on.

Yup. Got that documented already. All of our power up/down procedures actually shows you which button to press and in what order. The power up procedure for the core systems alone is about 10 pages long. That will bring up enough to operate the business at a minimal level.

Quarterly DR tests mean you pretty much have to write all this stuff down. Anybody in the IT department should be able to bring up the DR site from following the instructions alone without any help from anybody else.

The fun of working in finance.

HeroPsycho

tiersten wrote:

Yup. Got that documented already. All of our power up/down procedures actually shows you which button to press and in what order. The power up procedure for the core systems alone is about 10 pages long. That will bring up enough to operate the business at a minimal level.

Quarterly DR tests mean you pretty much have to write all this stuff down. Anybody in the IT department should be able to bring up the DR site from following the instructions alone without any help from anybody else.

The fun of working in finance.

Well, it's better to err in that manner than in the opposite direction. I deal a lot with smaller customers who think a Visio diagram of their overall network layout is all the documentation they need, and are unwilling to pay for anyone to document it further.

NetAdmin2436

Does anyone have a little basic list on what are the things you should be documenting.

I work for a fairly small company and I'll admit my documentation is.....well, non existent. It's all in my head, which is bad for the company I know. Good job security though . They've never asked for any documentation, but I feel I should make something. I don't even have a support ticket system or nothing. When i first started I carried a notebook and wrote down the problem and the solution, but i never kept up with it.

HeroPsycho

Things to help you and others troubleshoot:

Overall network design
Email flow
Any complex service involving multiple servers (for example, with Exchange show if you have front-end and backend servers, an ISA server publishing, etc.)

Basics in case you get hit by a bus:

important accounts - DSRM, domain admin, service accounts, important local accounts, public DNS account info, etc.
Current disaster recovery plan, even if that means step by step instructions for rebuilding each critical system
Special procedures for anything that requires it

NetAdmin2436

HeroPsycho wrote:

Things to help you and others troubleshoot:

Overall network design
Email flow
Any complex service involving multiple servers (for example, with Exchange show if you have front-end and backend servers, an ISA server publishing, etc.)

Basics in case you get hit by a bus:

important accounts - DSRM, domain admin, service accounts, important local accounts, public DNS account info, etc.
Current disaster recovery plan, even if that means step by step instructions for rebuilding each critical system
Special procedures for anything that requires it

Cool, thanks....your my hero.

I guess I have most of this documented in my notebook except for the disaster recovery part....but it's all scattered. I knew I didn't have a disaster recovery plan before, so I suppose it's time to make one.

Sorry to hijack your post techjunky.

TechJunky

My latest project has been documenting how to merge 6 companies seperate domain's into one big forest and create OU's for each domain instead of seperate domains. This is just the small portion of the pie.

I am also working on domain security plans, how the current infastructure is setup and what will need changing with the merger etc. So mine is a little different.

I have documented all critical servers, visio of the networks, rackmount visio's, basically anything I can think of when the time comes for reference material just incase someone isn't on site they have a document or drawing to reference to so they could walk someone through reinstalling, finding a server etc.

I dont mind hijacking, especially when its useful information.

HeroPsycho

NetAdmin2436 wrote:

Cool, thanks....your my hero.

I guess I have most of this documented in my notebook except for the disaster recovery part....but it's all scattered. I knew I didn't have a disaster recovery plan before, so I suppose it's time to make one.

Sorry to hijack your post techjunky.

Make sure this documentation is elsewhere less prone to loss than your notebook, and that your notebook is encrypted. You don't want everyone getting the keys to the kingdom by swiping your laptop.

And what out, I'm your psycho, too.