question

Have a similar sort of mess!

Some info(probably more dev related than anything else) is stored in a dev wiki: server configs, server locations, useful contacts, build scripts (as in h/w builds)

Some tasks are document in Word docs - generally tasks that could be performed by anyone with a modicum of technical and SQL knowledge. These are often step-by-step, peppered with screen shots overlayed with big red arrows and circles, annotated with 'Click this!'

Pure DBA tasks - rarely documented at all, probably due to the fact that the DBA team is me.

In previous roles where the DBA team has been more than me - we have tended to use a netowrk share directory/folder structure to organize all kinds of documents: Word docs, sql scripts, Visio diagrams, udls, whitepapers, pdfs, etc, but it often fell to the junior member of the team to keep it tidy, as they would always be the one asking 'How do we....?'. If we came across a procedure that wasn't documented, then as part of the mentoring and knowledge sharing, the junior would be required to document it and save it away

For common scripts, stored procedures, etc., we create a database and put all the procedures in there. We also name them in a way that you know they were created by us, for our needs. Most of them are documented in the comments, but that still makes it hard to find what you need. For processes, etc., we keep our documents in clearly defined folders in Sharepoint. We also use the Sharepoint discussion groups to comment on the documents and processes, linking the two together, so that proposed changes can be communicated. Finally, we have a standard project document that describes the systems used by the project, people responsible and deployment methodologies used by the project (since they unfortunately vary).

It's not the perfect all-in-one type of solution, but there are only a few places to look for information and we're pretty disciplined about keeping the right stuff in the right place.