文档知识库的演进和小结

本文是今天下午在我的自动化运维群做的分享,群里每天都有一到两个主题的分享,目前来看效果还不错。正文如下:

我看过很多公司的知识库,干脆叫它文档库也可以。总体来说,知识库在很多公司的角色比较尴尬,不被重视,但是大家都希望有。

如果从我的工作中碰到的知识库来说,我觉得之前的外企Amdocs的知识库做得最好,文档有一个统一的ID,跟进这个ID能够搜到指定的文档,这个知识库是基于B/S的架构,集成了权限管理,还有部分的文旦预览功能,基本上大家能够想到的功能,那里都有。

而国内的很多公司中,发现知识库的建设还是有限,有些公司是基于svn,但是缺点很明显,文档的搜索,可视化功能不够好。

还有其他的工具,很多都是基于c/s架构,总体来说,使用效果会比较受限

所以现在你去看有些公司,越来越多的会用基于wiki的文档知识库,但是这个也是相对的。我来说一下我的想法。

建设文档库的过程中,有下面的几个地方需要注意。这些也是我今天要简短分享的脉络。

绝大多数公司的文档库都是半成品,如果重新够构建一个,那么想法肯定是很远大的,希望目录丰富,功能更好,工作效率也能够极大提高。

简单说下之前的文档库的情况,之前的文档库是比较简单的,基于seafile,文档的目录比较简单,就分了几个数据库,文档也缺少很多,所以大家也希望能有一个全面完整的知识库,这个也是boss的想法。所以,需要有人来规划做这个事情。

这个是我最初规划的文档知识库。

目录还算是比较全的,主要分为了六个大的板块。架构选型,日常管理,流程规范,平台建设和知识分享和团队建设。

对于里面的内容我们内部也讨论了很多次,最后发现大家都会陷入这样一个漩涡,那就是应该是技术线还是业务线,因为有些技术文档是基于具体业务的,那这个文档到底该怎么归类。

我们做了很多讨论,先拍板按照我设想的来做,大家可以提供建议,所以我设计的时候主要是从技术方向来入手,日常管理这个部分是希望放入一些业务层面的文档。

原来的方案不好,那就改进吧,发现大家的想法其实很简单,就是希望把文档存储起来,哪种形式其实都能接受。

总体来说,考虑了上面的几个方案,有些也做了测试,但是发现总是有一些细节和实际的需求有较大的出入,所以知识库的方案就花了一些时间来调研和确认。

公司的项目管理部有一个平台,说是基于wiki的,我们商量了一下,说自己建有些麻烦,有现成的就用吧。于是我们把已有的目录结构拿去和项目管理部的同事聊。

聊到第三次,我突然发现,这个方案不可行,因为项目管理部用的wiki系统是公共平台的,接一个知识库,从他们的角度来说,希望是一些公共达成共识的文档,而且权限控制和目录结构上都是有专人来维护的。而且从项目管理部的角度来说,他们的目录结构是分成了三个层次,是面向全公司的所有部门的,这样一来,不光我们原有的文档库要重新组织,而且很多内容都要商量要怎么对接,看起来简单的知识库要落地就遥遥无期了。

所以这样一个事情之后,我聊完之后就不主动发起了讨论了。我决定我们内部先得迭代完成文档库,截至那个时候,虽然文档库达成了目录结构,讨论了方案,但是还没有实际的文档真正被管理起来。

所以这个情况比较尴尬,而团队内部讨论的时候,我算是夹在中间需要两边协调。反正文档没出来,大家怎么说都行。

而说实话,我不喜欢这样,讨论一个不存在的事情,而且都脑洞大开,落不到实处,做这个事情的意义和动力都会大打折扣。

所以我们再次讨论的时候,我就提了一个概念,算是自创的0-1,1-99理论。

任何事情我们要做,做的过程中就不要讨论这么做的意义了,好与不好,怎么讨论都很难出结果,落不到实处都是虚的。所以从0到1,得让它先有,然后我们再讨论优化和改进。

而有了这个东西之后,持续的优化才是不断迭代的,没有一个东西是一下子就做好的。单纯借助某一方的力量最后发现该走的路还是得走一遍。

