该文档介绍了运维工具如何通过实施ITIL（信息技术基础设施库）来优化IT服务管理，强调了数据监控、故障定位与预防的重要性。文档提供了ITIL的基本概念、实施流程及其在运营平台中的应用，包括配置管理与运营效率提升的具体案例。通过模块间调用监控，故障定位时间得到显著缩短，业务可用率和产品质量提高。

1. 运维工具让你的开发运营更轻松 架构平台部 - 运营平台中心 Aresliang

2. Aresliang 架构平台部 - 运营平台中心 产品管理组 分机：７５７４ 个人介绍

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

4. 服务器数 25867 进程数 64025 域名数 4864 机房 111 业务集合 322 业务总数 5075 我们为什么要建ＩＴＩＬ 还将以每年 80% 的速度增长

5. 月突发事件平均数量： 3000 起 ； 故障平均定位时间： 23 分钟； ISD12 月份各业务对外发布 450 次； 我们为什么要建ＩＴＩＬ

6. 我们为什么要建ＩＴＩＬ 30 多个亿 100 亿 我们的规模会有多大？ 我们需要多强大的支持能力？

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

8. 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

9. IT 服务管理的 “ 最佳实践 ” ，而不是抽象的方法论 ! 优化 IT 环境 / 基础设施管理的系统化、实用的方法： 运行和维护现有系统 开发新的系统 使 IT 服务和业务需求保持一致 ITIL 的好处

10. HP － ITSM 方法论

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

12. 传统的 IT 管理和 ITSM 比较

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

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

16. 服务目录介绍 质量 基础 数据 运营平 台中心 成本 ４个产品线 ３１个子产品 效率

17. 运营环境基础数据 配置管理系统 服务器 业务 软件 网络设备 网络专线 IP 域名 LVS 存储 IDC 资源 ADS 业务监控体系（ Service View ） 基础服务器监控 URL 监控 基础网络监控 模块间调用监控 智能分析监控 综合故障管理平台 容量管理 质量 基础 数据 200 7 成本 效率

18. 运营质量 ITIL 流程建设 事件管理 Server Desk 问题管理 需求门户 IDC 需求管理 IDC 变更管理 设备分配管理 值班系统 8000 报障系统 基础 数据 成本 200 7 效率 质量

19. 运营效率 效率 公共运维平台建设 发布管理 作业自动化平台 自动化编译 基础 数据 成本 200 7 质量

20. 控制运营成本 ITIL 流程建设 OMSCA 系统 基础 数据 成本 200 7 效率 质量

21. 产品线体系

22. 价值 - 运维的工作及重心转变 日常发布及相关沟通协调工作 × 扩容工作 × 投诉的二线支持 × 数据迁移 / 提取 × IDC 软硬件故障维护 × 配置管理 运营数据分析 立体化监控及异常发现 代码编译检查 可运营规范及推进开发优化 … … 重心 日常操作 救火 运营分析 优化改进 监控预防 工具化、智能化及自动化 持续优化和规范环境，降低复杂度 举措 进化

23. 配置管理系统

24. 配置管理是一项关键过程，负责对所有版本的硬件、软件、文档、过程、程序及信息技术（ IT ）机构内其它无生命组成要素进行识别、控制和跟踪。 配置管理的目标在于，确保只有经过授权的组件才能在 IT 环境中得到应用，并对所有变更调整实施记录和跟踪。 什么是配置管理 服务台 突发事件管理 问题管理 变更管理 发布管理 配置管理 CMDB

25. 定位

26. 真实准确的反应公司运营环境的配置状况 为其他 ITIL 流程、各类运营管控流程提供配置数据支持 能够计量运营环境所有资产和配置项的价值 能够分析和评价公司运营环境的整体服务能力 价值

27. 系统结构 配置核心支撑平台 管理平台 接口 基于场景的配置管理模块 网管 OMSCA 变更系统 RTools … CMDB Auto Discovery System 高级配置管理模块 接口

