我突然需要全面logging一个适度复杂的平台，并将其分解成服务和应用程序组件，并描述如何将这些服务迁移并提供到基于云的新平台中。
显然，既要求简洁，又要遵守网站的规则，我不打算讨论文档的好处和types，只是为了捕获pipe理generics应用程序的“事实”的基本列表叠加。
我最初的头脑清单如下。
支持服务
售票处
警报
升级
文档
构build文档
服务文件
最终用户文档
安全
configuration合规性
打包和更新监控
漏洞扫描
备份和恢复
OS级别
应用数据
服务器pipe理
裸机部署
configurationpipe理
升级和包装mngt
共享服务
用户authentication
内部DNS和DHCP
外部DNS
监控
操作系统级指标
服务水平指标
外部URL监控
报告
网站分析
可用性报告
操作系统级别统计
如果有什么遗漏，我会热衷于识别它。
PS我也会有兴趣在Excel或谷歌文档模板来跟踪这些项目。
你的文件清单是比较完整的。
对于格式，我的第一个build议是使它与你公司中的其他文档相匹配（如果你使用的是维基，那么它就是维基，如果你使用SharePoint，把它放在SharePoint等） – 你要确保人们会真正阅读（并更新）文档。
同样的，如果你的公司使用了特定的文档格式， 否则，我的build议是将每个练习区分成单独的文档（备份和恢复;供应和部署;监控和度量等…） – 使他们成为逻辑单元，可以有一个特定的人负责。
（请注意，“安全”是一个特殊情况 – 每一本其他书中都应该包含安全系统的实现和维护，而安全书应该只是推动实施的一般公司安全策略，这往往是一个更清洁/更多明智的设置，而不是让每个人都为安全簿而战，因为他们需要查找某些东西。）