文件知識庫的演進和小結

本文是今天下午在我的自動化運維群做的分享，群裡每天都有一到兩個主題的分享，目前來看效果還不錯。正文如下：

我看過很多公司的知識庫，乾脆叫它文件庫也可以。總體來說，知識庫在很多公司的角色比較尷尬，不被重視，但是大家都希望有。

如果從我的工作中碰到的知識庫來說，我覺得之前的外企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,其實掌握了要領，這個效率會高很多。

接下來的事情就是為每個人開通許可權，給大家講講怎麼使用，注意事項了，如果這些都給你準備好了，你還不用，是不是欠扁了。

所以截止目前，文件庫的工程就暫時告一段落了，當然還需要細化還需要改進，但是至少目前的文件建立了連線，至於後面的事情，我覺得就刻意優雅一些了。我就不會再去強推了。

這是當時和其他部門討論接入管理平臺的時候，之前的目錄結構面目全非，所以做一件事情，能夠做到基本的可控很重要。當然這種吃力不討好的事情等需要的時候發揮作用，也算是一個功德吧