您如何记录您的工作、流程和环境？

评论工具。

我们尝试了在线 wiki，但发现了一些限制，这可能是个人喜好，但包括文档结构，最关键的是必须连接到文档服务器。

如果您离线或在现场，连接是一个严重的问题（显然，您可以使用安全的 SSL 连接等来缓解现场）

我们目前的文档流程是：

• 静态html生成器
• 降价语法
• 分布式版本控制系统

我们有一个“正式”的文档布局，它提供了菜单的结构（以及用于视觉样式等的相关 CSS）

静态 HTML 生成器

我们使用基于cubictemp和许多其他工具的内部静态html 生成器：pygments、docutils。

生成的页面（不是？）明显难看，因为我们大多数人/我们的系统管理员/程序员都知道什么是美学上的美丽，但在构建这样的页面时完全缺乏协调。

但它提供/让我们包含配置文件、示例脚本、pdf 等，而不必担心 html 格式会搞砸它或担心在“服务器”上的哪里可以找到它以供下载。

如果不是 HTML，只需将其放入文件夹并添加 url 链接即可。

HTML 为布局提供了“潜在”结构，并且还提供了知识/内容项之间的“链接”（以及基本结构机制，例如能够创建菜单、内容表等）。使用 HTML，每个用户现在都可以在他们的机器上运行一个小型 Web 服务器，无论是 lighttpd 还是其他小型服务器，或者只是使用 Apache 或 IIS 完全成熟。

我们所有的机器都支持基本的 html 服务，并且对我们来说运行良好。

MARKDOWN 语法。

我们使用 MARKDOWN、Textish 和/或reStructuredTEXT的混蛋版本让我们的“创意”果汁编写文档而不必担心 HTML。

这也意味着每个人都可以使用他们最喜欢的编辑器（我在 Windows 上使用 Scintilla 和 *Nix），而这里的其他人使用 vi/vim。

分布式版本控制系统。

我们使用Git在用户之间“分发”文档。哦，我们也使用它的版本控制能力。

对我们来说，主要优势是我们都可以更新文档，而无需连接到服务器，也无需发布“已完成”的作品。我们都可以处理文档的相同部分或不同部分，或者只是使用信息。

就个人而言，我讨厌被绑定到服务器来更新博客，更不用说维基了。Git 非常适合我们。

评论工作流程

Wiki 似乎是知识传播/编纂的“时尚”，但正如其他地方所评论的那样，所有流程都变得难以维持，找到最能支持您的团队需求且可持续的工具组合将需要时间。

更好的解决方案最终会被发现而不是强制执行。

我们已经开始在我工作的地方使用DokuWiki 。

来自 Dokuwiki 的网站：

DokuWiki 是一个符合标准、易于使用的 Wiki，主要用于创建任何类型的文档。它面向开发人员团队、工作组和小公司。它具有简单但强大的语法，可确保数据文件在 Wiki 之外保持可读，并简化结构化文本的创建。所有数据都存储在纯文本文件中——不需要数据库。

我发现 Dokuwiki 最容易实现，因为它不需要数据库，而且很容易设置。还有一些插件模块可以使用我现有的Active Directory 帐户登录，而不必为每个人创建帐户，这是我发现的许多其他 wiki 系统的巨大优势。它还具有典型的版本控制，您可以在其中查看谁在哪里发布了什么，并且如果需要，它还可以轻松回滚到以前的版本。它们还包括一个可定制的主页，您可以在其中轻松更改最适合您环境的任何类型的内容。

我们正在使用维基。事实上，我们正在使用 MediaWiki。在 MediaWiki 之上，我们安装了Semantic Mediawiki 扩展，它实际上将我们的 MediaWiki 变成了一个松散类型的数据库，我们可以使用类别、标题、内容等进行查询。

例如，假设我想查看通过集群 F 路由的所有网络 cname。我需要做的就是使用 Special:Ask 页面查询 [[Category:cname]] [[destination::cluster_f]] .. . 它将返回所有归类为 cname 且目标为 cluster_f 的页面。

我们支持数百个非常不同的客户，因此将这些文档放在一个中心位置（并将其交叉链接，以便特殊情况保持记录并与整体联系在一起）是一件非常方便的事情。显然，我们的文档需要维护，但您可以采取更多的“园丁”方法进行维护，因为用于保持大型数据集最新的 mediawiki 工具包已经相当成熟。

