运维工具让你的开发运营更轻松

架构平台部 - 运营平台中心

Aresliang

Aresliang架构平台部 - 运营平台中心产品管理组

分机：７５７４

个人介绍

来看一些数据ITIL基础介绍运营平台中心产品介绍

Ag e nd a

服务器数　　　　 25867进程数 　　 64025域名数 　　 4864机房 　　　　 111业务集合 322业务总数　　　　 5075

我们为什么要建ＩＴＩＬ

还将以每年 80% 的速度增长

月突发事件平均数量： 3000 起 ；

故障平均定位时间： 23分钟；

ISD12月份各业务对外发布 450次；

我们为什么要建ＩＴＩＬ

我们为什么要建ＩＴＩＬ

30 多个亿 100 亿

我们的规模会有多大？

我们需要多强大的支持能力？

来看一些数据ITIL基础介绍运营平台中心产品介绍

Ag e nd a

IT 管理国际规范 --ITIL

•　 全称 IT Infrastructure Library

•　 从 1986 年开始被使用

• 　英国政府电脑局 (CCTA) 开发制定

• 　国际上唯一的关于 IT 服务管理的综合性准则

• 　国际性资格认证（基础级 / 主管级 / 经理级）

• 　有自己的国际性用户组织 (ITSMF)

• 　全球十万多家大型企业采用的管理模式 • 最新国际标准 ISO 20000

Ch

ange

Config

Help

Desk

Prob

lem

Cost

SLM

Avail

Co

ntingency

Opera

tions

Cap

acity

Security

http://www.itil.co.uk

• IT 服务管理的“最佳实践”，而不是抽象的方法论 !

• 优化 IT 环境 / 基础设施管理的系统化、实用的方法：● 运行和维护现有系统● 开发新的系统● 使 IT 服务和业务需求保持一致

ITIL 的好处

HP － ITSM 方法论

服务保障协议

安全管理

连续性管理

可用性管理

服务能力管理

财务管理

IT服务体系开发&测试

IT服务系统发布&试运营

服务等级管理

变更管理

配置管理

运营管理

问题管理

事件及服务请求管理

服务体系发展规划

IT 战略规划及整体架构设计

客户管理

IT 系统评估

如何实施 ITIL

配置管理 CMDB

客

户

服务台

突发事件管理

问题管理

变更管理

发布管理

专家建议：应用 ITIL ，一般从服务支持环节着手。服务支持环节包括包含 5 个流程：事件管理、问题管理、变更管理、配置管理和软件发布管理，它们之间互为补充。 ITIL 的实施过程中，配置管理是核心。

传统的 IT 管理和 ITS M 比较

ITSM的核心思想是：IT组织，不管它是企业内部的还是外部的，都是 IT服务提供者，其主要工作就是提供低成本、高质量的 IT服务。IT服务的质量和成本则需从 IT服务的客户（购买 IT服务的）和用户（使用IT服务的）方加以判断。ITSM也是一种 IT管理。不过与传统的 IT管理不同，它是一种以服务为中心的 IT 管理。

IT 服务管理的核心思想

来看一些数据ITIL基础介绍运营平台中心产品介绍

Ag e nd a

质量基础数据

运营平台中心

成本

４个产品线３１个子产品

效率

服务目录介绍

运营环境基础数据

配置管理系统● 服务器● 业务● 软件● 网络设备● 网络专线● IP● 域名● LVS● 存储● IDC资源● ADS

业务监控体系（ S e rvic eVie w ）

● 基础服务器监控● URL监控● 基础网络监控● 模块间调用监控● 智能分析监控● 综合故障管理平台● 容量管理

质量基础数据

2007

成本效率

运营质量

ITIL 流程建设● 事件管理● Server Desk● 问题管理● 需求门户● IDC需求管理● IDC变更管理● 设备分配管理● 值班系统● 8000报障系统

基础数据

成本

2007

效率

质量

运营效率

效率

公共运维平台建设

● 发布管理

● 作业自动化平台

● 自动化编译

基础数据

成本

2007

质量

控制运营成本

ITIL 流程建设

● OMS CA 系统基础数据

成本

2007

效率

质量

产品线体系

价值 - 运维的工作及重心转变

22

