IT文档平台

我们正在不断增长的IT运营,继续为各种客户提供更多的产品和支持。 随着我们继续保持这种增长,我们发现我们需要在IT团队中轻松访问有关我们各种系统和软件的信息和文档。 我们在IT部门有三个主要职能部门,其中包括:

  1. 服务台人员(一级),
  2. 开发人员和程序员,和
  3. 系统pipe理员/networkingpipe理员/安全分析员(第2层)。

目前,我们拥有基于MediaWiki的维基存储的一级信息,这已经被certificate对于服务台团队非常成功。 开发人员和程序员已经转移到Redmine来跟踪他们的项目,问题和项目文档。 pipe理员(第2层)没有一个集中的知识库,而是依赖于分散在networking驱动器,个人机器上的MS Word文件,因为他们没有logging在任何地方,所以只有特定的个人可以使用这些知识。

我们现在面临的挑战是我们需要有一个集中的位置来logging方法2的信息和文档。但是,我们还有两个其他系统已经到位。 理想情况下,我们希望拥有一个文档平台,可以在一级和二级工作的最低工作量以及将程序员join其中。 这个平台需要有能力保持某些内容的独立性。 例如,在第一层不需要知道的第二层级上有敏感信息(我们如何build立我们的服务器,可能的用户名等)。 此外,第2层应该能够访问第1层及以上的信息。 我们想过为此扩展MediaWiki安装,但ACL和维基用户的信息保护似乎是黑客的工作,没有得到很好的支持,违背了开放和方便访问维基核心信息的精神。 我正在寻找符合上述标准以及下列额外目标的想法和build议:

  1. 最好是免费或开源软件(和一个networking工具),因为我们没有真正的预算
  2. 一个不包含票务元素的平台,因为我们有一个独立的系统来处理一级和二级
  3. 一个平台,不需要一级和二级项目pipe理的能力
  4. 一个灵活的产品,易于添加文档,包括表格,简单的标记,语法突出显示,图像,networking图等
  5. 全文searchfunction可能具有自然语言function
  6. 支持file upload和下载的能力
  7. 可能有RSS或Atom提要和电子邮件更新警报
  8. 允许LDAP身份validation能够被集成到现有的SSO环境中
  9. 一个不需要太多开发时间或大量自定义代码创build的平台
  10. 基于用户,angular色,组成员身份,每个单独的文档/页面或一组文档/页面的访问控制,如果您无法访问站点/文档/页面/成员资格的那一部分,则看不到链接或内容
  11. 最好有一个内置的编辑器来帮助数据input和文档发布更容易
  12. 内置的版本控制和审计将是可取的
  13. 能够将页面或集合或页面导出为PDF文件
  14. 我们应该继续发展壮大,扩大规模
  15. 也许支持跟踪使用情况或执行分析的能力
  16. 仅供内部使用,不会面向客户或无法使用
  17. 支持pipe理信息摘要的能力,如操作方法,程序,解决scheme,项目,服务器版本,networking文档等
  18. 它不需要社交整合function
  19. 可能支持具有或添加到系统库存(服务器和客户机)
  20. 如果我们需要切换平台,则允许导入MediaWiki信息

此外,还有很多在线的地方讨论了专家系统,可以创build类似于stream程图或分步向导的故障排除工作stream程。 这是我们应该考虑在我们的文档平台作为一个选项吗? 这有多有用,这是否有助于一级scheme更好地执行工作? 网上也有一些资料介绍了内容pipe理和知识pipe理的区别。 这是我们应该考虑作为文档平台要求的一部分吗?

我知道这个post是一个更长的一个,我感谢您可以提供的帮助和反馈。 我试图确保我提出正确的问题,并提供基础,以帮助做出更明智的决定,并实施长期可行的解决scheme,以便我们不会继续重做我们刚刚实施。 再次感谢,我期待阅读你分享。

我知道这不是免费的,但我认为阿尔巴斯产品可以满足您的需求。 具体来说, Confluence Wiki可以帮助你的文档和JIRA模块可以做问题/错误跟踪。

不要过分简化,但Sharepoint浮现在脑海。

就个人而言,我会select维基(我喜欢Trac )或Plone 。

在以前的雇主中,我们使用Plone进行内部KB应用程序,支持具有一定的权限,pipe理有其他权限,而开发又有另一个权限。

就像SLY提到的,Jira和Confluence对此非常有趣。 在自由的一端,你会有Trac和它的相关插件。

然后再次,你正在寻找一个免费的厨房水槽,到目前为止所推荐的都不会提供所有需要的function。

如果你有一些额外的周期,你可以释放这个,Trac可以通过插件扩展,所以你可能会添加一些你需要的function。

我也看到一个wiki是最适合你的要求的。 维基百科对wiki软件与function,目标受众以及授权/成本等进行了很好的比较 ,所以除了其他答案中的build议之外,您还可以参考一下。

我会咬人

我与MoinMoin有过好运。 它是一个维基引擎,可以支持大部分您正在寻找的内容,并被某些大型组织(包括Ubuntu,Apache Foundation等)使用。但它包括ACL,LDAP集成,将页面导出为PDF,以及所见即所得的编辑器。 除了WYSIWYG编辑器之外,如果您希望使用它编辑页面,它还支持wiki标记语言。 所见即所得的界面还支持从Word复制和粘贴,以帮助您迁移现有的Word文档。

在过去,我使用它作为一个库存和系统历史平台,使用它的一些内置的macros和模板来允许你使用一个表单向wiki添加新的设备和事件。

我看到的唯一问题可能与您的要求是从mediawiki导入数据。 一些脚本确实存在,但边缘有点粗糙,并且是有限的。

当然,这听起来像一个维基是正确的路要走。 这里没有产品的terminal – 但是正如你所说的,有时候关键function在其实现上有点临时性(例如search不知道导致受限信息泄露的权限子系统)。

我使用了dokuwiki–它像大多数wiki一样在大多数框中打勾,但是它被很好地整合在一起,它还允许我非常容易地在页面上embeddedPHP(尽pipe对于一个数量非常大的系统的用户,你可以考虑添加一个自定义标签来引用维基以外的脚本,而不是直接访问解释器)。 它当然可以扩展以支持大量的用户,但基于平面文件,可以存储的数据量是有限的。

http://www.wikimatrix.org/wiki/comparison提供了一种快速检查function的方法。

Nuxeo拥有LGPL许可的开源文档pipe理解决scheme。

营销手段:

Nuxeo DM是一款使用灵活而强大的Nuxeo企业平台技术构build的文档pipe理解决scheme。 通过pipe理和跟踪整个商业周期的内容stream,Nuxeo DM解决了文档重复,缺乏版本跟踪,耗时search和检索以及安全和访问问题的常见缺陷。 为什么? 仅仅因为文档pipe理不仅仅是将文档存储在文件服务器上, 这是关于pipe理您的业务与内容交互的方式。 继续阅读,了解我们的客户为什么告诉我们,Nuxeo DM是其内容和文档pipe理计划的最佳解决scheme。

Alfresco也有一个文档pipe理解决scheme,但它是他们企业产品的一部分,而不是开源社区版。

Kablink Vibe中提供了许多您想要的function。

http://sourceforge.net/projects/kablink/

http://www.kablink.org/