所謂”知識管理與知識積累”,其實有點繞,我們不如就說說”運維技術(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è)的始終,逐漸豐富完善。