【IT168专稿】如果用三个形容词描述 大型WEB2.0网站的运营现状, 那应该是:巨大, 复杂,和众多。

　　巨大从何而来?

　　1、用户与网站的交互巨大 – 每日请求量数以亿计

　　2、用户产生内容巨大 –T级~P级用户数据,51每天有大量的用户照片,日记上传,

　　3、线上运行的代码量巨大 – 估计有上百万行代码在线上运行

　　复杂又出自哪里?

　　1、业务逻辑复杂 – 比如登入验证,支付逻辑都很复

　　2、网站架构复杂 –N层架构, 又是cache层,web层, 又是中间层, 数据库层, 架构异常复杂

　　3、网络环境复杂 – 电信,网通,移动,N个运营商

　　众多又如何解读?

　　1、网站功能众多 – 数以千计的功能点

　　2、机房众多–51有十几个机房,几千台服务器

　　3、用户交互大 --每日请求量以亿计

　　4、用户产生的内容多 --T级~P级

　　5、网站功能多，业务逻辑复杂 --几千个功能点

　　6、网站架构复杂，线上运行代码量大 -- N层架构

　　7、几千台服务器, 机房众多 --网络环境复杂,电信,联通,铁通……

　　因此，巨大,复杂,众多的web2.0运营现状, 给运营监控带来了巨大的挑战：

　　在web1.0时代, 页面大部分是静态的, 网站交互性不高, 用户创造的内容较少, 因此已有的监控方式已经能满足需要了, 特别是Nagios在服务器方面的监控已经做的非常好了.

　　但在web2.0时代, 绝大部分都是动态页面, 偷菜, 楼一栋这样的webgame,带来了很高交互性要求, 用户创造的内容也非常大, 特别是中国的网络环境特别复杂, 在这样的情况下, 已有的监控方式已经不能满足监控的需要,

　　他的不足体现在：广域网监控, 监控点少,价格昂贵,且有时不准确；而且。无法发现并定位业务层问题。

　　对于web2.0时代运营监控的挑战，51.com做出了他们的应对策略：

　　策略一：缺啥补啥

　　在广域网监控领域，通过在网站页面上嵌入脚本, 测试用户端抓取不同服务器上的图片的速度, 将数据汇总, 根据不同的测速曲线及历史曲线判定广域网事件;

　　在业务层监控领域，通过嵌入在业务逻辑代码中的数据采集程序, 汇聚业务数据到数据中心, 异常发现系统抓取数据中心的数据进行曲线模式匹配运算, 发现异常上报数据到告警服务器, 监控中心收到告警, 并做检查,最终确定是否有事故发生;

　　51.com具体部署如下：

　　接下来我们通过分享一个案例来看运营监控系统在51.com的日常运营中起到的重要作用。

　　阳光明媚的早上, 客服美眉, 接到了个用户的电话说网站的图片上传有问题, 客服提单给测试, 测试部的哥们测了后说没问题, 过了5分钟, 又陆续有两三个电话反馈同样的问题, 测试部哥们让开发部的兄弟看下是不是程序上的问题, 开发说没问题, 找运维查查, 这时又有好几个用户电话, 大家开始踢皮球.

　　重点自动报警系统发现异常, 监控中心监控员查看异常, 通告徐建红和小焦同学人员, 反馈相关事故现象.

　　相关人员在监控系统中检查网络,服务器,业务层监控发现问题,分析现象,定位问题,然后解决问题, 最后将结论反馈给监控中心监控员, 监控员记录事故日志。下面我们通过一组胶片来详细说明一下这一过程：

　　当其他公司的运营总监在为运营质量头痛脑裂时, 我们陈总却能胸有成竹,运筹帷幄,很重要的原因就是有一套完备的监控系统, 用一双双自动化的眼睛检查运营质量.

　　谈数据统计之前，大家先思考下面这三个问题：

　　?数据统计和运营监控有什么关系?

　　?为什么系统提供的数据能做财务审计使用?

　　?51.COM高层为何每天登入系统3次,他们在关注什么?

　　06,07年的时候, 51发展的很快, 主要精力都集中在产品和服务质量上。那时51.Com的流量太大，使得服务器无法承受，我们的统计服务被暂停了2周；

如今，51的统计却发生了重要变化：

　　下面我们通过两个图片，可以清晰的看到51是如何做系统架构的：