你使用维基格式吗？如果有，是什么产品？（MediaWiki、Confluence、Sharepoint 等）
您是否创建了知识库？（面向问题/解决方案的简短文档。）
您在创建有效的文档时遇到了哪些挑战，因此您在休假时不会接到电话？
对我来说，我发现完成文档通常涉及一定程度的组织“惯性”。似乎是不同类型的人可以完成一项任务，然后考虑他们如何完成任务并描述它以便其他人可以完成 - 对你来说是一种“变元”的力量，并不是每个人都愿意这样做。
更新
到目前为止的答案包括
编辑：你不是用你的监控系统隐式记录你的网络吗？Nagios 一直鼓励使用parent指令来反映您的网络结构，notes_url指令旨在允许您链接到 wiki 或其他基于浏览器的文档。因此，此处的“文档”分为监控系统的“活动文档”和 wiki 中更详细的离线文档。因为我花了很多时间盯着 Nagios，所以努力让它尽可能提供信息是有意义的。
我们尝试了在线 wiki，但发现了许多限制，这可能是个人喜好，但包括文档结构，最重要的是必须连接到文档服务器。
如果您离线或在现场，连接是一个严重的问题（显然，您可以通过安全的 SSL 连接等来缓解现场问题。）
我们目前的文档流程是：
我们有一个“正式”的文档布局，它提供了菜单的结构（以及用于视觉样式等的相关 CSS）。
我们使用基于cubictemp 的内部静态html 生成器和许多其他工具：pygments、docutils。
生成的页面（不是？）显然很难看，因为我们/我们的系统管理员/程序员中的大多数人都知道什么是美学上的美丽，但在构建这样的页面时完全缺乏协调。
但它提供/让我们包含配置文件、示例脚本、pdf 等，而不必担心 html 格式将其搞砸或担心在“服务器”上的何处可以找到它进行下载。
如果它不是 HTML，只需将其放入文件夹并添加一个 url 链接即可。
HTML 为布局提供了“潜在”结构，并且还严格提供了知识/内容项之间的“链接”（以及基本结构机制，例如能够创建菜单、内容表等）。使用 HTML，每个用户现在都可以在他们的机器上运行一个小型的 web 服务器，无论是 lighttpd 还是一些小的东西，或者只是用 Apache 或 IIS 来全面发展。
我们所有的机器都有基本的 html 服务，并且对我们来说工作得很好。
我们使用 MARKDOWN、Textish 和/或reStructuredTEXT的混蛋版本让我们的“创意”果汁编写文档而不必担心 HTML。
这也意味着每个人都可以使用他们最喜欢的编辑器（我在 Windows 和 *Nix 上使用 Scintilla），而这里的其他人使用 vi/vim。
我们使用Git在用户之间“分发”文档。哦，我们也使用它的版本控制能力。
对我们来说，主要优势是我们所有人都可以在无需连接到服务器的情况下更新文档，也无需发布“已完成”的作品。我们都可以处理文档的相同部分或不同部分，或者只是使用信息。
就个人而言，我讨厌被绑定到服务器来更新博客，更不用说维基了。Git 对我们很有效。
Wiki 似乎是知识传播/编纂的“时尚”，但正如其他地方所评论的，所有流程都变得难以维持，并且找到最能支持您的团队需求且可持续的工具组合需要时间。
更好的解决方案最终会被发现而不是强制执行。
我们已经开始在我工作的地方使用DokuWiki。
来自 Dokuwiki 的网站：
DokuWiki 是一个符合标准、易于使用的 Wiki，主要旨在创建任何类型的文档。它针对开发人员团队、工作组和小公司。它具有简单但功能强大的语法，可确保数据文件在 Wiki 之外保持可读，并简化结构化文本的创建。所有数据都存储在纯文本文件中——不需要数据库。
我发现 Dokuwiki 最容易实现，因为它不需要数据库，而且很容易设置。还有一些附加模块可以使用我现有的Active Directory 帐户登录，而不必为每个人创建帐户，这比我发现的许多其他 wiki 系统要好得多。它还具有典型的版本控制，您可以在其中查看谁发布了什么内容，并且可以在必要时轻松回滚到以前的版本。它们还包括一个可定制的主页，您可以在其中轻松更改最适合您环境的任何类型的内容。
我们正在使用维基。事实上，我们正在使用 MediaWiki。在 MediaWiki 之上，我们安装了Semantic Mediawiki 扩展，这实际上将我们的 MediaWiki 变成了一种松散类型的数据库，我们可以使用类别、标题、内容等进行查询。
例如，假设我想查看通过集群 F 路由的所有网络名称。我需要做的就是使用 Special:Ask 页面查询 [[Category:cname]] [[destination::cluster_f]] .. . 它将返回所有归类为 cname 且目标为 cluster_f 的页面。
我们支持数百个非常不同的客户，因此将这些文档放在一个中央位置（并使其交叉链接，以便特殊情况保持记录并与整体联系起来）是一件非常方便的事情。显然，我们的文档需要维护，但您可以采取更多的“园丁”方法进行维护，因为用于保持大型数据集最新的 mediawiki 工具包已经相当成熟。
在我之前的工作中，我使用了 Twiki。它工作得相当好。
除此之外，我倾向于自动化大多数任务，并记录脚本（并不总是充满热情，但仍然......）。在设计脚本的过程中很容易记录脚本，所以没有真正的开销......
两者的结合（以及对脚本使用版本控制）很好地解决了这个问题。
将知识制度化
我们从文件开始。然后我们将其中一些存储在 Sharepoint 库中。然后最近我们转移到了 Sharepoint wiki。我喜欢 wiki 在快速更新内容方面的低摩擦方法，尽管 Sharepoint 的 wiki 在图形支持和表格等内容的格式支持方面留下了一些不足之处。它适用于文本并且内置编辑器允许一些基本的 HTML 格式和有序/无序列表。Sharepoint 还有其他低成本的替代方案。
在我们的帮助台软件 Numara 的 Track-It 中，我们还为我们的支持票提供了一个非正式的知识库。它并不完美，但它有效。
让员工使用制度化的知识
我同意你的评估，即让知识制度化只是战斗的一部分。如果您的组织和人员不习惯“先研究，后提问”，那么您会发现老方法占上风：每个人仍然会向正式和非正式的专家寻求答案，而对于某些人来说，提问总是更容易你旁边的人而不是自己搜索。
处理这个将涉及一些变更管理；就像大多数成功的变革举措不仅仅影响一个小团队一样，获得管理层的认可和支持会有所帮助。你真的必须在两个方向上形成新的行为；有人需要获取知识，人们需要使用它。更难的是，人们还需要使数据保持最新。
只是一些想法：可能需要以正式政策的形式进行鼓励，声明解决的票证和问题需要在知识库或维基中记录，然后才能被视为关闭。此外，通常会被问到问题的知识领导者不应该总是根据要求提供答案；他们需要将人们指向维基并让他们习惯先在那里查看。另一件事是向用户提供数据以进行自助，以便在问题成为技术人员必须处理的另一个项目之前解决问题。
对于我们的帮助台系统来说，最好有一个类似于 StackOverflow 和 ServerFault 的系统：在输入问题时，搜索引擎会找到类似的项目并提供它们，这样用户甚至可以在提交问题之前查看它们。
小智 -3
卡塞尔文献展——什么？我们不需要任何文档！
这可能是一种糟糕的做法，但它与大多数 IT 组织中的课程相同。没有时间，没有预算，不想写。