所以本来大家要讨论接下来要不要做文档库,怎么接入项目管理部的时候,我重新规划了下面的几件事情。

现有的seafile已经有了,本身还是有一些有点的,比如可以类似网盘一些存文件,一些比较大的文件尤其合适。我们可以先用这个平台来迭代。

然后梳理知识库目录结构。大家后面还是会有不同的声音,比如有的同学做业务多,文档多是业务的,有些同学纯做技术的文档多,两者之间很难完全统一。

所以我们提议的快速迭代,就是不管你是基于那种考虑,业务线还是技术线,我给你单独建立一个目录,目录结构可以参考我之前提的目录结构,但是你可以改,按照你的理解来重新组织。

这样就是责任分包,每个人都有一个单独的目录,每个人都维护自己的一个小的文档库,这个时候,大家彼此都很难看到彼此的文档,因为seafile本身还不支持搜索,除非你知道那个目录。

还有一个好处就是,有了这个专属的目录,我就能看到谁那天提交了文档,哪些人还没有提交。

所以我划分成了3个阶段:1,seafile快速迭代 2.基于初始的结构查漏补缺,3.然后组织讨论,看看接下来怎么走。

第一个阶段算是每个人我都口头交代了,而且实际上还是一个人一个人的去跟进,所以想想如果团队有几十上百号人,要落地这样一个事情有多难。

第二个阶段,总体来说,完成的效果一般。大概是2周之后,到了月底的时候,开会讨论,初步的文档目录结构是有了。那么我们接下来就是看看怎么让文档发挥价值。

开完会之后,我就在琢磨怎么去改进这个文档库,首先的方案是基于b/s,这个时候wiki的想法又冒了出来,我调研了一圈,有confluence,xwiki,还有mediawiki等。

最后就拍了xwiki,也就是接下来要给大家介绍的文档知识库的一个雏形。

这个是当时和大家讨论后的一个小结。

xwiki的架构是基于Java线,很多人不熟,我的考虑是不熟我比较熟,所以就先花了个把小时来测试了。

xwiki是一个开源项目,当然也有企业支持服务,国内也有一个xwiki的中文网站。

这些技术我之前都接触过,所以还算是比较熟的。配置和部署,改动,在元旦放假前的周五下午就搞定了。

xwiki可以支持很多文档类型,亮点之一就是支持很多插件,这个插件和大家理解的atom,vscode的插件还不大一样,量级也要少很多。总体来说已经算不错了。

xwiki还有个博客功能,这是之前没有想到的,自带了这个功能也算是一个小的福利吧。团队用不用就看个人的习惯了。

当然xwiki的亮点在于强大的搜索功能,底层是用solr来做的。

搜索pdf,ppt,word,xmind等等文件,能够根据关键字都搜索出相关的结果,这个是强大的地方。

这样一来,就符合IT人懒的方式了,不用费心费力的去把各种类型的文档全部转换一遍。让solr来做就好了。

所以这样一来会发现以前未曾发现的文档,竟然根据关键字也能找到一些联系.

当然还有个优点,就是可以根据很多的过滤条件来筛选。这个就很方便了。

搭建的过程,可以参考之前的一篇文章。

搭建知识库xwiki

而且说实话,经历的阶段比我提到的要多。经历了Django Admin,Django Suit,然后都不满意的情况,才走到现在的这个阶段。

当然目前的算是一个1.0的版本,我来简单说下如何做xwiki的迁移,为什么这么说,因为xwiki的插件是基于网络下载的,我们的工作环境很可能是没有这些网络的。

总体的思路就是在测试环境部署tomcat和war包,然后下载插件,插件都下载好以后,直接把整个目录都拷贝到内网的环境中,然后把已有的数据都迁移出来,这里用的数据库是mysql,导出导入即可。整个迁移用了一上午就做完了。

工程的难度就是对于插件的裁剪,因为xwiki支持很多插件,其实不是所有的我们都需要,最后我裁剪剩下的也就不到5个插件,其他的目录结构统统都去掉。