1. 日常发布及相关沟通协调工作 ×2. 扩容工作 ×3. 投诉的二线支持 ×4. 数据迁移 / 提取 ×5. IDC 软硬件故障维护 ×

1. 配置管理2. 运营数据分析3. 立体化监控及异常发现4. 代码编译检查5. 可运营规范及推进开发优化6. … …

重心

日常操作救火

运营分析优化改进监控预防

工具化、智能化及自动化持续优化和规范环境，降低复杂

度

举措

进化

配置管理系统

配置管理是一项关键过程，负责对所有版本的硬件、软件、文档、过程、程序及信息技术（ IT）机构内其它无生命组成要素进行识别、控制和跟踪。配置管理的目标在于，确保

只有经过授权的组件才能在IT 环境中得到应用，并对所有变更调整实施记录和跟踪。

什么是配置管理

配置管理 CMDB

服务台

突发事件管理

问题管理

变更管理

发布管理

定位

25

真实准确的反应公司运营环境的配置状况

为其他 ITIL流程、各类运营管控流程提供配置数据支持

能够计量运营环境所有资产和配置项的价值

能够分析和评价公司运营环境的整体服务能力

价值

系统结构

配置核心支撑平台 管理平台接口

基于场景的配置管理模块

网管

OMSCA

变更系统

RTools

…

CMDB

Auto Discovery System

高级配置管理模块

接口

系统结构

配置核心支撑平台 管理平台接口

基于场景的配置管理模块

网管

OMSCA

变更系统

RTools

…

CMDB

Auto Discovery System

高层配置管理模块

接口

