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

您使用的是Wiki格式吗？如果是这样，哪个产品？（MediaWiki，Confluence，Sharepoint等）

您是否创建了知识库？（面向问题/解决方案的简短文档。）

创建有效的文档会给您带来哪些挑战，从而使您在休假时不会接到电话？

对我来说，我发现完成文档通常涉及一定数量的组织“惯性”。似乎是另一种可以完成任务的人，然后考虑他们如何完成任务并描述它以便其他人可以执行它-一种对您“施加影响”的力量，并不是每个人都乐于这样做。

更新资料

到目前为止的答案包括

• 合流
• Flexwiki
• 福布兹
• Mediawiki（带有fckeditor等插件）
• 共享点
• 维基百科
• Word / Excel / Visio文档
• 记录脚本

编辑：您不是通过监视系统隐式地记录您的网络吗？Nagios一直鼓励使用parents指令来反映您的网络结构，并且notes_url指令旨在允许您链接到Wiki或其他基于浏览器的文档。因此，此处的“文档”在监视系统的“活动文档”和Wiki中更详细的脱机文档之间划分。由于我花了很多时间盯着Nagios，因此尽最大努力使它具有更多信息是有意义的。

评论工具。

我们已经尝试了在线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和* Nix上使用Scintilla），而这里的其他人则使用vi / vim。

分布式版本控制系统。

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

对我们而言，主要优势在于，我们都可以在无需连接到服务器的情况下更新文档，而不必发布“已完成”的作品。我们都可以处理文档的相同部分或不同部分，或者仅使用信息。

就个人而言，我讨厌被服务器绑定以更新博客，更不用说维基了。Git对我们很好。

评论工作流程

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

更好的解决方案最终被发现并且没有被强制执行。

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

在Dokuwiki的网站上：

DokuWiki是符合标准且易于使用的Wiki，主要用于创建任何类型的文档。它针对开发人员团队，工作组和小型公司。它具有简单但功能强大的语法，可确保数据文件在Wiki外部仍然可读，并简化了结构化文本的创建。所有数据均存储在纯文本文件中-无需数据库。

我发现Dokuwiki最容易实现，因为它不需要数据库，并且易于安装。还有一些附加模块，使它们能够使用我现有的Active Directory帐户登录，而不必为每个人创建帐户，这对我发现的许多其他Wiki系统来说都是一个巨大的优势。它还具有典型的版本控制功能，您可以在其中查看谁在何处发布了什么，并且可以根据需要轻松地回滚到以前的版本。它们还包括一个可自定义的主页，您可以在其中轻松更改最适合您的环境的任何类型的内容。

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

您很快就习惯了在Wiki上发布内容，语法实际上并不那么复杂。组织信息非常容易，以后其他人也可以轻松找到。

我使用visio制作图形，以获得更清晰的说明（导出为JPEG）。

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

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

我们为数百个非常不同的客户提供支持，因此将文档集中放在一个中心（并使其相互链接，以便使特殊情况保持文档记录并捆绑到整个文档中）是一件很方便的事情。显然，我们的文档需要维护，但是您可以采用更多的“园丁”方法进行维护，因为用于保持大型数据集最新状态的mediawiki工具包已经相当成熟。

使用正确的插件，Trac可以成为票证和Wiki的组合系统。这样，您的票证就可以轻松链接到Wiki文章，反之亦然。

我喜欢几个插件：

• 私人门票插件。Trac的建立是一个错误库，所有票证及其响应都是公开的。这不适用于IT票务系统，但此插件可以解决该问题。
• Trac所见即所得插件。面对现实吧，大多数人不会学习让您开心的wiki语法。这为票证和Wiki页面提供了一个“所见即所得”编辑器。

有相当多的多的Trac的自定义设置。设置和自定义Trac系统并不难！

在之前的工作中，我使用了Twiki。它运作良好。

