所謂”知識管理與知識積累”，其實有點繞，我們不如就說說”運維技術(shù)文檔”的事兒吧，這樣可能還直白一點。因為每次說起類似的話題，總有兄弟用不屑的語氣說，不就是寫寫文檔的事兒么?

運維友好的文檔

不同的團隊對文檔要求可能都有不同的”風(fēng)格”–更多的時候是運維主管要看著舒服。就運維來說，必須能夠創(chuàng)建”運維人員友好”的文檔。

一般來說，運維文檔應(yīng)該具備如下特點：

• 易讀性 便于閱讀，便于技術(shù)人員閱讀。尤其是內(nèi)容不應(yīng)引起歧義、轉(zhuǎn)碼等。
• 可搜索性 針對具體內(nèi)容便于查找，便于發(fā)現(xiàn)。
• 版本化控制 這里不是普通的 V1.0，V2.0 之類的簡單標(biāo)識版本，而是要能夠獲取所有的內(nèi)容改變過程，便于回溯。
• 通行格式 能夠適應(yīng)不同的操作系統(tǒng)平臺。
• 信息完備性 具備足夠豐富的交叉引用，反復(fù)保存的時候不會丟失信息等。

可能還有其他特性沒在這里一一列出。有的網(wǎng)友看了上面的描述，這不就是 Wiki 嘛! Bingo! 基于HTML 的 Wiki 頁面，絕對是對運維友好的，尤其是網(wǎng)站運維團隊。 我見過很多團隊用 Word 寫文檔，這是非常糟糕的事情。在版本化控制、可搜索性方面具備天生缺陷?；蛟S書寫運維報告用 Word 是好的選擇，但是運維技術(shù)文檔的積累絕對不能用 Word。

運維友好的 Wiki

你們的運維團隊在用 Wiki 么?

一般來說，具備一頂?shù)恼Z言背景可能更喜歡用該語言開發(fā)的工具(嗯，我說的是”一般”)，有一定 Java 背景的程序員可能會喜歡用 Confluence 之類的 Wiki 工具。而對運維人員來說呢，什么是他們的語言背景? Shell ? No ! Perl/Python/PHP ，一般運維人員可能都熟悉三者之中的東西。

我個人多少喜歡一點 TWiki ，盡管我對 Perl 不那么熟悉。而很多中小 Web 網(wǎng)站，可能是 PHP 為開發(fā)語言，摟柴火打兔子，捎帶腳讓程序員幫著定制一些功能就成了。這是不是有點扯遠了? 什么是運維友好的 Wiki 呢? 我的意見是要能促進運維人員技能的 Wiki 軟件，比如選用了 TWiki，那么在維護的時候，Perl 背景技能就能派上用場并能進一步促進，多少有點以戰(zhàn)養(yǎng)戰(zhàn)的意味在里面。

此外，應(yīng)該強制運維人員提交 Wiki 標(biāo)記化的文檔，而不是簡單上傳一些 Word 文檔、PPT 甚至 HTML附件。Wiki 編輯器里別直接粘貼從 Word 文檔 Copy 來得內(nèi)容。

如果團隊足夠大，應(yīng)該有人專門定期檢查文檔質(zhì)量，乃至對新人做一些簡單的示例或者培訓(xùn)什么的。寫一份好的文檔甚至比寫一大段好的代碼更重要。

知識管理與積累

Wiki 上都記錄什么? 最佳實踐、技術(shù)心得、配置文檔、軟硬件信息 … 乃至團隊人員聯(lián)系方式，隨時記錄是需要的，但保持更新更重要。

知識管理(KM, Knowledge Management)是干啥的? 這四個字說來話長，維基百科解釋道：

... comprises a range of practices used in an organisation to identify, create, 
 represent, distribute  and enable adoption of insights and experiences.

用我的土話說，要把信息沉淀下來并傳遞給更多的人用。一個人寫的文檔，團隊其他的人要能看明白，要理解，要能拿著這文檔做事情。沒有知識管理意識的團隊，成員之間的信息交流或許也有些不順暢，可能會在人員的使用上存在很多瓶頸，遇到一點技術(shù)上的小事情，原來負責(zé)的人不在場，其他人可能搞不定，這是風(fēng)險！

有些團隊對待知識管理的態(tài)度上是”拿來主義”但缺乏分享精神，比如復(fù)制大量網(wǎng)絡(luò)上的信息到內(nèi)部，但是不愿意對外分享團隊的心得，這樣不好!

積累，意味著這是一件長期的事情。不是一窩蜂搞一下就結(jié)束不管的。一份運維文檔應(yīng)該貫穿網(wǎng)站建設(shè)的始終，逐漸豐富完善。