文档知识库的演进和小结
本文是今天下午在我的自动化运维群做的分享，群里每天都有一到两个主题的分享，目前来看效果还不错。正文如下：
我看过很多公司的知识库，干脆叫它文档库也可以。总体来说，知识库在很多公司的角色比较尴尬，不被重视，但是大家都希望有。
如果从我的工作中碰到的知识库来说，我觉得之前的外企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来做就好了。
所以这样一来会发现以前未曾发现的文档，竟然根据关键字也能找到一些联系.
当然还有个优点，就是可以根据很多的过滤条件来筛选。这个就很方便了。
搭建的过程，可以参考之前的一篇文章。
而且说实话，经历的阶段比我提到的要多。经历了Django Admin,Django Suit，然后都不满意的情况，才走到现在的这个阶段。
当然目前的算是一个1.0的版本，我来简单说下如何做xwiki的迁移，为什么这么说，因为xwiki的插件是基于网络下载的，我们的工作环境很可能是没有这些网络的。
总体的思路就是在测试环境部署tomcat和war包，然后下载插件，插件都下载好以后，直接把整个目录都拷贝到内网的环境中，然后把已有的数据都迁移出来，这里用的数据库是mysql，导出导入即可。整个迁移用了一上午就做完了。
工程的难度就是对于插件的裁剪，因为xwiki支持很多插件，其实不是所有的我们都需要，最后我裁剪剩下的也就不到5个插件，其他的目录结构统统都去掉。
接下来的事情就是所有文档的接入，这个部分我做到了为人民服务的宗旨，我把大家已有的目录和文旦都从seafile上传到了xwiki,其实掌握了要领，这个效率会高很多。
接下来的事情就是为每个人开通权限，给大家讲讲怎么使用，注意事项了，如果这些都给你准备好了，你还不用，是不是欠扁了。
所以截止目前，文档库的工程就暂时告一段落了，当然还需要细化还需要改进，但是至少目前的文档建立了连接，至于后面的事情，我觉得就刻意优雅一些了。我就不会再去强推了。
这是当时和其他部门讨论接入管理平台的时候，之前的目录结构面目全非，所以做一件事情，能够做到基本的可控很重要。当然这种吃力不讨好的事情等需要的时候发挥作用，也算是一个功德吧。