大型互联网公司运维体系

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