Wiki Site-books (RunBooks)
Tags documentation, runbook, wiki
Do you document your admin procedures? Tired of spending three hours learning how to configure something new or troubleshoot a problem, only to relearn all about it 11 months from now. Write the how-to in your own words so you understand it better.
We use MediaWiki servers for our run-books (site books). I'm not sure what "you" call them, but they are an invaluable asset to an aging team of developers and admin staff, like myself.
If you're not already using some sort of documentation system, that's not only backed up but replicated to another system, you're probably going to regret it some day.
Sure, Mr. Google and Mrs. Bing are great, but there's nothing like reading your own words when it comes time to do one of the long term repetitive tasks that all admins must do. A year down the road.
There's one thing I say about Unix/Linux guys is, "You spend more time up front during configuration time, but once it's setup, you can usually forget about it for a year or three, it'll keep running". That's where a healthy documentation server coming in handy.
One time at band camp... oh, wrong site! Once the server went down that contained the wiki too. I needed to look something up in one of my docs. BAD! Now I run two MySQL replicated Wiki servers in two separate system frames. I use rsync to sync the upload docs to each server. I find a backup server is a good place for a wiki since usually the backup server is sitting idle during the day. Or if you have a Master backup server and a media server (as do some backup solutions, put one wiki node on each server. This is especially reasonable if you're running many CPU cores or a SPARC T2 processor with LOTS of threads to handle all the load.
Don't put the services in the same physical frame either. Maybe even two different server rooms and/or sites is best. Once you get use to the Wiki ways of writing you'll find that being a diligent note taker is fast and easy, especially with the new invention of copy & paste. :-)
We now have hundreds of personally written "WikiDocs" which contain everything from Solaris install customizations, to Frame configuration tables and license numbers/files and serial numbers.
If you plan on keeping system passwords in a doc center, BE VERY CAREFUL. Learn now to lock down the doc system at multiple levels. Use everything from htaccess files to TCP wrappers, and built in SSL authentication. Whatever it takes to protect those passwords. Only your senior admins should have access to those pages. And don't keep them on the web!!!
All common sense I know... but! :-)
Save time in the long run and document.
Cheers,
bits
We use MediaWiki servers for our run-books (site books). I'm not sure what "you" call them, but they are an invaluable asset to an aging team of developers and admin staff, like myself.
If you're not already using some sort of documentation system, that's not only backed up but replicated to another system, you're probably going to regret it some day.
Sure, Mr. Google and Mrs. Bing are great, but there's nothing like reading your own words when it comes time to do one of the long term repetitive tasks that all admins must do. A year down the road.
There's one thing I say about Unix/Linux guys is, "You spend more time up front during configuration time, but once it's setup, you can usually forget about it for a year or three, it'll keep running". That's where a healthy documentation server coming in handy.
One time at band camp... oh, wrong site! Once the server went down that contained the wiki too. I needed to look something up in one of my docs. BAD! Now I run two MySQL replicated Wiki servers in two separate system frames. I use rsync to sync the upload docs to each server. I find a backup server is a good place for a wiki since usually the backup server is sitting idle during the day. Or if you have a Master backup server and a media server (as do some backup solutions, put one wiki node on each server. This is especially reasonable if you're running many CPU cores or a SPARC T2 processor with LOTS of threads to handle all the load.
Don't put the services in the same physical frame either. Maybe even two different server rooms and/or sites is best. Once you get use to the Wiki ways of writing you'll find that being a diligent note taker is fast and easy, especially with the new invention of copy & paste. :-)
We now have hundreds of personally written "WikiDocs" which contain everything from Solaris install customizations, to Frame configuration tables and license numbers/files and serial numbers.
If you plan on keeping system passwords in a doc center, BE VERY CAREFUL. Learn now to lock down the doc system at multiple levels. Use everything from htaccess files to TCP wrappers, and built in SSL authentication. Whatever it takes to protect those passwords. Only your senior admins should have access to those pages. And don't keep them on the web!!!
All common sense I know... but! :-)
Save time in the long run and document.
Cheers,
bits
Total Comments 0