紧接着，我倾向于自动化大多数任务，并记录脚本（并不总是很热情，但仍然...）。编写脚本很容易在设计过程中完成，因此没有真正的开销...

两者的结合（以及对脚本使用版本控制）都很好地完成了这个技巧。

JIRA，Confluence和Word文档的混合体。

制度化知识

我们从文档开始。然后，我们将其中一些存储在Sharepoint库中。然后最近我们移到了Sharepoint Wiki。我喜欢Wiki的低摩擦方法来快速更新内容，尽管Sharepoint的Wiki在图形支持和格式支持（例如表格）方面仍有一些不足。文本很好，内置编辑器允许一些基本的HTML格式和有序/无序列表。Sharepoint还有其他低成本的替代品。

我们的帮助台软件Numara的Track-It还为支持票提供了非正式的知识库。这不是完美的，但可以。

让员工使用制度化的知识

我同意您的评估，即将知识制度化只是战斗的一部分。如果您的组织和人员不习惯“先研究，再询问”，那么您会发现旧的方法占了上风：每个人仍然会向正式和非正式的专家寻求答案，对于某些人来说，询问总是很容易的您旁边的人比您自己搜索。

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

只是一些想法：可能需要采取正式政策的形式鼓励人们，说明已解决的故障单和问题需要在知识库或Wiki中记录下来，然后才能视为已关闭。此外，通常会被问到问题的知识领导者不应该总是按要求提供答案。他们需要将人们指向Wiki，并让他们习惯于首先查看Wiki。另一件事是将数据提供给用户以进行自助服务，以便在该问题成为技术人员必须解决的另一项问题之前，可以解决该问题。

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

在我的最后两个工作场所中，我使用了Sharepoint的Wiki，以及一个包含某些文档（例如DRP和一次性升级计划）的文档库，这些文档无法轻松地创建为Wiki文档。这些文档具有Wiki中的链接。Wiki在此领域具有许多优势，因为许多人可以对其进行编辑，内置版本控制，易于搜索和访问等。为了快速写下笔记或想法，我将使用OneNote或白板。

之前，我已经以论坛格式（以Lotus Notes和MS Sharepoint的形式）创建了一些知识库，但是我必须说，只有很少的人正在浏览它们，以查看是否已经解决了某个问题。这样的解决方案必须从第一天起就具有非常强大和有效的搜索引擎。

如果要创建可以在假期使用的文档，请像试图指导一位父母一样编写文档。这不是100％防呆，但有时会有所帮助。取决于谁在阅读。

共享点很好。

它的搜索功能可以索引几乎所有类型的文档，从而使搜索文档变得非常容易。

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

它还可以为您对文档进行版本控制，以便您拥有文档更改的审核历史记录。

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

我们已经使用MediaWiki（与fckeditor一起使用）已有几年了，尽管我必须说，如果图片（即屏幕截图）的处理更加容易，那就太好了。尽管具有搜索能力至关重要，但我发现MediaWiki的搜索经常会遗漏页面。也许这只是学习更好地搜索的问题（这违背了以简单的方式让他人完成您的工作的目的）

目前，我们正在讨论将所有内容移至MS Sharepoint的想法，尽管不一定是他们的Wiki。我认为，Sharepoint能够以否定Wiki某些优势的方式进行完整文档搜索，因此我们将了解其发展方向。

（尽管不希望移植当前所有文档的过程：））

我们正在使用维基。当然语法需要一点时间来习惯，但是我们正在使用的（twiki）完全将其数据存储为文本文件。这使我们能够在发生灾难时轻松读取它们，因为我们可以将它们还原到任何地方，并通过grep在命令行中搜索它们，然后在我们喜欢的任何文本编辑器中读取它们。

每个服务器都有一个页面，其中包含标准的子页面集合，这些子页面包含变更管理信息，启动/关闭和配置说明，以及dns，防火墙和资产信息。