配置核心支撑平台（包括配置系统核心的数据库 (CMDB)和管理模型、接口、管理工具 (定义及配置管理、用户管理、角色权限管理、日志管理、通用增删改、通用查询检索）

系统结构

配置核心支撑平台 管理平台接口

基于场景的配置管理模块

网管

OMSCA

变更系统

RTools

…

CMDB

Auto Discovery System

高层配置管理模块

接口

基于场景的配置管理模块（为了提高批量操作，简化配置管理的复杂性，而引入的基于场景的配置管理模块）

系统结构

配置核心支撑平台 管理平台接口

基于场景的配置管理模块

网管

OMSCA

变更系统

RTools

…

CMDB

Auto Discovery System

高层配置管理模块

接口

高层配置管理模块（以配置数据的管理为核心的高层增值管理模块，如综合管理试图）

系统结构

配置核心支撑平台 管理平台接口

基于场景的配置管理模块

网管

OMSCA

变更系统

RTools

…

CMDB

Auto Discovery System

高层配置管理模块

接口

Auto Discovery System（用于数据的自动发现、自动采集、自校验和诊断的系统）

系统结构

配置管理支撑平台 管理平台接口

基于场景的配置管理模块

网管

OMSCA

变更系统

RTools

…

CMDB

Auto Discovery System

高层配置管理模块

接口

周边配套系统（主要不是用于配置管理的系统，但需要存取 CMDB中的数据的系统）

系统界面 :/ / . .http S e rve r itil c o m

业务监控体系

什么是业务健康 业务在功能、容量等相关方面体现出来的各项可监控数的

总称。当个别或部分数据不满足标准阀值时我们称业务为亚 健康或不健康的，反之业务为健康的。

我们为什么需要立体化监控 一个良好、全面、完善的业务健康立体化监控体系，能够

帮助我们准确，及时、完善地了解业务各个层面的生存情况，并最终实现对业务的量化管理。怎样才算立体化监控

一个从外部 / 内部、从业务 / 基础环境、从功能 /性能、从预算 /收入等各个方面对业务数据进行采集、展现和告警的体系

3 个 W

用户分析

我们的用户是谁● 运维人员● 业务主管● 中高层领导

我们面临的需求是什么运维人员：

通过对各层次的数据的展示和告警设置 ,快速直观的发现和定位故障

运维主管： 通过对各层次的数据的展示 , 来反应业务的容量和性 能 , 通过

设置阀值来对业务的容量和性能进行告警公司中高层：

通过对各层次数据的量化 , 来量化业务运行的监控度

发现快、定位准

直观、全面的了解业务情况

业务情况量化了解

提供腾讯唯一、准确的运营信息采集、传输、存储的渠道

及时、准确的发现故障及辅助故障定位、排障

向其他业务系统提供高效、规范、稳定可靠的运营数据接口

定位和价值

智能数据分析

数据采集

用户体验 业务特性 模块间调用监控

模块进程/模块端口/模块特性监控

OS/Device 网路/IDC

业务逻辑

监控数据中心

监控数据存储 监控数据管理 基础数据视图

容量/预算分析模型

告警

分析

模型

定位

分析

模型

财务分析模型 其他分析模型

财务数据

ＣＭＤＢ

自动化采集系统

决策支持

容量管理 告警／定位平台

业务健康管理 利润分析／展示

安全

行为

安全管理

行为管理

逻辑结构

监控层次

产品

业务

模块组

模块

业务功能

用例

用例操作 组件 （具体到ＩＰ）

基础资源

外部监控

业务内监控

基础监控

产品体系架构（三横两纵）用户体验监控系统 用户体验定位系统

业务特性监控系统

外部监控

业务逻辑监控系统 模块间调用监控系统

业务模块监控系统

业务内部监控

基础环境监控

基础设备监控系统 基础网络监控系统

统一告警平台

告警关联模型库

统一告警渠道

智能分析平台

公司级网管 http://monitor.itil.com

二级网管ISD http://isd.itil.comIED http://ied.iti.com

无线 http://mqq.itil.com 网站 http://info.itil.com 即通 http://srv.itil.com 运支 http://oss.itil.com

基础设备监控系统

基础网管架构层次

Agent 数据接入层

数据 Cache层

数据逻辑运算层

DB,文件存储层

数据访问接口层

Web 展示层

采集的网络 , 主机数据, 业务插件接入数据

最近访问数据内存缓冲

告警分析 , 数据分析 ,叠加运算等

主机性能数据 , 告警等历史数据

各种数据访问方法 ,访问协议适配方法

基于 iis 的 aps.net 和apache cgi web 应用展示

网管公共组件库(.so)

数据流

核心价值 - 故障主动发现和定位能力

核心价值 - 故障主动发现和定位能力

核心价值 - 采集的数据挖掘展现

核心价值 - 挖掘展现：服务器负载分析

ISD模块间调用监控系统

无线模块间调用监控系统

运支模块间调用监控系统

模块间调用监控系统

模块间调用监控系统现状及原状对比

49

1. 运维人员需要做大量的数据查找工作2. 运维人员需要做大量的数据统计工作3. 定位问题要经过多次尝试4. 对模块间调用的监控粒度不更细

1. 提供数据支持 ,让分析更轻松2. 发现问题及时及准确3. 使定位问题更直观4. 使对模块间调用的监控粒度更细5. 使对模块间调用的告警更直观6. … …

原状

原状 : 现状 :

模块间调用原状特点

运维人员需要做大量的数据查找工作在公司的日志集中平台需要做大量的手工查找工作查找工作比较耗事且不够准确；

运维人员需要做大量的统计工作定位问题需要经过多次尝试 , 效率低监控粒度不细

50

模块间调用原状特点

运维人员需要做大量的数据查找工作运维人员需要做大量的统计工作在公司的日志集中平台需要做大量的手工统计工作统计工作比较烦琐；

定位问题需要经过多次尝试 , 效率低监控粒度不细

51

模块间调用原状特点

运维人员需要做大量的数据查找工作运维人员需要做大量的统计工作定位问题需要经过多次尝试 , 效率低

模块间调用故障原因比较复杂，多重故障现象交错；如出问题需要从单机、网络、机房、业务特性等多方面反复排除定位，效率极低

监控粒度不细

52

模块间调用原状特点

运维人员需要做大量的数据查找工作运维人员需要做大量的统计工作定位问题需要经过多次尝试 , 效率低监控粒度不细

模块间调用只监控到模块层不能监控到模块之间的相互调用的性能及请求量；

53

产品架构

Qzone Service

QQshow Service

QQ音乐 Service

Log local Api

Log msg

Log msg

Log Server

Local log agernt

Local file

Log msg

Log files

Log msg

Data Process

处理插件

处理插件

Result Files

Data Sender

Qzone QQshow QQ音乐

Collector

FileCache

Alarmsvr NMData

NMTASK

IIS 中间件

告警库

内存cache数

据

数据采集服务器

部门二级网管服务器

业务数据

部门网管web服务器

用户IE

部门二级网管日志预处理机制日志集中平台

Collector接收所有agent数据并转发

订阅该数据的各级网管服务器

FileCache接收agent数据包，做cache和历史转存文件

Alarmsvr分析agent数据产生存储告

警

NMTask接收Web端的数据查询告警

功能

NMData对agent数据进行叠加等运

算

提供客户端页面浏览服务器

54

日志集中平台 ---local LogApi

Service 1

……

Service n

Local Log API

Log msg

Log msg

Log msg

Local Log Transfer Agent

Local log fileLog msg

Log msg

55

日志预处理机制

Log files

Data Process

处理插件

处理插件

Result files

Data Sender

二级网管

预处理机制由 Data Process 、 Data Sender两个模块组成

Data Process通过插件形式加载不同的处理逻辑

插件需要实现 handle_init 、 handle_process 、 handle_write_result几个接口

Data Sender负责将本地的结果数据发送给二级网管

56

日志预处理机制说明

由于处理结果集可能很大，因此考虑将结果发送独立 出来。预处理系统由数据处理和结果发送两个模块组成

处理模块的结果跟 log server的输出格式一致，结果发送模块读取后再发送给二级网管。目的是如果单个log id的数据一台机器处理不过来， forward到多台机器分别预处理，然后再通过一台机器汇总，汇总的机器可以用同一套程序 数据处理模块通过插件方式加载数据处理算法不同的处理算法启动多套程序处理，数据也需要分开保存。譬如模块间调用的 log数据、业务 log数据应该

分开不同目录保存

57

消灭隐患 - 提升业务可用率和产品质量

通过解决潜在的问题和隐患，将业务故障消灭在发生前，促进 BU的运维管理逐步从救火到预防发展和转变。

质量提升案例

没有模块间调用监控的时候（以前）产品质量问题多，定位难，跟踪麻烦，长期得不到解决。上级主管常常一周询问运维主管好几次，本周的重大故障定位和解决情况如何，还有什么可能发生的情况存在。

有了模块间调用监控（现在）上级主管一个月会询问运维主管一、两次关于重大故障定位和解决情况。

快速、准确的定位 - 提升运营效率

通过模块间调用的返回值及调用结果，使开发、运维人员定位故障的时间提升了 35%。

以前平均定位时间 :23分，数据来源于 ISD突发事件管理系统现在平均定位时间 14.95分，数据来源于模块间调用监控系统邮件订阅点评功能

效率提升案例

业务：会员功能：会员头像问题：会员头像显示速度慢，不稳定，用户体验感很差没有模块间调用前：根据经验定位，估计是即通的接口返回速度慢。与即通沟通后，答复接口没有问题。问题只得搁置一直得不到解决。

接入模块间调用后通过调用数据分析发现，即通的接口返回速度快，没有任何问题网盘接口的调用返回速度慢，失败率高通过排查发现：网盘提供的接口业务逻辑不稳定，有过多的冗余日志操作优化相关代码，问题得到解决从发现问题到具体定位： 3个工作日

为业务发展和决策提供数据支持

提供成功率、响应时间等 7个维度业务分析数据，为业务的扩容、迁移等决策提供了数据支持。以 QQ会员自定义图像为例，扩容前QQ会员自定义图像调用网络硬盘 qqdisk上传接口成功率为 81.51%、响应时间为3.52秒，通过数据分析，扩容后QQ会员自定义图像调用网络硬盘 qqdisk上传接口成功率为 99.9%、响应时间为 197.79毫秒， CGI 自动化测试时间由 2.4秒下降到现在的 800毫秒，大大提高了产品质量，提升了产品的用户体验感。

对不达标 CGI 业务潜在隐患的实时跟踪

★ 通过模块间邮件订阅和日分析报告，对任何一个不达标的cgi 业务模块的潜在隐患，从根本层面形成了BU在每天的业务故障跟踪方面的制度，这一方面在监控技术的发展和思路方面

是一个大的进步

后续建设计划结合配置管理，真实的勾画业务的内部调用结构图，使业务内部结

构透明化。

后续建设计划

结合自动化测试系统，进行数据的深度分析，打通外部调用和内部调用之间的联系，精确监控每次外部请求的逻辑走向，形成业务调

用逻辑有序图 ，使定位更加快速、直观

突发事件管理

服务支持流程

事件管理流程用于记录跟踪和监控事件

客服工单系

统网管系统

运维人员自

行发现

事件识别

（服务台）

事件记录

事件分类

是否属于服务

请求转入服务请求

事件处理优先级

是否属于重大

运维故障重大运维故障处理

初步支持

调查诊断

解决和恢复

事件关闭

是

否

否

是

是否需要职能升级

职能升级2/3线处理是

否

结束

事件管理目标最快恢复正常服务；尽量减少对业务的不利影响；确保最可能的服务级别的质量，维护 SLA条款的有效性；

反应公司平均故障解决时长、计算各个业务的可用率

单据类型

被动

主动

事件

维护单

客服

自动监控 /运维发现

突发事件

监控单

投诉单

服务请求（管工事件）

有影响

无影响

管工BU

处理部门？

标红色是为目前未实现

变更实施解决故障

产品关联图

事件管理 问题管理

变更管理 配置管理

服务台

变更请求 提供

配置信息

配置变化通知

提供配置信息

提供配置信息

趋势分析

避免故障重复出现

监控告警

客服工单

投诉单

事件系统的价值和定位

S L A确

定及签

署

事件的记录及处理

S L A的阶段

核算及监

控

绩效及

评价考

核

SLA优化及改进措施

年度系统建

设及优化规

划

系统建设及优化实施

S L A偏离整

改及行动方

案

系统改进及

优化

系统建设

项目评估

评价

图：可用性管理与项目建设的推进协作

解决方案及成果

解决方案 项目收益

事件记录

公司统一事件录入平台，记录跟踪事件处理直至最终解决

1.将原来分散在工单系统、事件系统和 BU内部的运维数据录入统一的事件管理平台中2. 公司只建设一套系统，各部门不用投入重复开发3.将 ISD/IED对事件管理的管理和规范推广到其他部门

管理支持

建立服务目录和级别管理模块 1.在统一平台上展现管工 SLA以及 BU可用性统计等重要运营数据和报表，可以纵向对比运营质量2. 支持管工、客服、 BU针对数据分析，进行管理决策3. 支持对运维人员的服务质量和运维质量考评

ITIL其他系统建设

统一后续问题管理，知识库管理的建设，减少重复投入

1. 通过各相关系统提供的接口，预留变更管理、问题管理接口，并在统一平台上展现管工 SLA以及 BU可用性统计等重要运营数据和报表2.已支持与 ISD问题管理系统接口，实现初步的问题管理升级模式

阶段目标

夯实基础

精耕细作

拓展

08Q1 08Q2 08Q4

•事件数据源的完善；•改进事件系统的易用性•统一考核指标、关键统计•服务台建设第一期•系统优化，组件化提高

•事件系统与配置系统、网管系统、问题系统、变更系统的数据集成，•建立公司级统一的可用性度量和评价体系•系统优化，组件化提高

•事件数据源的完善，管理精细化；监控单、突发事件单、管工事件单、维护单

整合

08Q3

•服务台建设第二期•问题管理的建设•系统优化，组件化提高

V3.2

V3.3

V4.0

系统界面 :/ / . .http he lp e r itil c o m

发布管理

公司发布工作以前存在的问题

大量的发布仍处于手工或者半自动化运作方式，效率低；由于历史原因，现实环境非常复杂，开发管理不规范，导致发布工作的复杂性高，导致发布容易出错；现有的系统工具虽然能够实现一定程度的自动化，但应用还不够系统化；在权限管理和规范化方面，还有待提高；缺乏同其他相关应用或系统，如配置系统、报警系统的关联和集成；发布管理缺乏健全的管理规范和培训体系；各 BU在发布管理上参差不齐，发布工具不统一，在自动化工具的实现上，也具有非常大的差异；

75

发布管理解决方案的层面

发布管理

发布工具及管理系统

ICT基础架构

从发布管理、发布工具及系统、 ICT架构三个层面去改进发布管理。1. 明确相关岗位角色，区分发布操作岗、发布管理审计、发布工

具管理维护等角色，建立岗位职责；2. 建立《发布管理规范》，对发布工作进行严格管理；3. 开展相应的人员培训及教育；

1. 建立 TOMS-ARS 软件系统和打包工具；2. 实现发布过程的自动化；3. 固化相关的关键控制点和权限控制；4. 实现同公司相关系统的集成和整合；

1. 建立预发布机备份管理；2. 对测试环境及编译环境进行梳理；3. 规范产品、模块在编译环境、测试环境和预发布环境中的映射

；4. 梳理配置系统，建立配置关系，推动应用系统配置的完整性和准确性；

5. 梳理 IDC生产环境，提高生产环境的一致性，降低复杂性；

通过自动化发布，提升发布质量和效率，减少误操作，保证发布安全性；梳理和规范发布流程，促进发布环境管理；版本管理，进行版本的快速恢复；任务管理，有效提升windows服务器维护效率；控制开发环境对生产环境的访问，保证安全性；公司统一发布平台。

价值

ARS 发布推广情况

部门 对象业务 接口人 现状

IS D

Qz o ne

wa yne wa ng1 、已经覆盖 80IS D ％的发布工作；2 、剩余 20 ％的 IS D 发布计划在 2Q实现覆盖（主要是包的增量发布）；

QQ 秀QQ 会员QQ 相册QQ 交友QQ 音乐Ima g e c a c he

IED

寻仙

le o xio ng 、 fe lixwa ng

1 、飞行岛发布稳定。2 、 1 .0PET 正常进行了多次正式环境发布。3 、 CF 进行了多次正式发布。4 、其它多个产品处于试用中。

QQ 宠物 1 .0飞行岛QQ 宠物 2 .0CFQQ 幻想

无线

手机 QQ , ,a myli ye n s te,ve q ia o wing z

ho u

1 、手机 QQ 发布稳定。2 、 VOIP 进行了多次正式发布。3 、其它多个产品处于试用中。

无线音乐无线平台服务VOIP

创新中心 QQ 客服

ja c kye1 、频道应用发布稳定。网站部 频道应用

国际产品中心 美国 QQGa me广告部 QQlive运营支持部 . .p a y q q c o m ha iryxie 发布数量稳定。电子商务部 　 e a g le 已完成部署，试用中在线支付部 财富通 a a ro nz he ng 完成了新环境的部署，试用中。

红色代表基本覆盖所有产品

蓝色代表部分产品覆盖

白色代表正在试用中

ARS 发布数据

注明：1 、图表中所示为发布次数，不是发布版本数，因为一个版本可能会发布多次；2 、互动娱乐和无线产品部的发布次数中包含试用次数。

ARS 版本计划

V3.2Mar 2008

V3.2 Beta02 Apr 6,2008

V3.0Dec 2007

V3.1Jan 2008

ARS V3.2 主要进行 windows移植开发、 Linux 整改、包发布、 task完善。

V3.2 Beta03Apr 22,2008

V3.3Jul 2008

V3.2 Beta04May 15,2008 V3.2 Beta05

May 23,2008

V3.2 Beta06Jun 6,2008 V3.2 Beta07

Jun 17,2008

V3.2 Beta08Jun 27,2008

公共运维平台的规划

发布管理 任务管理 TSH监控管理

用户管理 权限管理 操作日志管理安全管理

公共运维平台

发布自动化发布平台化发布审批

发布计划管理版本管理

公共软件的发布管理

命令 /脚本集中管理（编辑 / 查看 /保存）

任务的权限管理任务手工 / 定时自动调用任务执行结果查看

进程状态监控；版本状态查询；

自动 /手工重启进程；

用户分权分组管理操作进行分类管理

记录 / 查看用户在公共运维平台的所有操作

公共运维平台的拓扑图

Rnet

Dnet

IDC

ARS 服务器

编译机池

生产机

生产机

办公网

…测试机池

…预发布机池

…

ARS 备份服务器

……

公共运维平台定位

IDC

RNet

办公网

… …

……

控制以及审计对生产环境的访问

发布系统： http://rtools.itil.com