我们在工作场所没有做任何文件。 我完全陌生，并要求一些指导入门。
我有几个问题：
什么是系统pipe理员应该编写和维护的基本文件？ 为什么这些如此重要？
你如何保持你的文档与系统同步？ 你如何最大限度地减less重复的信息？
推荐指南，最佳实践，反模式？
自2003年以来，我正在logging我们的内部维基的一切 。
服务器
工作stream程
例如如何添加或删除用户，并允许他/她访问所有相关的服务
重要的联系
紧急指示
如果intranetserver / internet / webserver / etc停机，该怎么做
重要：
select一个易于导出为PDF的wiki引擎！
如果你在假期，它不是有用的，运行你的wiki的服务器已closures，没有人知道该怎么办，因为你的文档是离线的
看看twiki，docuwiki或者mediawiki。
BTW：
有一个OOo插件直接写入mediawiki – 非常方便。
编辑：
它也很好地写下一些信息到/home/adminuser/maintenance 。 如果几个pipe理员在服务器上工作，这可以快速完成，并且可以非常有帮助。 例如：
2009-06-27 -thorsten- running aptitude update && aptitude full-upgrade everything seems ok 2009-06-25 -andreas- cups-pdf wasn't reachable. restarted cups 2009-06-23 -thorsten- deleted old log under /var/log/squid etc.
虽然你意识到，虽然每个人都想要（并需要）文档，但你也需要认识到，没有人有时间阅读和研究的东西。
因此，不要编写需要研究的文档 – 而应该以一种方式来构build文档，以便人们能够在需要时快速find所需的信息 – 这可能是在系统closures时，CTO是呼吸着他/她的脖子。
考虑到这一点，一些build议…
（1）不要创造一个真相的来源，强迫人们追捕它。 这个想法越重要，你应该重复的越多。
基本文件：
保持文档同步可以是一个“修复它，因为你看到错误的事情。 除此之外，还需要认识到文件可能会过时，而且不应该盲目追踪，而不考虑这一点。 文档可以帮助pipe理员完成任务，而不是一步一步地取代批判性思维的规则。
最大限度地减less重复 – 使用像wiki这样可以将文档链接在一起的东西可以帮助你做到这一点，而不是重复信息，你只需链接到它。 问题是编写文档的人需要知道他们即将复制的信息已经存在。 这通常是一个良好组织的问题。
我发现创build一个模板是一个很大的帮助。 在我的情况下，这是一个Word模板，但使用任何套房你。 创build一个框架文件，并根据需要填写目录字段和部分。 一旦你使用了它几次，并做了任何微调，你将会更快地创build新文档。 格式的一致性将对文档创build和以后的使用都有很大的帮助。 文档需要存储在合乎逻辑的位置和逻辑目录结构中。
我个人反对这样一个简单的事实，即它使得维护起来不必要的困难和耗时。 而不是复制文件或文件的一部分，在适当的地方创build对其他文件的引用。 如果有什么变化，你不应该再多修改一次，或者在多个地方修改相关的文档，否则你将会收集一系列冲突的文档，这对任何人都没有帮助。
在创build文档时，请记住它的用途。 稍后有人需要使用它。 在事先没有知识的情况下做这项工作可以使用吗？
不是你的问题的直接答案，而是一个正确方向的指针：
我发现Limoncelli和Hogan（系统pipe理员圣经） 的系统和networkingpipe理实践是相当有价值的，因为它是关于“最佳实践”问题，如文档。 如果您还不知道，请确保在有机会的时候进行调查。
对我而言，最重要的考虑因素是使其易于使用。 如果编排困难，人们会避免。 我selectTrac的wiki作为我们文档的媒介，原因如下：
位于中心位置。
任何一个文档的多个活动副本会导致混淆。 如果您能够将每个人都推荐给同一个地方，贡献者和受众，那么您可以简化stream程。
简单的编辑和格式。
如此多的时间浪费在漂亮的Word模板上，并符合最后作者的风格。 如果你不想让这些人陷入困境，那么编辑就更容易，贡献者更倾向于这样做。 用TracLinks尽可能多地分出项目。
审计历史。
什么时候以及为什么做什么改变是很重要的。 如果你可以将它绑定到变更请求票据和configuration提交日志，那么更好。 SVN提交钩子非常适合这个。