1、运维工具让你的开发运营更轻松,架构平台部-运营平台中心 Aresliang,Aresliang 架构平台部-运营平台中心 产品管理组分机:,个人介绍,来看一些数据 ITIL基础介绍 运营平台中心产品介绍,Agenda,服务器数 25867 进程数 64025 域名数 4864 机房 111 业务集合 322 业务总数 5075,我们为什么要建,还将以每年80%的速度增长,月突发事件平均数量:3000起 ;故障平均定位时间:23分钟;ISD12月份各业务对外发布450次;,我们为什么要建,我们为什么要建,30多个亿,100亿,我们的规模会有多大?,我们需要多强大的支持能力?,来看一些数据 ITI
2、L基础介绍 运营平台中心产品介绍,Agenda,IT管理国际规范-ITIL,全称 IT Infrastructure Library从1986年开始被使用英国政府电脑局(CCTA)开发制定国际上唯一的关于IT服务管理的综合性准则国际性资格认证(基础级/主管级/经理级)有自己的国际性用户组织 (ITSMF)全球十万多家大型企业采用的管理模式最新国际标准ISO 20000,Change,Config,Help Desk,Problem,Cost,SLM,Avail,Contingency,Operations,Capacity,Security,http:/www.itil.co.uk,IT服务管
3、理的“最佳实践”,而不是抽象的方法论 !优化IT 环境/基础设施管理的系统化、实用的方法: 运行和维护现有系统 开发新的系统 使IT服务和业务需求保持一致,ITIL的好处,HPITSM方法论,如何实施ITIL,客户,服务台突发事件管理,问题管理,变更管理,发布管理,专家建议:应用ITIL,一般从服务支持环节着手。服务支持环节包括包含5个流程:事件管理、问题管理、变更管理、配置管理和软件发布管理,它们之间互为补充。ITIL的实施过程中,配置管理是核心。,传统的IT管理和ITSM比较,ITSM的核心思想是: IT组织,不管它是企业内部的还是外部的,都是IT服务提供者,其主要工作就是提供低成本、高质
4、量的IT服务。 IT服务的质量和成本则需从IT服务的客户(购买IT服务的)和用户(使用IT服务的)方加以判断。 ITSM也是一种IT管理。不过与传统的IT管理不同,它是一种以服务为中心的IT管理。,IT服务管理的核心思想,来看一些数据 ITIL基础介绍 运营平台中心产品介绍,Agenda,质量,基础 数据,运营平 台中心,成本,个产品线 个子产品,效率,服务目录介绍,运营环境基础数据,配置管理系统 服务器 业务 软件 网络设备 网络专线 IP 域名 LVS 存储 IDC资源 ADS 业务监控体系(Service View) 基础服务器监控 URL监控 基础网络监控 模块间调用监控 智能分析监控
5、 综合故障管理平台 容量管理,质量,基础 数据,2007,成本,效率,运营质量,ITIL流程建设 事件管理 Server Desk 问题管理 需求门户 IDC需求管理 IDC变更管理 设备分配管理 值班系统 8000报障系统,基础 数据,成本,2007,效率,质量,运营效率,效率,公共运维平台建设发布管理作业自动化平台自动化编译,基础 数据,成本,2007,质量,控制运营成本,ITIL流程建设OMSCA系统,基础 数据,成本,2007,效率,质量,产品线体系,价值-运维的工作及重心转变,22,日常发布及相关沟通协调工作 扩容工作 投诉的二线支持 数据迁移/提取 IDC软硬件故障维护 ,配置管理
6、 运营数据分析 立体化监控及异常发现 代码编译检查 可运营规范及推进开发优化 ,重心,日常操作 救火,运营分析 优化改进 监控预防,工具化、智能化及自动化 持续优化和规范环境,降低复杂度,举措,进化,配置管理系统,配置管理是一项关键过程,负责对所有版本的硬件、软件、文档、过程、程序及信息技术(IT)机构内其它无生命组成要素进行识别、控制和跟踪。 配置管理的目标在于,确保只有经过授权的组件才能在 IT 环境中得到应用,并对所有变更调整实施记录和跟踪。,什么是配置管理,服务台突发事件管理,问题管理,变更管理,发布管理,定位,25,真实准确的反应公司运营环境的配置状况为其他ITIL流程、各类运营管控
7、流程提供配置数据支持能够计量运营环境所有资产和配置项的价值能够分析和评价公司运营环境的整体服务能力,价值,系统结构,配置核心支撑平台,管理平台,接口,基于场景的配置管理模块,网管,OMSCA,变更系统,RTools,CMDB,Auto Discovery System,高级配置管理模块,接口,系统结构,配置核心支撑平台,管理平台,接口,基于场景的配置管理模块,网管,OMSCA,变更系统,RTools,CMDB,Auto Discovery System,高层配置管理模块,接口,配置核心支撑平台 (包括配置系统核心的数据库(CMDB)和管理模型、接口、管理工具(定义及配置管理、用户管理、角色权限
8、管理、日志管理、通用增删改、通用查询检索),系统结构,配置核心支撑平台,管理平台,接口,基于场景的配置管理模块,网管,OMSCA,变更系统,RTools,CMDB,Auto Discovery System,高层配置管理模块,接口,基于场景的配置管理模块 (为了提高批量操作,简化配置管理的复杂性,而引入的基于场景的配置管理模块),系统结构,配置核心支撑平台,管理平台,接口,基于场景的配置管理模块,网管,OMSCA,变更系统,RTools,CMDB,Auto Discovery System,高层配置管理模块,接口,高层配置管理模块 (以配置数据的管理为核心的高层增值管理模块,如综合管理试图),
9、系统结构,配置核心支撑平台,管理平台,接口,基于场景的配置管理模块,网管,OMSCA,变更系统,RTools,CMDB,Auto Discovery System,高层配置管理模块,接口,Auto Discovery System (用于数据的自动发现、自动采集、自校验和诊断的系统),系统结构,配置管理支撑平台,管理平台,接口,基于场景的配置管理模块,网管,OMSCA,变更系统,RTools,CMDB,Auto Discovery System,高层配置管理模块,接口,周边配套系统 (主要不是用于配置管理的系统,但需要存取CMDB中的数据的系统),系统界面 http:/S,业务监控体系,什么是
10、业务健康业务在功能、容量等相关方面体现出来的各项可监控数的总称。当个别或部分数据不满足标准阀值时我们称业务为亚健康或不健康的,反之业务为健康的。 我们为什么需要立体化监控一个良好、全面、完善的业务健康立体化监控体系,能够 帮助我们准确,及时、完善地了解业务各个层面的生存情 况,并最终实现对业务的量化管理。 怎样才算立体化监控一个从外部/内部、从业务/基础环境、从功能/性能、从预算/收入等各个方面对业务数据进行采集、展现和告警的体系,3个W,用户分析,我们的用户是谁 运维人员 业务主管 中高层领导 我们面临的需求是什么 运维人员:通过对各层次的数据的展示和告警设置,快速直观的发现和定位 故障 运
11、维主管:通过对各层次的数据的展示,来反应业务的容量和性 能,通过 设置阀值来对业务的容量和性能进行告警 公司中高层:通过对各层次数据的量化,来量化业务运行的监控度,发现快、定位准,直观、全面的了解业务情况,业务情况量化了解,提供腾讯唯一、准确的运营信息采集、传输、存储的渠道及时、准确的发现故障及辅助故障定位、排障向其他业务系统提供高效、规范、稳定可靠的运营数据接口,定位和价值,逻辑结构,监控层次,产品,业务,模块组,模块,业务功能,用例,用例操作,组件 (具体到),基础资源,外部监控,业务内监控,基础监控,产品体系架构(三横两纵),用户体验监控系统,用户体验定位系统,业务特性监控系统,外部 监
12、控,业务逻辑监控系统,模块间调用监控系统,业务模块监控系统,业务内部 监控,基础环境监控,基础设备监控系统,基础网络监控系统,统一告警平台告警关联模型库统一告警渠道,智能分析平台,公司级网管 http:/二级网管 ISD http:/ IED http:/ 无线 http:/ 网站 http:/ 即通 http:/ 运支 http:/,基础设备监控系统,基础网管架构层次,Agent数据接入层,数据Cache层,数据逻辑运算层,DB,文件存储层,数据访问接口层,Web展示层,采集的网络,主机数据,业务插件接入数据,最近访问数据内存缓冲,告警分析,数据分析,叠加运算等,主机性能数据,告警等历史数据
13、,各种数据访问方法,访问协议适配方法,基于iis的和apache cgi web应用展示,网管公共组件库(.so),数据流,核心价值-故障主动发现和定位能力,核心价值-故障主动发现和定位能力,核心价值-采集的数据挖掘展现,核心价值-挖掘展现:服务器负载分析,ISD模块间调用监控系统无线模块间调用监控系统运支模块间调用监控系统,模块间调用监控系统,模块间调用监控系统现状及原状对比,49,运维人员需要做大量的数据查找工作 运维人员需要做大量的数据统计工作 定位问题要经过多次尝试 对模块间调用的监控粒度不更细,提供数据支持,让分析更轻松 发现问题及时及准确 使定位问题更直观 使对模块间调用的监控粒度
14、更细 使对模块间调用的告警更直观 ,原状,原状:,现状:,模块间调用原状特点,运维人员需要做大量的数据查找工作 在公司的日志集中平台需要做大量的手工查找工作 查找工作比较耗事且不够准确; 运维人员需要做大量的统计工作 定位问题需要经过多次尝试,效率低 监控粒度不细,50,模块间调用原状特点,运维人员需要做大量的数据查找工作 运维人员需要做大量的统计工作 在公司的日志集中平台需要做大量的手工统计工作 统计工作比较烦琐; 定位问题需要经过多次尝试,效率低 监控粒度不细,51,模块间调用原状特点,运维人员需要做大量的数据查找工作 运维人员需要做大量的统计工作 定位问题需要经过多次尝试,效率低 模块间
15、调用故障原因比较复杂,多重故障现象交错;如出问题需要从单机、网络、机房、业务特性等多方面反复排除定位,效率极低 监控粒度不细,52,模块间调用原状特点,运维人员需要做大量的数据查找工作 运维人员需要做大量的统计工作 定位问题需要经过多次尝试,效率低 监控粒度不细 模块间调用只监控到模块层 不能监控到模块之间的相互调用的性能及请求量;,53,产品架构,54,日志集中平台-local LogApi,55,日志预处理机制,预处理机制由Data Process、Data Sender两个模块组成 Data Process通过插件形式加载不同的处理逻辑 插件需要实现handle_init、handle_
16、process、 handle_write_result几个接口 Data Sender负责将本地的结果数据发送给二级网管,56,日志预处理机制说明,由于处理结果集可能很大,因此考虑将结果发送独立出来。预处理系统由数据处理和结果发送两个模块组成 处理模块的结果跟log server的输出格式一致,结果发送模块读取后再发送给二级网管。目的是如果单个log id的数据一台机器处理不过来,forward到多台机器分别预处理,然后再通过一台机器汇总,汇总的机器可以用同一套程序 数据处理模块通过插件方式加载数据处理算法 不同的处理算法启动多套程序处理,数据也需要分开保存。譬如模块间调用的log数据、业务
17、log数据应该分开不同目录保存,57,消灭隐患-提升业务可用率和产品质量,通过解决潜在的问题和隐患,将业务故障消灭在发生前,促进BU的运维管理逐步从救火到预防发展和转变。,质量提升案例,没有模块间调用监控的时候(以前) 产品质量问题多,定位难,跟踪麻烦,长期得不到解决。上级主管常常一周询问运维主管好几次,本周的重大故障定位和解决情况如何,还有什么可能发生的情况存在。有了模块间调用监控(现在) 上级主管一个月会询问运维主管一、两次关于重大故障定位和解决情况。,快速、准确的定位-提升运营效率,通过模块间调用的返回值及调用结果,使开发、运维人员定位故障的时间提升了35%。 以前平均定位时间:23分,
18、数据来源于ISD突发事件管理系统 现在平均定位时间14.95分,数据来源于模块间调用监控系统邮件订阅点评功能,效率提升案例,业务:会员 功能:会员头像 问题:会员头像显示速度慢,不稳定,用户体验感很差 没有模块间调用前: 根据经验定位,估计是即通的接口返回速度慢。 与即通沟通后,答复接口没有问题。 问题只得搁置一直得不到解决。 接入模块间调用后 通过调用数据分析发现,即通的接口返回速度快,没有任何问题 网盘接口的调用返回速度慢,失败率高 通过排查发现:网盘提供的接口业务逻辑不稳定,有过多的冗余日志操作 优化相关代码,问题得到解决 从发现问题到具体定位:3个工作日,为业务发展和决策提供数据支持,
19、提供成功率、响应时间等7个维度业务分析数据,为业务的扩容、迁移等决策提供了数据支持。 以QQ会员自定义图像为例,扩容前QQ会员自定义图像调用网络硬盘qqdisk上传接口成功率为81.51%、响应时间为3.52秒,通过数据分析,扩容后QQ会员自定义图像调用网络硬盘qqdisk上传接口成功率为99.9%、响应时间为197.79毫秒,CGI自动化测试时间由2.4秒下降到现在的800毫秒,大大提高了产品质量,提升了产品的用户体验感。,对不达标CGI业务潜在隐患的实时跟踪,通过模块间邮件订阅和日分析报告,对任何一个不达标的cgi业务模块的潜在隐患,从根本层面形成了BU在每天的业务故障跟踪方面的制度,这一
20、方面在监控技术的发展和思路方面是一个大的进步,后续建设计划,结合配置管理,真实的勾画业务的内部调用结构图,使业务内部结构透明化。,后续建设计划,结合自动化测试系统,进行数据的深度分析,打通外部调用和内部调用之间的联系,精确监控每次外部请求的逻辑走向,形成业务调用逻辑有序图 ,使定位更加快速、直观,突发事件管理,服务支持流程,事件管理流程用于记录 跟踪和监控事件,事件管理目标 最快恢复正常服务; 尽量减少对业务的不利影响; 确保最可能的服务级别的质量,维护SLA条款的有效性;,反应公司平均故障解决时长、计算各个业务的可用率,单据类型,标红色是为目前未实现,变更实施解决故障,产品关联图,事件管理,
21、问题管理,变更管理,配置管理,服务台,变更请求,提供配置信息,配置变化通知,提供配置信息,提供配置信息,趋势分析,避免故障重复出现,监控告警,客服工单,投诉单,事件系统的价值和定位,解决方案及成果,阶段目标,夯实基础,精耕细作,拓展,08Q1,08Q2,08Q4,事件数据源的完善; 改进事件系统的易用性 统一考核指标、关键统计 服务台建设第一期 系统优化,组件化提高,事件系统与配置系统、网管系统、问题系统、变更系统的数据集成, 建立公司级统一的可用性度量和评价体系 系统优化,组件化提高,事件数据源的完善, 管理精细化; 监控单、突发事件单、管工事件单、维护单,整合,08Q3,服务台建设第二期
22、问题管理的建设 系统优化,组件化提高,V3.2,V3.3,V4.0,系统界面 http:/,发布管理,公司发布工作以前存在的问题,大量的发布仍处于手工或者半自动化运作方式,效率低; 由于历史原因,现实环境非常复杂,开发管理不规范,导致发布工作的复杂性高,导致发布容易出错; 现有的系统工具虽然能够实现一定程度的自动化,但应用还不够系统化; 在权限管理和规范化方面,还有待提高; 缺乏同其他相关应用或系统,如配置系统、报警系统的关联和集成; 发布管理缺乏健全的管理规范和培训体系; 各BU在发布管理上参差不齐,发布工具不统一,在自动化工具的实现上,也具有非常大的差异;,75,发布管理解决方案的层面,发
23、布管理,发布工具及管理系统,ICT基础架构,从发布管理、发布工具及系统、ICT架构三个层面去改进发布管理。,明确相关岗位角色,区分发布操作岗、发布管理审计、发布工具管理维护等角色,建立岗位职责; 建立发布管理规范,对发布工作进行严格管理; 开展相应的人员培训及教育;,建立TOMS-ARS 软件系统和打包工具; 实现发布过程的自动化; 固化相关的关键控制点和权限控制; 实现同公司相关系统的集成和整合;,建立预发布机备份管理; 对测试环境及编译环境进行梳理; 规范产品、模块在编译环境、测试环境和预发布环境中的映射; 梳理配置系统,建立配置关系,推动应用系统配置的完整性和准确性; 梳理IDC生产环境
24、,提高生产环境的一致性,降低复杂性;,通过自动化发布,提升发布质量和效率,减少误操作,保证发布安全性; 梳理和规范发布流程,促进发布环境管理; 版本管理,进行版本的快速恢复; 任务管理,有效提升windows服务器维护效率; 控制开发环境对生产环境的访问,保证安全性; 公司统一发布平台。,价值,ARS发布推广情况,红色代表基本覆盖所有产品,蓝色代表部分产品覆盖,白色代表正在试用中,ARS发布数据,注明: 1、图表中所示为发布次数,不是发布版本数,因为一个版本可能会发布多次; 2、互动娱乐和无线产品部的发布次数中包含试用次数。,ARS 版本计划,V3.2 Mar 2008,V3.2 Beta02
25、 Apr 6,2008,V3.0 Dec 2007,V3.1 Jan 2008,ARS V3.2主要进行windows移植开发、Linux整改、包发布、task完善。,V3.2 Beta03 Apr 22,2008,V3.3 Jul 2008,V3.2 Beta04 May 15,2008,V3.2 Beta05 May 23,2008,V3.2 Beta06 Jun 6,2008,V3.2 Beta07 Jun 17,2008,V3.2 Beta08 Jun 27,2008,公共运维平台的规划,发布管理,任务管理,TSH,监控管理,用户管理,权限管理,操作日志管理,安全管理,公共运维平台,发布自动化 发布平台化 发布审批 发布计划管理 版本管理 公共软件的发布管理,命令/脚本集中管理(编辑/查看/保存) 任务的权限管理 任务手工/定时自动调用 任务执行结果查看,进程状态监控; 版本状态查询; 自动/手工重启进程;,用户分权分组管理 操作进行分类管理 记录/查看用户在公共运维平台的所有操作,公共运维平台的拓扑图,Rnet,Dnet,IDC,ARS 服务器,编译机池,生产机,生产机,办公网,测试机池,预发布机池,ARS 备份服务器,公共运维平台定位,IDC,RNet,办公网,控制以及 审计对生 产环境的 访问,发布系统: http:/,