28. 系统结构 配置核心支撑平台 管理平台 接口 基于场景的配置管理模块 网管 OMSCA 变更系统 RTools … CMDB Auto Discovery System 高层配置管理模块 接口 配置核心支撑平台 （包括配置系统核心的数据库 (CMDB) 和管理模型、接口、管理工具 ( 定义及配置管理、用户管理、角色权限管理、日志管理、通用增删改、通用查询检索）

29. 系统结构 配置核心支撑平台 管理平台 接口 基于场景的配置管理模块 网管 OMSCA 变更系统 RTools … CMDB Auto Discovery System 高层配置管理模块 接口 基于场景的配置管理模块 （为了提高批量操作，简化配置管理的复杂性，而引入的基于场景的配置管理模块）

30. 系统结构 配置核心支撑平台 管理平台 接口 基于场景的配置管理模块 网管 OMSCA 变更系统 RTools … CMDB Auto Discovery System 高层配置管理模块 接口 高层配置管理模块 （以配置数据的管理为核心的高层增值管理模块，如综合管理试图）

31. 系统结构 配置核心支撑平台 管理平台 接口 基于场景的配置管理模块 网管 OMSCA 变更系统 RTools … CMDB Auto Discovery System 高层配置管理模块 接口 Auto Discovery System （用于数据的自动发现、自动采集、自校验和诊断的系统）

32. 系统结构 配置管理支撑平台 管理平台 接口 基于场景的配置管理模块 网管 OMSCA 变更系统 RTools … CMDB Auto Discovery System 高层配置管理模块 接口 周边配套系统 （主要不是用于配置管理的系统，但需要存取 CMDB 中的数据的系统）

33. 系统界面 http://Server.itil.com

34. 业务监控体系

35. 什么是业务健康 业务在功能、容量等相关方面体现出来的各项可监控数的总称。当个别或部分数据不满足标准阀值时我们称业务为亚健康或不健康的，反之业务为健康的。 我们为什么需要立体化监控 一个良好、全面、完善的业务健康立体化监控体系，能够 帮助我们准确，及时、完善地了解业务各个层面的生存情 况，并最终实现对业务的量化管理。 怎样才算立体化监控 一个从外部 / 内部、从业务 / 基础环境、从功能 / 性能、从预算 / 收入等各个方面对业务数据进行采集、展现和告警的体系 3 个 W

36. 用户分析 我们的用户是谁 运维人员 业务主管 中高层领导 我们面临的需求是什么 运维人员： 通过对各层次的数据的展示和告警设置 , 快速直观的发现和定位 故障 运维主管： 通过对各层次的数据的展示 , 来反应业务的容量和性 能 , 通过 设置阀值来对业务的容量和性能进行告警 公司中高层： 通过对各层次数据的量化 , 来量化业务运行的监控度 发现快、定位准 直观、全面的了解业务情况 业务情况量化了解

37. 提供腾讯唯一、准确的运营信息采集、传输、存储的渠道 及时、准确的发现故障及辅助故障定位、排障 向其他业务系统提供高效、规范、稳定可靠的运营数据接口 定位和价值

38. 逻辑结构

39. 监控层次 产品 业务 模块组 模块 业务功能 用例 用例操作 组件 （具体到ＩＰ） 基础资源 外部监控 业务内监控 基础监控

40. 产品体系架构（三横两纵） 用户体验监控系统 用户体验定位系统 业务特性监控系统 外部 监控 业务逻辑监控系统 模块间调用监控系统 业务模块监控系统 业务内部 监控 基础环境监控 基础设备监控系统 基础网络监控系统 统一告警平台 告警关联模型库 统一告警渠道 智能分析平台

41. 公司级网管 http://monitor.itil.com 二级网管 ISD http://isd.itil.com IED http://ied.iti.com 无线 http://mqq.itil.com 网站 http://info.itil.com 即通 http://srv.itil.com 运支 http://oss.itil.com 基础设备监控系统

42. 基础网管架构层次 Agent 数据接入层 数据 Cache 层 数据逻辑运算层 DB, 文件存储层 数据访问接口层 Web 展示层 采集的网络 , 主机数据 , 业务插件接入数据 最近访问数据内存缓冲 告警分析 , 数据分析 , 叠加运算等 主机性能数据 , 告警等历史数据 各种数据访问方法 , 访问协议适配方法 基于 iis 的 aps.net 和 apache cgi web 应用展示 网管公共组件库 (.so)

43. 数据流

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

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

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

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

48. ISD 模块间调用监控系统 无线模块间调用监控系统 运支模块间调用监控系统 模块间调用监控系统

49. 模块间调用监控系统现状及原状对比 运维人员需要做大量的数据查找工作 运维人员需要做大量的数据统计工作 定位问题要经过多次尝试 对模块间调用的监控粒度不更细 提供数据支持 , 让分析更轻松 发现问题及时及准确 使定位问题更直观 使对模块间调用的监控粒度更细 使对模块间调用的告警更直观 … … 原状 原状 : 现状 :

50. 模块间调用原状特点 运维人员需要做大量的数据查找工作 在公司的日志集中平台需要做大量的手工查找工作 查找工作比较耗事且不够准确； 运维人员需要做大量的统计工作 定位问题需要经过多次尝试 , 效率低 监控粒度不细

51. 模块间调用原状特点 运维人员需要做大量的数据查找工作 运维人员需要做大量的统计工作 在公司的日志集中平台需要做大量的手工统计工作 统计工作比较烦琐； 定位问题需要经过多次尝试 , 效率低 监控粒度不细

52. 模块间调用原状特点 运维人员需要做大量的数据查找工作 运维人员需要做大量的统计工作 定位问题需要经过多次尝试 , 效率低 模块间调用故障原因比较复杂，多重故障现象交错 ；如出问题需要从单机、网络、机房、业务特性等多方面反复排除定位，效率极低 监控粒度不细

53. 模块间调用原状特点 运维人员需要做大量的数据查找工作 运维人员需要做大量的统计工作 定位问题需要经过多次尝试 , 效率低 监控粒度不细 模块间调用只监控到模块层 不能监控到模块之间的相互调用的性能及请求量；

54. 产品架构

55. 日志集中平台 ---local LogApi

56. 日志预处理机制 预处理机制由 Data Process 、 Data Sender 两个模块组成 Data Process 通过插件形式加载不同的处理逻辑 插件需要实现 handle_init 、 handle_process 、 handle_write_result 几个接口 Data Sender 负责将本地的结果数据发送给二级网管 Log files Data Process 处理插件 处理插件 Result files Data Sender 二级网管

57. 日志预处理机制说明 由于处理结果集可能很大，因此考虑将结果发送独立出来。预处理系统由数据处理和结果发送两个模块组成 处理模块的结果跟 log server 的输出格式一致，结果发送模块读取后再发送给二级网管。目的是如果单个 log id 的数据一台机器处理不过来， forward 到多台机器分别预处理，然后再通过一台机器汇总，汇总的机器可以用同一套程序 数据处理模块通过插件方式加载数据处理算法 不同的处理算法启动多套程序处理，数据也需要分开保存。譬如模块间调用的 log 数据、业务 log 数据应该分开不同目录保存

58. 消灭隐患 - 提升业务可用率和产品质量 通过解决潜在的问题和隐患，将业务故障消灭在发生前，促进 BU 的运维管理逐步从救火到预防发展和转变。

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

60. 快速、准确的定位 - 提升运营效率 通过模块间调用的返回值及调用结果，使开发、运维人员定位故障的时间提升了 35% 。 以前平均定位时间 :23 分，数据来源于 ISD 突发事件管理系统 现在平均定位时间 14.95 分，数据来源于模块间调用监控系统邮件订阅点评功能

61. 效率提升案例 业务：会员 功能：会员头像 问题：会员头像显示速度慢，不稳定，用户体验感很差 没有模块间调用前： 根据经验定位，估计是即通的接口返回速度慢。 与即通沟通后，答复接口没有问题。 问题只得搁置一直得不到解决。 接入模块间调用后 通过调用数据分析发现，即通的接口返回速度快，没有任何问题 网盘接口的调用返回速度慢，失败率高 通过排查发现：网盘提供的接口业务逻辑不稳定，有过多的冗余日志操作 优化相关代码，问题得到解决 从发现问题到具体定位： 3 个工作日

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

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

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

65. 后续建设计划 结合自动化测试系统，进行数据的深度分析，打通外部调用和内部调用之间的联系，精确监控每次外部请求的逻辑走向，形成业务调用逻辑有序图 ，使定位更加快速、直观

66. 突发事件管理

67. 服务支持流程 事件管理流程用于记录 跟踪和监控事件 事件管理目标 最快恢复正常服务； 尽量减少对业务的不利影响； 确保最可能的服务级别的质量，维护 SLA 条款的有效性； 反应公司平均故障解决时长、计算各个业务的可用率

68. 单据类型 标 红色 是为目前未实现 被动 主动 事件 维护单 客服 自动监控 / 运维发现 突发事件 监控单 投诉单 服务请求 （管工事件） 有影响 无影响 管工 BU 处理 部门？

69. 产品关联图 变更实施解决故障 事件管理 问题管理 变更管理 配置管理 服务台 变更请求 提供配置信息 配置变化通知 提供配置信息 提供配置信息 趋势分析 避免故障重复出现 监控告警 客服工单 投诉单

70. 事件系统的价值和定位 SLA 确定及签署 事件的记录及处理 SLA 的阶段核算及监控 绩效及评价考核 SLA 优化及改进措施 年度系统建设及优化规划 系统建设及优化实施 SLA 偏离整改及行动方案 系统改进及优化 系统建设项目评估评价 图：可用性管理与项目建设的推进协作

71. 解决方案及成果 解决方案 项目收益 事件记录 公司统一事件录入平台，记录跟踪事件处理直至最终解决 1. 将原来分散在工单系统、事件系统和 BU 内部的运维数据录入统一的事件管理平台中 2. 公司只建设一套系统，各部门不用投入重复开发 3. 将 ISD/IED 对事件管理的管理和规范推广到其他部门 管理支持 建立服务目录和级别管理模块 1. 在统一平台上展现管工 SLA 以及 BU 可用性统计等重要运营数据和报表，可以纵向对比运营质量 2. 支持管工、客服、 BU 针对数据分析，进行管理决策 3. 支持对运维人员的服务质量和运维质量考评 ITIL 其他系统建设 统一后续问题管理，知识库管理的建设，减少重复投入 1. 通过各相关系统提供的接口，预留变更管理、问题管理接口，并在统一平台上展现管工 SLA 以及 BU 可用性统计等重要运营数据和报表 2. 已支持与 ISD 问题管理系统接口，实现初步的问题管理升级模式

72. 阶段目标 08Q1 08Q2 08Q4 事件数据源的完善； 改进事件系统的易用性 统一考核指标、关键统计 服务台建设第一期 系统优化，组件化提高 事件系统与配置系统、网管系统 、问题系统、变更系统的数据集成， 建立公司级统一的可用性度量和评价体系 系统优化，组件化提高 事件数据源的完善， 管理精细化； 监控单、突发事件单、管工事件单、维护单 08Q3 服务台建设第二期 问题管理的建设 系统优化，组件化提高 V3.2 V3.3 V4.0 夯实基础 精耕细作 拓展 整合

73. 系统界面 http://helper.itil.com

74. 发布管理

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

76. 发布管理解决方案的层面 发布管理 发布工具及管理系统 ICT 基础架构 从发布管理、发布工具及系统、 ICT 架构三个层面去改进发布管理。 明确相关岗位角色，区分发布操作岗、发布管理审计、发布工具管理维护等角色，建立岗位职责； 建立《发布管理规范》，对发布工作进行严格管理； 开展相应的人员培训及教育； 建立 TOMS-ARS 软件系统和打包工具； 实现发布过程的自动化； 固化相关的关键控制点和权限控制； 实现同公司相关系统的集成和整合； 建立预发布机备份管理； 对测试环境及编译环境进行梳理； 规范产品、模块在编译环境、测试环境和预发布环境中的映射； 梳理配置系统，建立配置关系，推动应用系统配置的完整性和准确性； 梳理 IDC 生产环境，提高生产环境的一致性，降低复杂性；

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

78. ARS 发布推广情况 红色代表基本覆盖所有产品 蓝色代表部分产品覆盖 白色代表正在试用中 部门 对象业务 接口人 现状 ISD Qzone waynewang 1 、已经覆盖 ISD80 ％的发布工作； 2 、剩余 20 ％的 ISD 发布计划在 Q2 实现覆盖（主要是包的增量发布）； QQ 秀 QQ 会员 QQ 相册 QQ 交友 QQ 音乐 Imagecache IED 寻仙 leoxiong 、 felixwang 1 、飞行岛发布稳定。 2 、 PET 1.0 正常进行了多次正式环境发布。 3 、 CF 进行了多次正式发布。 4 、其它多个产品处于试用中。 QQ 宠物 1.0 飞行岛 QQ 宠物 2.0 CF QQ 幻想 无线 手机 QQ amyli,yen,steveqiao,wingzhou 1 、手机 QQ 发布稳定。 2 、 VOIP 进行了多次正式发布。 3 、其它多个产品处于试用中。 无线音乐 无线平台服务 VOIP 创新中心 QQ 客服 jackye 1 、频道应用发布稳定。 网站部 频道应用 国际产品中心 美国 QQGame 广告部 QQlive 运营支持部 pay.qq.com hairyxie 发布数量稳定。 电子商务部 eagle 已完成部署，试用中 在线支付部 财富通 aaronzheng 完成了新环境的部署，试用中。

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

80. ARS 版本计划 V3.2 Mar 2008 V3.2 Beta02 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

81. 公共运维平台的规划 安全管理 公共运维平台 发布管理 任务管理 TSH 监控管理 用户管理 权限管理 操作日志管理 发布自动化 发布平台化 发布审批 发布计划管理 版本管理 公共软件的发布管理 命令 / 脚本集中管理（编辑 / 查看 / 保存） 任务的权限管理 任务手工 / 定时自动调用 任务执行结果查看 进程状态监控； 版本状态查询； 自动 / 手工重启进程； 用户分权分组管理 操作进行分类管理 记录 / 查看用户在公共运维平台的所有操作

82. 公共运维平台的拓扑图 Rnet Dnet IDC ARS 服务器 编译机池 生产机 生产机 办公网 测试机池 预发布机池 ARS 备份服务器 …… … … …

83. 公共运维平台定位 IDC RNet 办公网 控制以及 审计对生 产环境的 访问 … … ……

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