作者文章: Fenng

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

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

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

运维友好的文档

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

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

  • 易读性 便于阅读,便于技术人员阅读。尤其是内容不应引起歧义、转码等。
  • 可搜索性 针对具体内容便于查找,便于发现。
  • 版本化控制 这里不是普通的 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

代招聘 .NET 架构师一名

插播一条广告:帮朋友公司招聘 .NET 架构师一名。尽管是互联网寒冬,还是有的公司准备足了木头、煤来取暖的。

职责:

  • 1. 主要负责公司产品组件设计工作
  • 2. 负责产品开发技术研究及其实现方面的技术分析和架构
  • 3. 负责基于服务的接口定义和方案及其实现规划
  • 4. 带领和带动整个开发团队的技术学习并对编码人员进行指导
  • 5. 全局掌控和执行既定解决方案的实施
  • 6. 关注团队代码质量和规范化

要求:

  • 1. 熟悉面向对象的编程思想
  • 2. 7-10年以上软件行业工作经验(非必须)
  • 3. 计算机相关专业本科及以上学历
  • 4. 具有良好的沟通能力及团队协作能力,工作细致,能承受工作压力,富有责任心
  • 5. 拥有SOA系统的架构和设计能力,并且有实际的工作经验
  • 6. 具有3年以上大型ERP项目开发经验并产于架构工作(非必须)
  • 7. 了解微软主要企业应用技术和服务器:Biztalk,Message Queen(消息队列),Windows UDDI Server等相关技术
  • 8. 对WEB Service 有非常精通,特别要熟悉WCF,WWF等相关技术
  • 9. 注重在后台开发架构,而非页面操作方面的能力
  • 10. 对实现软件设计解偶的设计模式有相当经验
  • 11. 熟练掌握常见的多种设计模式
  • 12. 对系统性能的优化和评估有实际工作经验
  • 13. 有MVC设计方法有实际经验
  • 14. 对多层应用系统开发有3年以上实际经验
  • 15. 了解IOC 和AOP等等技术
  • 16. 有SSO单点认证或者通行证开发经验
  • 17. 拥有多系统集成项目实施经验。

描述的内容还不少。其实就是一个 .NET 架构师该做的事儿,倒也不必强求所有条件都符合(那两个”非必须”的标注是我加的),也别挑刺其中描述是否有过分的地方吧。

工作地点在杭州。

薪酬,年薪 + 期权。感兴趣的话请发简历到 [email protected] .,具体情况和招聘公司详谈,我知道的不比这个页面上描述的内容更多。

EOF

网站运维之道 之流程规范

接上一篇《容量规划》,谈一下流程规范这个话题。

流程规范

对于相对正规的网站维护工作,所有网站的所有变更必须能做到有记录,可回溯。如果是单枪匹马作战,那么要实现这个目标并不是很难,只需要把好习惯培养起来就成了,可如果要面对一个团队,那么就必须要依赖流程规范来进行约束。

所谓”流程规范”,在初期也可以拆开来对待:流程 + 规范(废话!)。

关于流程(Process),直白的说就是”把大象放入冰箱需要几步?“的问题。比如上线一台服务器,那么可能要经过至少前期的选型规划、基准测试、压力测试……等等诸多步骤。如果跳过某个环节(比如缺少基准测试)而直接上线,遇到问题的时候几乎就会因为缺乏对比数据而走弯路。

关于规范(Norm),在运维的过程中是个范围比较大的话题,因为 Web 站点环境因为各种原因而不可复制,在另一个公司可用的规范照搬到另外一家公司未必管用。如果能够意识到并且尽早抽象出来标准化组件,并着手推进,那么规范必然会逐渐丰富起来并完善。比如 Web 服务器配置规范、Linux 主机配置规范、SAN 存储系统测试规范,都是可以尽早抽象出来并且可具体化的东西。

