网站运维之道 之知识管理与积累

接上一篇《流程规范》，继续谈谈知识管理与知识积累的相关内容。

所谓"知识管理与知识积累"，其实有点绕，我们不如就说说"运维技术文档"的事儿吧，这样可能还直白一点。因为每次说起类似的话题，总有兄弟用不屑的语气说，不就是写写文档的事儿么?

运维友好的文档

不同的团队对文档要求可能都有不同的"风格"--更多的时候是运维主管要看着舒服。就运维来说，必须能够创建"运维人员友好"的文档。

一般来说，运维文档应该具备如下特点：

• 易读性 便于阅读，便于技术人员阅读。尤其是内容不应引起歧义、转码等。
• 可搜索性 针对具体内容便于查找，便于发现。
• 版本化控制 这里不是普通的 V1.0，V2.0 之类的简单标识版本，而是要能够获取所有的内容改变过程，便于回溯。
• 通行格式 能够适应不同的操作系统平台。
• 信息完备性 具备足够丰富的交叉引用，反复保存的时候不会丢失信息等。

可能还有其他特性没在这里一一列出。有的网友看了上面的描述，这不就是 Wiki 嘛! Bingo! 基于 HTML 的 Wiki 页面，绝对是对运维友好的，尤其是网站运维团队。 我见过很多团队用 Word 写文档，这是非常糟糕的事情。在版本化控制、可搜索性方面具备天生缺陷。或许书写运维报告用 Word 是好的选择，但是运维技术文档的积累绝对不能用 Word。

运维友好的 Wiki

你们的运维团队在用 Wiki 么?

一般来说，具备一顶的语言背景可能更喜欢用该语言开发的工具(嗯，我说的是"一般")，有一定 Java 背景的程序员可能会喜欢用 Confluence 之类的 Wiki 工具。而对运维人员来说呢，什么是他们的语言背景? Shell ? No ! Perl/Python/PHP ，一般运维人员可能都熟悉三者之中的东西。

我个人多少喜欢一点 TWiki ，尽管我对 Perl 不那么熟悉。而很多中小 Web 网站，可能是 PHP 为开发语言，搂柴火打兔子，捎带脚让程序员帮着定制一些功能就成了。这是不是有点扯远了? 什么是运维友好的 Wiki 呢? 我的意见是要能促进运维人员技能的 Wiki 软件，比如选用了 TWiki，那么在维护的时候，Perl 背景技能就能派上用场并能进一步促进，多少有点以战养战的意味在里面。

此外，应该强制运维人员提交 Wiki 标记化的文档，而不是简单上传一些 Word 文档、PPT 甚至 HTML 附件。Wiki 编辑器里别直接粘贴从 Word 文档 Copy 来得内容。

如果团队足够大，应该有人专门定期检查文档质量，乃至对新人做一些简单的示例或者培训什么的。写一份好的文档甚至比写一大段好的代码更重要。

知识管理与积累

Wiki 上都记录什么? 最佳实践、技术心得、配置文档、软硬件信息 ... 乃至团队人员联系方式，随时记录是需要的，但保持更新更重要。

知识管理(KM, Knowledge Management)是干啥的? 这四个字说来话长，维基百科解释道：

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

用我的土话说，要把信息沉淀下来并传递给更多的人用。一个人写的文档，团队其他的人要能看明白，要理解，要能拿着这文档做事情。没有知识管理意识的团队，成员之间的信息交流或许也有些不顺畅，可能会在人员的使用上存在很多瓶颈，遇到一点技术上的小事情，原来负责的人不在场，其他人可能搞不定，这是风险！

有些团队对待知识管理的态度上是"拿来主义"但缺乏分享精神，比如复制大量网络上的信息到内部，但是不愿意对外分享团队的心得，这样不好!

积累，意味着这是一件长期的事情。不是一窝蜂搞一下就结束不管的。一份运维文档应该贯穿网站建设的始终，逐渐丰富完善。

后记：如果还有兴趣，写写关于《自动化维护》的话题? 要不算了吧。今天这个话题写的有点匆忙，因为不是对媒体供稿，所以行文语气很散，有待于收到反馈后更新吧...

--EOF--