0%

大型互联网公司运维体系

今天听了下百度的朋友讲了百度现有的运维体系,感觉还是很不错的,比较适合大的方向把握。 第一个是运维的日常工作: 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. 最大等待时间

  • 本文作者: Timo
  • 本文链接: 3003.html
  • 版权声明: 本博客所有文章除特别声明外,均采用 BY-NC-SA 许可协议。转载请注明出处!