02、大型互联网公司运维体系.doc

大型互联网公司运维体系

转自互联网

今天听了下百度的朋友讲了百度现有的运维体系，感觉还是很不错的，比较适合大的方向把握。

第一个是运维的日常工作：

1.突发流量，这个需要及时的进行流量调度，以及排查为什么会有突发流量，是某个新的上线导致还是由于配置错误还是运营推广。

2.复杂环境关联。这个其实是最重要的，在一个复杂的系统环境中会有很多层次，我们要了解每个层次之间的关联，以及每个层次的性能。所以一个完整的系统逻辑框架图和物理框架图是很有必要的。3.快速开发并上线。这个是由于互联网的特性造成的，我们什么都是讲究一个快字，快速开发，快速部署，快速增长，快速下线。

第二个是整体运维的框架：

1.容量管理

2.关联关系

3.任务管理

4.自动部署

5.分布式集群和传统集群

6.机器管理

要在一开始为这6项做好流程化和监控管理，同时最后要贯穿安全检测和灾难管理。

具体到运维框架里的自动化监控

数据采集：

1.数据采集（主动提交到中心服务器上）：在client端部署公共插件和自定义脚本的一些监控

2.服务器状态检测（由中心服务器隔时间去检测）：这个主要是中心服务器去检测服务器上的服务状态和程序状态，以及用户访问的质量3.第三方信息：这个主要是跟公司内部系统相关联

数据处理：

1.复杂计算：因为有些监控阈值不是单独一个值就能判定这个是否有问题，而是通过多个监控值进行计算后才能确定是否有故障

2.阈值判别

3.智能分析：这个是分析到底是什么导致了这个故障，为后面做故障自动恢复打下基础。

报警和联动：

1.报警策略：这个主要是报警的阈值和去重报警。当一台服务器挂掉的时候，那一般情况这个服务器上所有报警都会发出来，但是这个时候其实就报一个服务器down就可以了。2.联动处理：由于一个服务的问题可能导致其它问题的产生，这个时候需要了解系统的逻辑架构和关联关系才能知道。

3.报警跟踪：跟踪问题的处理过程和结果，时间等信息

4.问题管理：每个问题都有各种各样的原因产生的，这个可以汇总整理

完整的监控内容：

1.域名监控：看看dns解析是否正确，这个百度吃过大亏的

2.流量监控：主要是某个区域和全网流量是否有异常。

3.访问质量监控：通过对于前端服务器的流量镜像分析来判定网络质量值否正常。也有是从本地通往远程是否网络路由是否正常。也可以使用networkbench和gomez这种第三方监测来发现。4.语义监控：就是对于页面中的关键字进行监控

5.基础监控：系统的状态，cpu,load等等

6.端口监控：telnet到机器的服务端口看看是否正确返回

7.结构体监控：这个是当某个进程还在系统中存在，端口也存活，但是无法正常服务的情况下进行监控。可以模拟程序请求这个进程，看是否能正常工作并返回正确的值。8.模块监控

9.日志监控：对于机器的错误日志，访问日志等信息进行监控

10.自定义监控：

其实以上所有的监控的最终目的就是要发现对于用户的影响是什么？

具体到具体的语义监控内容：

1.语义监控（页面监控）：其实就是通过get页面然后判断页面是否有预定义的关键字。

2.高级语义监控（面向功能）：这个是为了监控页面中多个模块是否正常。这个需要在html对于不同的功能定义标签开始符和结束符，这样通过get这个面后看看标签之间是否数据存在就知道页面功能是否正常。

监测各地用户访问质量：

1.各地访问速度：这个基本需要在当地部署机房后才能测定，也有用networkbench和gomez来测量的。

2.各地流量

3.机房带宽使用

4.各地DNS速度

对于模块的监控：

1.程序自身占用的资源是否合理

2.程序的性能表现是否正常

3.该程序的分支是否正常

基础监控：

1.CPU资源占用：这个就看CPU到底是多少核了，不能一定说多少

2.内存使用：这个要看实际使用的，不能算上buffer和cache，因为Linux系统默认是利用完所有的内存的

3.文件句柄的使用

4.网络句柄

5.各种状态的进程数

服务监控标准：

1.数据加载情况

2.模块处理能力

2.1平均耗时

2.2队列长度

2.3线程池使用率

3.模块间通讯状态

3.1平均连接时间

3.2读写错误数

异常根源分析：

1.关联关系查询

2.模块关联探测

3.服务器关联状态探测

4.网络关联探测

5.波动性预警

联动处理：

1.流量切换预案

2.服务器重启

3.磁盘数据清理

4.执行用户自定义命令

报警去重：

1.服务器维度

2.策略维度

3.多维度

4.计算同策略两次连续报警的时间间隔

5.最大等待时间

#####################################