一、关注产品比服务器更重要
无论是Web网站还是要移动应用，最终都要呈现给用户的，不是服务器的负载图，而是产品本身。而从产品形态展示到服务器的请求处理，这个过程中有很多过程，这也同样是运维人员需要关注的。哪怕后台再烂，Bug一大堆，也能支撑的了现有系统的用户访问。因为作为运维人员职责并不是开发，而是保证开发出来的系统不会因为服务器某些问题而导致用户无法访问，从而影响为用户提供正常服务。
一般来说，从用户角度监测产品，有如下几个维度？
1.使用情况监测:监测内容包括用户是否完成预设的访问路径，停留在哪些内容比较长。
2.交互动作监测:监测内容包括页面哪些位置更容易吸引用户点击，哪个元素比较吸引人。
3.访问性能监测:监测的内容包括用户看到他(她)想看到的页面内容，花了多久时间，能否正常显示。
4.用户统计监测:监测的内容包括用户的年龄、性别、职业分布，满意度调查等。
不同的维度有不同的人关注。比如像产品经理比较关注的就是使用情况和交互动作
对于运维人员，更需要关注的就是访问性能。因为使用情况和访问性能及其最后的用户统计都是建立在访问的基础上。
二、网站监测的明星指标
1.可用性
主要是可用性，对于任何网站，可用性都是首要的关键指标。人们常说“聊胜于无”，就网站运维来说，建立对网站应用的可用性监测，是产品监测从无到有的第一步。最简单通用的方式就是对应用最终发布的服务器进行80端口上是否可连接的定期测试。
对于大规模网站应用，连接可用性又可以细分为服务器可用性、运营商可用性、地区可用性、错误响应比等四个方面。
a.服务器可用性
大规模网站一般情况下都拥有多个对外发布的可用的服务器。运维人员既要尽力保障整个应用集群的高可用性，也同样需要关注集群内部单个服务器的可用性。否则，一旦出现连续宕机的情况，就很容易出现雪崩反应。
如果是运维人员只是仅仅管理三到四台机器上面的几个项目，那还好，如果是成千上万台服务器支撑着一个规模非常大的项目的话，为了保障某部分服务器出现问题第一时间解决，那么监控手段的有效性和实时性是非常重要的。
b.运营商可用性
运营商的可用性很多参考例子，我就以前段时间因为运营商的缘故导致某创业公司数据丢失问题。这个说白了最直接的原因就是腾讯的原因。从某个角度看就是因为运营商没选好导致的。
c.地区可用性
比如现在阿里云服务器提供华北一、华北二等之类的选项就是因为地区网络可用性的原因。有的时候因为业务需要在某个特定的区域对外提供服务。
d.错误响应比
因为多方面的原因，例如服务器负载过高、网络延时、DNS劫持篡改甚至运维操作失误(比如前段的运维人员不慎删库)等，连接可用的网络也可能返回错误的结果。与连接可用性比较，错误响应比更难以监测。
2.响应时间
响应时间这个不用说的太多，在很多年前有个8秒定律，然后变成4秒定律，最后变成了最好是1秒或者2秒定律，当然了，实际因情况而定。或许有人对8秒定律这样的很疑问，对此，我觉得不是特别理解的人，可以参照平时上网，如果你好久好久也就是10秒以上时间没打开这个网站，恐怕你早就放弃了。我这个10秒都是夸张了点。当然了，这里针对的是一般用户。像我们开发人员这些特别的用户，一般访问外国的技术网站，确实有的时候很卡，当然也不排除有的时候无法访问(拦截的缘故)，但是为了学习这也是没有办法的事情，于是有的就想尽办法代理访问或者是翻墙等等。
3.首屏响应时间
首屏一般是用户第一眼看到的，首屏如果响应半天，只仅仅看到了有的图片显示有的没有显示、有的css样式或者js动态效果出来了，有的就没有。如果是这样的话，那么用户早就跑光了。
为此针对这种情况，就需要前端人员和运维人员合作采取一些必要的措施，比如动静分离、CDN之类的。
三、网页浏览过程
1.解析域名
解析域名同样分成几部分。
首先，浏览器本身是可以缓存DNS域名解析的，所以浏览器会先在自己内部的DNS缓存中查看是否有现成的记录，如果有，就直接返回结果。
否则，查询操作系统级别的DNS缓存。这在Window操作系统中，是一个叫DNSCache的服务；在Linux操作系统中，可能是HSCD服务，也可能是DNSmasq服务。如果命中，直接返回结果。
如果依然没有，下一步是查询本机Hosts记录。该文件在Windows操作系统下位于C:WindowsSystemdriversetchosts,在Linux操作系统下位于/etc/hosts。
2.连接服务器
在获取最终的服务器IP后，下一步就是与该IP的网页服务端口(即HTTP的80和HTTPS的433端口)建立TCP连接。这部分过程涉及TCP/IP相关的知识，无论是开发和运维人员都有这个必要去好好看看。
3.发送请求
在成功连接上对应端口后，浏览器开始发送HTTP请求。HTTP请求包括请求方法、URL和协议版本三个最基本要素，以及种类繁多的各式HTTP Header。完整的协议内容通过查看RFC2616，以及《HTTP协议指南》获取。
4.等待响应
这一步可能会让读者觉得很惊讶，但事实上，这个时间确实存在，而且有必要单独关注。动态网页的内容，需要服务器端进行数据库查询等复杂操作；静态内容，也需要服务器进行磁盘寻道读取；如果是代理服务器，或者文件通过NFS挂载，那么更大的世界消耗还有内部网络交互等。这个时间依赖于服务器性能，也就可以间接反映出服务器端的负载压力情况。
5.传输响应内容
传输响应内容的快慢，取决于网速
6.浏览器渲染处理
浏览器接受完全部响应内容后，开始在本地进行渲染处理。
对于HTML文件，现代浏览器一般会读取到<a href>和<img src>等需要继续请求元素节点，随机提前开始准备DNS解析，并稍后开始建连。因为DOM树的构建是随着HTML语句的读入进行的，所以这一部分操作相当快速。
对于CSS/JS文件，CSS操作DOM树JS则更准确就是客户端脚本语言，它们都需要在浏览器上编译运行。
浏览器对这两种文件的运行速度对全页面显示完成总时间的影响非常大。因为在目前的协议和实现下，浏览器页面渲染都是单线程的，CSS和JS的执行都会阻塞整个页面的效果。
如果将JS脚本放在HTML代码的开头或者中间，那这个阻塞甚至会影响到DOM树的构建。所以在Yahoo等常见前端优化规则，大多数建议将JS脚本放到</body>前
四、浏览器网络监测和分析
常用的浏览器调试工具FireBug和Chrome开发人员工具。我觉得这两个足以胜任。同时也是前后端、运维人员常用的工具之一。