接下来的事情就是所有文档的接入,这个部分我做到了为人民服务的宗旨,我把大家已有的目录和文旦都从seafile上传到了xwiki,其实掌握了要领,这个效率会高很多。

接下来的事情就是为每个人开通权限,给大家讲讲怎么使用,注意事项了,如果这些都给你准备好了,你还不用,是不是欠扁了。

所以截止目前,文档库的工程就暂时告一段落了,当然还需要细化还需要改进,但是至少目前的文档建立了连接,至于后面的事情,我觉得就刻意优雅一些了。我就不会再去强推了。

这是当时和其他部门讨论接入管理平台的时候,之前的目录结构面目全非,所以做一件事情,能够做到基本的可控很重要。当然这种吃力不讨好的事情等需要的时候发挥作用,也算是一个功德吧。

原文发布于微信公众号 - 杨建荣的学习笔记(jianrong-notes)

原文发表时间:2018-01-16

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏熊二哥

《大型网站技术架构》学习笔记-01概述

李智慧老师的大型网站架构已经买了两年了,之前大体看过一次,不过还未内化为自己的本领,最近项目空闲,决定尽力掌握这部分的知识,以跟上大师的节奏。今天是儿童节,祝自...

2775
来自专栏IT大咖说

微信支付大规模前端开发背后,如何用外包解决困境

摘要 业务高速发展离不开各种配套运营系统的高效建设,微信支付也不例外。在前端人力极其匮乏的条件下我们另辟蹊径,大规模引入外包团队协同作业,并且在如何保证效率和质...

4426
来自专栏WeTest质量开放平台团队的专栏

你的APK安全吗?来WeTest免费测!

? 腾讯安全联合实验室就曾在《2018上半年互联网黑产研究报告》指出,移动端黑产规模宏大,恶意推广日均影响用户超过千万。 尤其在网络强相关的APP流行年代,当...

1363
来自专栏云市场·精选汇

“功能直达”全面开放,小程序新一轮竞争开始!

微信宣布“功能直达”正式开放,商家与用户的距离可以更“近”一步!用户微信搜一搜功能词,搜索页面将呈现相关服务的小程序,点击搜索结果,可直达小程序相关服务页面。

1615
来自专栏云计算D1net

公共云存储服务的可扩展性和性能

公共云存储服务供应商可帮助企业用户免于承担物理硬件及其相关成本的负担,其中包括能源、冷却以及服务器维护等。 很多企业都在使用公共云、私有云以及混合云这样的一个组...

3669
来自专栏场景录小程序

“功能直达”全面开放,小程序新一轮竞争开始!

微信宣布“功能直达”正式开放,商家与用户的距离可以更“近”一步!用户微信搜一搜功能词,搜索页面将呈现相关服务的小程序,点击搜索结果,可直达小程序相关服务页面。

712
来自专栏BestSDK

【刷脸登陆】 一种毋须动用大脑皮层的登录方式

一登是啥? 一登是一家人脸登录服务提供商,以开发组件的形式,为 Android、iOS 应用开发者提供人脸登录功能接入服务。用户不需要记住很多密码,因为人脸就是...

22710
来自专栏云计算D1net

如何集成云层与本地存储

云和本地存储正走向越来越紧密的整合,于是云成为了另一个存储管理员可用的层级。 ? 组织不大可能把100%的数据都移到云服务上,但大多数企业都会至少想让一部分数据...

3146
来自专栏姬小光

科普 | 一张表格告诉你,到底 H5 和小程序哪个好

许多做产品的同学经常会有这样的疑问,计划开发的移动端产品到底是用 H5 好还是用小程序好,甚至很多开发同学也搞不清楚这两者在具体使用中的优劣。那么相信读完此篇,...

1602
来自专栏美团技术团队

美团外卖自动化业务运维系统——Alfred

背景 美团外卖业务在互联网行业是非常独特的,不仅流程复杂——从用户下单、商家接单到配送员接单、交付,而且压力和流量在午、晚高峰时段非常集中。同时,外卖业务的增长...

5648

扫码关注云+社区

领取腾讯云代金券