我们正准备迁移到某个版本的Sharepoint服务，以尝试使我们摆脱散布在三台服务器上的Word文档的混合，并且谁知道多少文件夹。当前，我们有一个庞大的excel电子表格，其中包含指向其中描述的文档的超链接。

这不是最好的方法，但是当公司成立时，他们从未计划过如何处理内部文档，而是让每个小组来决定如何分类和存储自己认为合适的文档。现在，我们正在尝试合并到一个统一的系统中，该系统将围绕Sharepoint产品之一提供。

在我工作的NGO中，我们只使用放置在文件夹中的文本文件来执行关键程序。作为系统管理员/ Web开发人员的混合体，我一直使用分散在树形目录中的文本文件的知识库，这就是我的Memex，我几乎在上面写下了所有内容（个人，工作等）。使用真正的瑞士军刀Jedit进行文本处理时，此方案非常易于管理，我发现它的轮廓插件，代码折叠和超级搜索功能是必不可少的。所有这些都可以通过rsync安全地备份到ssh可访问的远程服务器。

结合使用Makelink Firefox Extension，您将拥有完美的书签管理器。

我们使用flexwiki，这是一个dotnet和开放源代码。

恩... Fogbugz怎么样？:)

我们正在使用ScrewTurn获取内容，并使用SharePoint来存储文档/图像。

还有一些有趣的事情在这里 -我喜欢在一个安全的密码之一。

我们使用文本文件组合来使用grep快速搜索。和SharePoint，以获得更有条理的深入文档集合（Visio图表等）。

作为Google Apps（Enterprise）客户，我们使用Google Sites的特长-他们的Wiki“风味”。易于使用，我们已被管理员和开发人员广泛采用。

在回答另一个问题之前，我没有看到这个问题，但是现在开始。

我们使用许多工具和方法。

• 基础结构组件和软件的功能规范。
• 两个合流维基。一种用于内部公司文档（策略，过程，内部基础结构和IT等），另一种用于我们的开源软件产品。
• RSpec和黄瓜测试。我们的软件主要是用Ruby编写的，并且我们练习BDD / TDD，因此规范测试可以驱动实际的代码和文档。
• 内联代码文档。我们在代码注释中使用RDoc标记。
• 声明式配置管理（Chef）。我们所有的服务器都由Chef管理，Chef通过食谱和食谱中的替代性资源“自我记录”。

我们喜欢Confluence，因为它非常灵活，功能强大且功能齐全，而且它与我们喜欢的票务管理软件Jira绑定在一起。

在我工作过的以前的公司中，我使用了各种各样的工具和方法，并且许多公司都试图将单一的万能资源（例如Wiki）用于所有工作。这样做的问题是，使用一个单一工具来记录各种主题，而该工具并不特别适合于覆盖该主题，这意味着很多东西根本不会被记录下来，因为很难迁移信息。作为Unix / Linux极客，我相信每个任务都需要一个特定的工具，并且该工具应该非常适合该任务。

这个问题很好地重复了这个问题，我将答案移到了那里。

我负责公司的大部分文档，在这里开始工作时所建立的格式是MS Word，表示可编辑的原件，导出为PDF，表示只读的常规版本。对于仅由一个人来更新文档的项目来说，它工作得很好，并且由于该人通常是我，因此管理层不需要更改。

我们已经开始使用Trac记录我们的错误和即将发生的任务，同时使用“同行评审”扩展进行代码评审。这很容易被我们的团队接受，因为它的协作简单并且易于导航。其他一些团队成员表示希望开始与规范，测试程序和手册进行更多的协作，因此我们正在研究将DocBook / XML导出为PDF以用于手册之类的公共文档，以及Trac WIKI页面以获取诸如规范和文档之类的内部文档。测试程序。

在我看来，选择文档格式时遇到的最大问题是：

1. 创建起来容易吗？
2. 容易维护吗？
3. 如果别人写的话容易维护吗？
4. 可以轻松地将其导出/转换为其他格式吗？

