在 Web Analytics 的几种方法中，分析 Web 服务器日志(Logfile Analysis) 与页面标记方法(Page Tagging/JavaScript Tagging, 也有称之为"打点")相对更常见一些。今天发现一个关于二者的对比表格，感觉还是挺有帮助的，粗翻了一下，留作参考。
(点击可看大图)
Page Tagging 的方式对业务控制(比如特定业务预警)更为灵活一些。其他的方法比如 Web Beacons(Web Bug) 的方法在 Web 1.0 的时候还是挺普遍的，对付当前的各种新型 Web 应用已经无能为力。
在设计 Web 应用的初期架构师就应该考虑 Web 分析的方法接口，就像在程序中预置性能调试接口那样，早点考虑，会少许多麻烦。
关于 Web Analytics，仍然存在许多误解与误用。冷暖自知吧。
--EOF--
没看这本书之前我以为我懂 Web 分析，看了之后才发现之前其实并不明白。
算起来，用 AWstats 做了几年的小实验，尽管一些基本的东西是有所了解，但如果要详细说明背后的含义，还是并不清晰。这可能不是我一个人的感受吧? 我遇到过一些做 Web 分析的同仁，整天看网站数据报表，也看不出什么东西来。尽管我们常看到 Web 分析工具的更新，但国内互联网的 Web 分析思路似乎并没有"与时俱进"。 不管承认与否，毕竟是现实一种。
普及这本书，我想能有效避免 Web 分析中的一些误区，以 PageView 为核心的 Web 分析时代应该已经过去。结合自己的实际业务，通过数据去了解客户，真正做点能起到"正反馈"的事儿，而不是到了节假日弄一些无聊活动疯狂弹出一些用户烦透的垃圾页面。这对你们公司也是莫大的损失。
负责网站数据分析的主管啊经理啊总监啊都把这本书偷着买回去仔细读两遍，然后整点靠谱的针对 Web 的 KPI 出来，也让下面的员工心里服气你还算个合格的管理者。把这本书当作了解 Web 的另一面镜子(如果是从传统行业过来的话)，通过另一个角度(数据)观察 Web。
此书翻译质量一般...但我想不影响阅读。
Web Analytics，An Hour a Day ，不需那么多，只要一点点。
--EOF--
作者 Avinash Kaushik ，感兴趣的话还可以观看他的相关采访视频。更多信息访问豆瓣上的 精通Web Analytics页面，如果买书直接点击豆瓣上的链接去买吧，也算支持豆瓣了 :)
又及：这本书也被我列入豆列 Web 2.0 网站架构不可或缺的图书。
接上一篇《容量规划》，谈一下流程规范这个话题。
对于相对正规的网站维护工作，所有网站的所有变更必须能做到有记录，可回溯。如果是单枪匹马作战，那么要实现这个目标并不是很难，只需要把好习惯培养起来就成了，可如果要面对一个团队，那么就必须要依赖流程规范来进行约束。
所谓"流程规范"，在初期也可以拆开来对待：流程 + 规范(废话!)。
关于流程(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，很容易得到一段时间内某项数据指标的变化趋势(比如网络流量的增长趋势、服务器负载的趋势等)。这是运维过程中最主要的参考数据之一，缺乏此类数据而做决策是不可想象的。
如上图，可以发现被监控的服务器上进程数量半年内的增长趋势，在 2 月份间的进程数并不高(春节期间)，随后的几个月突破 4000 个进程，对于普通的服务器来说，这是比较危险的。尽管当前系统运行可能比较平稳，但运维技术人员绝对有必要考虑中期解决方案。
容量规划中的另外一个重要参考维度是 Web 访问日志的趋势图。对于中小网站来说，Awstats 足以胜任，更大一点的规模或是对统计要求更高的站点或许只能自己写统计工具了，还没听说有什么针对大型网站而且性价比好的商业工具。这里笔者要强调一下的是，商业站点尽量不要用第三方的流量统计工具，这样很容易泄漏比较关键的商业信息。
容量规划其实远远不止这些，比如应用服务器容量规划方面、数据库容量规划，主机容量规划、存储容量规划等等，把整个架构拆成各个组件，每个组件的容量规划都是值得大书特书的一块内容。
另外一个关键点是团队的"容量规划"，团队成长这一方面如果跟不上也很容易成为瓶颈。
未完待续，下一篇谈一下关于《流程规范》的事儿。
推荐阅读：The Art of Capacity Planning. 可以迅速帮助形成容量规划的概念。
