I have a sudden need to comprehensively document a moderately complex platform, and break it down into service and application components, and describe how these services can be migrated and are provided into a new platform which is cloud based.

Obviously in both a desire for brevity, and a desire to comply with the rules of the site, I am not looking to get into discussion about benefits and types of documentation, just to capture the basic list of "facts" that manage a generic application stack.

My initial off-the-top-of-my-head list is as follows.

Support Services

Build documentation
Service documentation
End-user documentation

Configuration Compliance
Package and update monitoring
Vulnerability scanning

Backup & Recovery
OS Level
Application Data

Server Management
Bare metal Deployment
Configuration management
Upgrade & Package mngt

Shared Services
User Authentication
Internal DNS & DHCP
External DNS

OS level metrics
Service level metrics
External URL monitoring

Web Analytics
Availability Reports
OS level statistics

If there is anything missing, I would be keen to identify it.

ps I would also be interested in excel or google docs templates to track these items.

closed as not constructive by Ward, Iain, Scott Pack, Chris S, MDMarra Feb 5 '12 at 15:00

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. If this question can be reworded to fit the rules in the help center, please edit the question.

locked by HopelessN00b Jan 22 '15 at 7:14

This question exists because it has historical significance, but it is not considered a good, on-topic question for this site, so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. More info: help center.

Read more about locked posts here.


Your list of items to document is relatively complete.

For format, my first suggestion is to make it match the other documentation in your company (if you use Wikis, wiki it. If you use SharePoint, put it in SharePoint, etc.) -- You want to make sure people will actually read (and update) the documentation.
Similarly if you have a specific document format at your company use that. Otherwise my suggestion is to break each practice area into a separate document (Backup & Restore ; Provisioning & Deployment ; Monitoring & Metrics ; etc...) -- Make them logical units that can have a specific person responsible for them.

(Note that "Security" is a special case -- Implementing and maintaining secure systems should be covered in EVERY OTHER BOOK, and the Security book should just be the general company security policies that drive that implementation. This tends to be a cleaner/more sensible setup than having everyone fight over the security book because they need to look something up.)

Not the answer you're looking for? Browse other questions tagged or ask your own question.