1-3使我的生活更轻松，并且对于快速制作文档而又不致于发疯很重要。我认为第四个是客户端最重要的，因为格式会不断变化。Microsoft Word 2003格式不会永远存在，我们当前的PDF实现也不会永远存在。我需要确保我们所有的客户都能阅读我们的文档，无论他们的操作系统或文档选择器是什么。

我们将MediaWiki与各种插件一起使用，包括SemanticMediaWiki。SMW很不错，因为它将我们的MediaWiki安装变成了一个可以自由查询的大型，自由格式的关系数据库。是否需要知道网站在哪台服务器上？访问它的页面。是否需要知道服务器上托管了哪些网站？运行一个查询，它将根据每个网站页面上的适当标签挑选页面名称。

我不会用我曾经使用过的文档系统来回答，而是会使用我看到过的并且觉得非常好的东西来回答：http : //stackexchange.com/

stackexchange是在serverfault下运行的问答平台（从技术上讲，它并不完全相同，但是出于我们的目的，我们可以假定它是相同的）。

Fogbugz 使用它。

有一个来自Fogbugz员工的有趣的博客文章，我在其中找到了这些引文：

对于产品规格以外的所有用途，我认为公司Wiki和讨论表已受到致命的打击。

...

自从我们开始使用FogBugz.StackExchange.com作为我们的支持平台以来，我从未两次回答相同的问题。我们甚至有一个内部SE服务器，用于非公开的问答环节，同样的原则也适用于此。

他们将stackexchange用于面向客户的知识库和内部知识库。

我很想知道这种知识交流问答平台是否会取代公司Wiki。

在我以前的雇主那里，我使用一起收集在一个文件夹中的Word，Excel和Visio文件。一切的硬拷贝都放在我办公桌的活页夹里。我是唯一的IT人员，因此几乎没有其他人可以访问该信息。

在我当前的雇主中，我们使用Exact Software的Macola ES，但与使用内置文档编辑器相比，我仍然更喜欢用Word编写文档并将其作为附件上传到Macola。

在我的工作场所，我将ScrewTurn Wiki放到了其中一台Windows开发服务器上，并将其连接到我们的SQL Server。它确实运行良好，运行迅速，并且在很大程度上不影响我们进行文档编制。自部署以来的两周内，我们已经添加了约60页信息，仅适用于我们的团队（约10人）。

到目前为止，我们在那里保留有关当前和过去项目的信息，并已开始添加有关应用程序的信息，例如如何从头开始构建它们，URL以及开发人员新的重要信息。

我在Wiki上最喜欢的页面之一是“工具和库”页面。在那里，我们开始添加有关我们常用的生产力工具和库的信息，其中很多就是grepWin的示例，用于Windows中的文本搜索。

我会完全建议您查看Wiki的全部内容，并找到适合您预期用途，功能和部署环境的内容。我选择ScrewTurn是因为它易于使用，并且在本地WinServer上有大量的免费空间，但YMMV。

在某些情况下，我们将Confluence用作Wiki和文档的共享点。我认为，当您需要真正广泛地共享此信息时，在线Wiki格式是一种首选格式，而当文档要经常编辑和更新时，更重要的是。因此，我认为知识库文章最好放在Wiki中。

我们目前正在将信息从网络上散布的各种文档移到两个位置：

1. 我们内部网上提供的Wiki
2. 与该服务器/ root目录中的特定服务器相关的信息的副本。

对于网络图，请使用“ 网络记事本”。

另外，在记录内容时，请记住记录为什么配置了类似的内容。这有助于防止看似好主意的想法变成错误。

我们发现MediaWiki的启动速度很慢，但是一旦IT部门以外的人对添加评论，更改，编辑等变得如此容易，它就变得不可或缺。开发人员正在将其用于内部文档和设施部门。用于发布通知等。它已不仅仅是一个IT文档工具而已。