我们将以下工具用于不同类型的文档：

• RackTables - 保存物理机架布局、布线、资产跟踪、IPAM（IP 地址管理）和更改日志。
• Rancid - 自动将所有配置更改从我们所有的交换机、路由器和防火墙备份到 SVN。这提供了自动文档和更改跟踪。
• MediaWiki - 所有代码片段、程序和详细的客户信息都记录在 wiki 表单中，因为在提供良好的版本历史记录的同时，所有人都可以轻松编辑。
• GitHub - 所有大型配置集（例如Nagios或Bacula）都存储在 GitHub 的私有存储库中。大约一年前，我们从 SVN 迁移到 Git，因为它提供了非常出色的跟踪和委托维护。

与其关注您使用的几个工具，不如关注哪种类型的数据值得记录。

我发现最容易被忽视的文档是“为什么”文档，它应该是标准文档的配套文档。这个“为什么”文件将描述被审查的设计选项以及做出选择背后的原因。几个月或几年后，您可以回顾一下，看看推理是否仍然合理，并根据需要进行更改。它还可以通过总结反对替代设计的论点来防止旧论点的重复。

工具

我们目前正在使用私有 SVN 服务器进行知识文档。我们的团队小而精明（包括最熟悉 SVN 的人，包括向 Apache Subversion 项目提交代码的人）。我们还跟踪其他领域的知识。请记住，我们的运营规模很小（只有几个人），因此重点是协调并确保我们不会忘记我们不应该忘记的事情。

我们正在（可能需要一些时间）完全集成 CMS/FAQ/等，跟踪我们的 ERP（这是我们存储详细客户信息的地方），但这可能需要相当长的时间。我们的目标之一是建立一个高度集成的系统，其中 ERP 中的更改会自动发布到网络（在网络和主机级别），并且知识和信息与此紧密相关。

利用

关于网络工程，我们有两个关键方面，即定期审查（记录很好，但如果您不定期对其进行处理则毫无用处）。这在涉及安全知识时尤为重要。我们目前担心的威胁状况是什么？我们在做什么呢？这些东西中的任何一个都可以改进吗？

一般来说，文件化的知识应该是可审​​查的和定期审查的。

我认为文档是基本的，所有的答案（尤其是Mike的一个恕我直言）都指出了这样做的很好的理由。

我想补充的是，我认为工具的选择应该以“受众”为基础。也就是说：如果需要为他和一些同事记录一个开发的模拟器，也许GitHub就足够了。但是，考虑在同一模拟器应该在学术课程中使用的情况下：那么，也许，这是值得提供给学生也是一个粗略的说明指导解释的基本功能。