![0feb0c39e8d8432da4fd5a79a3e1a8e1.jpeg](http://5b0988e595225.cdn.sohucs.com/images/20180117/0feb0c39e8d8432da4fd5a79a3e1a8e1.jpeg)
本文是今天下午在我的自动化运维群做的分享,群里每天都有一到两个主题的分享,目前来看效果还不错。正文如下:
我看过很多公司的知识库,干脆叫它文档库也可以。总体来说,知识库在很多公司的角色比较尴尬,不被重视,但是大家都希望有。
如果从我的工作中碰到的知识库来说,我觉得之前的外企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,其实掌握了要领,这个效率会高很多。
接下来的事情就是为每个人开通权限,给大家讲讲怎么使用,注意事项了,如果这些都给你准备好了,你还不用,是不是欠扁了。
所以截止目前,文档库的工程就暂时告一段落了,当然还需要细化还需要改进,但是至少目前的文档建立了连接,至于后面的事情,我觉得就刻意优雅一些了。我就不会再去强推了。
这是当时和其他部门讨论接入管理平台的时候,之前的目录结构面目全非,所以做一件事情,能够做到基本的可控很重要。当然这种吃力不讨好的事情等需要的时候发挥作用,也算是一个功德吧
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/23718752/viewspace-2152353/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/23718752/viewspace-2152353/