流程规范建立容易,但是如何确保执行却是一个很有挑战性的问题。从这一点来说,对于运维团队的领导的要求还是比较高的。如果要成功管理一个运维团队,起码要有足够的技术经验(当然,也容易看到外行领导内行的运维团队),而且要有足够强的执行力。

在流程规范的建立过程中,往往容易陷入为了规范而规范的误区,或是生搬硬套 ITIL(Information Technology Infrastructure Library,”信息技术基础架构库”) 那一套大而无当的东西进来(这里不是说 ITIL 不好,但最合适自己的才是最好的),必须明确,规范的最终目的是为了运维团队更快而不是变成束缚,所以,千万要避免技术人员对规范的抵触。

在运维团队发展的某个阶段,推行”流程规范”所引入的 ITIL 等事物是一把双刃剑,运用得当会很好的促进团队成长,运用不好则会阻碍一部分激进成员的积极性,这一点需要注意。

补充一点,对于流程规范,不是死的东西,必须具备不断反馈、改进、进化的能力,运维团队也应该定期修正流程规范的有关内容。有一句耳熟能详的话是:遵守流程而不拘泥于流程,这里的”不拘泥”切不可变成钻空子的借口,要知道我们生活中很多无形成本就是钻空子引起的。

未完待续,下一部分谈一下关于《知识管理与知识积累》等方面的内容。

EOF

强烈推荐一篇相关文章 运维的工序流程. Hutuworm 的大作。

网站运维之道 之容量规划

接上一篇《网站运维之道 监控与报警机制》,谈谈关于容量规划。

容量规划

有效的监控能够避免绝大多数问题的扩大化,但是还是做不到防患于未然。监控告警机制完善后,就需要着手考虑容量规划(Capacity Planning)的问题。

所谓的容量规划,也就是一个公司为了满足商业目标的需求而决定生产能力的过程。俗语说,”人无远虑,必有近忧”,容量规划,需要的是”远虑”。对应到运维的工作上来,一方面是商业目标带来的容量需求,一方面是针对相关历史数据的分析带来的预测。这里的历史数据,是需要运维团队采集、整理的。(从这个角度上说),容量规划是一个长期的过程。

相关的数据保存和图表生成,基本上都会采用 RRDtool (http://oss.oetiker.ch/rrdtool/)来做。 RRDtool 也已经是业界的事实上的标准,但毕竟 RRDtool 只能算是一套引擎。而规模化的数据管理工作则需要求助其它工具,则不能不提 Cacti (http://www.cacti.net/)这是现在相当通用的做法。老牌的 MRTG 已经很少有人用了。

利用 Cacti,很容易得到一段时间内某项数据指标的变化趋势(比如网络流量的增长趋势、服务器负载的趋势等)。这是运维过程中最主要的参考数据之一,缺乏此类数据而做决策是不可想象的。

Cacti_Graph.png

如上图,可以发现被监控的服务器上进程数量半年内的增长趋势,在 2 月份间的进程数并不高(春节期间),随后的几个月突破 4000 个进程,对于普通的服务器来说,这是比较危险的。尽管当前系统运行可能比较平稳,但运维技术人员绝对有必要考虑中期解决方案。

容量规划中的另外一个重要参考维度是 Web 访问日志的趋势图。对于中小网站来说,Awstats 足以胜任,更大一点的规模或是对统计要求更高的站点或许只能自己写统计工具了,还没听说有什么针对大型网站而且性价比好的商业工具。这里笔者要强调一下的是,商业站点尽量不要用第三方的流量统计工具,这样很容易泄漏比较关键的商业信息。

补充后记

容量规划其实远远不止这些,比如应用服务器容量规划方面、数据库容量规划,主机容量规划、存储容量规划等等,把整个架构拆成各个组件,每个组件的容量规划都是值得大书特书的一块内容。

另外一个关键点是团队的”容量规划”,团队成长这一方面如果跟不上也很容易成为瓶颈。

未完待续,下一篇谈一下关于《流程规范》的事儿。


推荐阅读:The Art of Capacity Planning. 可以迅速帮助形成容量规划的概念。