适合图表的其他内容的Doku Wiki或 Sharepoint。

您很快就会习惯在 wiki 上发帖，而且语法实际上并不那么复杂。组织信息非常容易，以后其他人也很容易找到它。

我使用 visio 制作图表以获得更清晰的解释（导出为 JPEG）。

使用正确的插件，Trac可以成为一个组合票和 wiki 系统。这使您的票很容易链接到 wiki 文章，反之亦然。

我喜欢的几个插件：

• 私人门票插件。Trac 被构建为一个错误库，所有票证及其响应都是公开的。这不适合 IT 票务系统，但这个插件解决了这个问题。
• Trac 所见即所得插件。让我们面对现实吧，大多数人不会为了让你开心而学习 wikisyntax。这为他们提供了一个“所见即所得”的工单和 wiki 页面编辑器。

Trac还有很多自定义设置。根据您的喜好设置和定制 Trac 系统并不难！

在我之前的工作中，我使用了 Twiki。它工作得相当好。

除此之外，我倾向于自动化大多数任务，并记录脚本（并不总是充满热情，但仍然......）。在设计脚本的过程中很容易记录脚本，所以没有真正的开销......

两者的结合（以及对脚本使用版本控制）做得相当好。

JIRA、Confluence 和 Word 文档的混合。

将知识制度化

我们从文件开始。然后我们将其中一些存储在 Sharepoint 库中。然后最近我们搬到了 Sharepoint wiki。我喜欢 wiki 在快速更新事物方面的低摩擦方法，尽管 Sharepoint 的 wiki 在图形支持和表格等格式支持方面留下了一些不足之处。文本很好，内置编辑器允许一些基本的 HTML 格式和有序/无序列表。Sharepoint 还有其他低成本的替代品。

我们的帮助台软件 Numara 的 Track-It 也为我们的支持票提供了某种非正式知识库。它并不完美，但它有效。

让员工使用制度化的知识

我同意你的评估，即让知识制度化只是战斗的一部分。如果您的组织和人员不习惯“先研究，后问”，那么您会发现旧方法盛行：每个人仍然会向正式和非正式的大师寻求答案，而对于某些人来说，提问总是更容易你旁边的人比你自己搜索。

处理这个将涉及一些变更管理；就像大多数成功的变革计划不仅仅影响一个小团队一样，获得管理层的认可和支持也会有所帮助。你真的必须在两个方向上建立新的行为；有人需要捕捉知识，人们需要使用它。更难的是，人们还需要保持这些数据是最新的。

只是一些想法：可能需要以正式政策的形式进行鼓励，说明解决的票证和问题需要在知识库或维基中记录，然后才能被视为关闭。此外，通常被问到问题的知识领导者不应该总是根据要求提供答案；他们需要将人们指向维基并让他们习惯于先在那里查看。另一件事是让用户可以使用数据进行自助，这样问题就有可能在成为技术人员必须处理的另一个项目之前得到解决。

我们的帮助台系统最好有一个类似于 StackOverflow 和 ServerFault 的系统：输入问题时，搜索引擎会找到类似的项目并提供它们，因此用户甚至可以在提交问题之前查看它们。

在我最近的两个工作中，我使用了 Sharepoint 的 Wiki，以及一个包含某些文档（例如 DRP 和一次性升级计划）的文档库，这些文档不能轻易地创建为 Wiki 文档。这些文件有来自 Wiki 的链接。Wiki 在这方面有很多优势，因为很多人可以编辑它，版本控制是内置的，易于搜索和访问等。为了快速写下笔记或想法，我会使用 OneNote 或白板。

我之前创建了一些知识库，以论坛格式（包括 Lotus Notes 和 MS Sharepoint），但我必须说，很少有人通过它们查看某个问题是否已经解决。这样的解决方案必须从一开始就拥有一个非常强大和有效的搜索引擎。

如果您想创建可以在假期使用的文档，请将它们写成好像您正在尝试指导您的一位父母一样。这不是 100% 万无一失的，但有时会有所帮助。取决于谁在读它。

共享点很好。

它的搜索功能能够索引几乎任何类型的文档，使搜索文档变得非常容易。

它也可以做一些模板化，这可以使事情变得更容易，例如，如果您为您构建的每个服务器都有一个标准信息表。

它还可以为您的文档版本化，以便您拥有文档更改的审计历史记录。

此外，文档库中包含的文件可以通过 Web、Outlook 或 unc 共享直接访问。