您的位置:新葡亰496net > 服务器网络 > 新葡亰496net:ITIL实施记实之配置管理经验谈,剖

新葡亰496net:ITIL实施记实之配置管理经验谈,剖

发布时间:2019-06-16 08:50编辑:服务器网络浏览(75)

    我在这家公司工作了三年,很少象这样需要开动所有脑力去思考一件工作,配置是一个很重要的基础,同时也是让我耗费脑力最多的一块,所以先把它写下来。

    新葡亰496net 1

    目录

    1. CMDB概述
    2. iTop系统概述
    3. iTop功能操作
      3.1. 配置管理
      3.2. 变更管理
      3.3. 事件管理
      3.4. 问题管理
      3.5. 服务管理

    本节内容

    互联网上有两大主要元素"内容和眼球","内容"是互联网公司(或称ICP)提供的网络服务,如网页、游戏、即时通信等,"眼球"则是借指海量的互联网用户。互联网公司的内容往往分布在多个或大或小的IDC中,越来越多的"眼球"在盯着ICP所提供的内容,互联网公司进行内容存储的基础设施也呈现出了爆发式的增长。为了保障对内容的访问体验,互联网公司需要在不同的运营商、不同的省份/城市批量部署业务服务器用以对外提供服务,并为业务模块间的通信建立IDC内部网络、城域网和广域网,同时通过自建CDN或CDN专业服务公司对服务盲点进行覆盖。因此随着业务的增长,运维部门也显得愈发重要。他们经过这些年的积累,逐步形成了高效的运维体系。本文将结合国内互联网公司的经验,重点针对IT基础设施的新一代自动化运维体系展开讨论。

    先介绍一下我们的业务情况,我们公司的运维项目较多,有网络、系统的、桌面的、软件的,而且这些项目用到的设备都存在共用的情况,比如一个段线路,会属于多个项目使用,一台客户的电脑,也可能装有多个管理软件,同时它又是属于桌面运维的,这些我们的IT组件一是数量多(光是需要桌面运维的电脑台数在5000台以上),二是相互的关系复杂。

    作为IT管理的核心,CMDB逐渐成为系统管理项目实施的热点。在很多的案例中,由于忽视了CMDB的因素,ITIL的深入应用受到了极大的挑战。同时,由于CMDB是IT管理信息的集中,CMDB也是一个重要的工具和手段。

    1. CMDB概述

    随着信息技术的发展, IT系统已经成为企业业务发展不可或缺的支撑基础。IT运维管理系统是以CMDB为核心,以网络、服务器、应用的监控为基础,操作行为审计为安全准则,上层整合了符合ITIL管理思想的服务台、事件管理、问题管理、变更管理等流程,从而使IT管理从日常的运营监控、统计分析、发现问题、解决问题向流程化管理转型。

    CMDB(Configuration Management Database, 配置管理数据库),提供配置管理数据库的功能,衔接监控与运维管理,是实现运维管理的核心数据支撑环境。

    CMDB包含了每一个配置项(Configuration Item, 简称:CI)全部管理细节以及配置项之间的重要关联细节的数据库。CMDB把零散在各处的不规范的资源信息,通过采集和关联的方式,集中在一个整体规划的信息库中,打破了管理模式之间的壁垒,通过识别、控制、维护、审查、展示IT资源,为技术监管、管理流程和业务服务提供准确、统一的配置数据支撑,帮助信息部门有效管控不断变化的IT环境和服务。

    CMDB提供动态的配置模型构建,数据模型基于面向对象的数据建模,实现配置项分类、属性继承、关系建模、字典维护等,用户可以根据实际管理需求进行灵活扩展,完成IT基础框架的构建。

    根据企业IT资源,我们对CMDB标准模型进行分类,如下图所示。

    新葡亰496net 2

    CMDB标准模型分类

    CMDB系统可分为:

    1. 面向基础设施的CMDB
    2. 面向业务应用的CMDB

    新葡亰496net 3

    CMDB系统分层

    浅谈ITIL

    一、运维的三个阶段

    我现在所讲的,是经过很多思考与折腾后,所整理出来的,我对配置管理的出发点,是从软件实现方面考虑的,这可能与其它的公司有一些不一样,一开始,在思考整个配置的模型,也是CMDB的业务层面逻辑,很长一段时间,在CI的结构与关系方面,我一直无法理清楚,因为当 CI的结构是怎样,关系是怎样不确定前,整个模型根本无从建立。最开始首先确定的是,我决定把CI的结构与关系分离,即结构是结构,关系是关系,两者不互为影响,作用也各自不同,这个想法应该是比较大胆的,而且这是在我对ITIL不熟悉的情况做出的决定,如果这个做法错误,后续的很多工作都会受到影响。

    在CMDB落地过程中需要注意的是,CMDB项目不是一个简单的软件安装过程,而是一个咨询、培训、实施、优化密切结合的综合过程,涉及到平台工具采购、咨询服务、实施服务、培训、甚至扩展开发等内容。同时,一个成功的CMDB项目不能一蹴而就,而是一个循序渐进、持续发展的过程,需要企业后续的投入和不断改进服务。

    2. iTop系统概述

    iTop,是IT运营门户(IT Operation Portal)的简称,它是一个开源web应用程序,适用于IT服务的日常运维管理。它基于ITIL最佳实践,适应符合ITIL最佳实践的流程,同时它又很灵活,可以适应一般的IT服务管理流程。

    iTop的核心是CMDB,即配置管理数据库(Configuration Management Data Base)。CMDB是iTop最早开发的部分。以CMDB为中心的设计理念,需要保证CMDB的准确性和及时更新,服务人员和客户均使用iTop来解决运维管理中的各类问题将会对这一点有帮助。此外,CMDB与其它工具,如监控系统、报表工具、库存管理系统等整合得越多,CMDB的信息就会越丰富。CMDB快速实施,与其它系统相比iTop有丰富的CMDB接口,支持多种方式的数据导入。

    iTop具备方便、快捷的二次开发接口,仅需要简单的数据库表操作知识及XML编写知识即可完成表单的二次开发定制。

    iTop的功能包括:

    • 记录IT配置项(如服务器、应用程序、网络设备、虚拟机、联系人、位置、VLAN等)及其各个配置项之间的关联关系;
    • 管理事件、用户请求和变更审批与执行等;
    • 归档IT服务及与外部供应商的合约,包括SLA(服务级别协议);
    • 手动或脚本方式导出所有信息;
    • 批量导入或同步/联调所有来自外部系统的数据;

    iTop角色包括:

    • 超级管理员(Administrator);
    • 变更主管(Change Supervisor);
    • 变更审批经理(Change Approver);
    • 变更执行人员(Change Implementor);
    • 文档作者(Document author);
    • 服务经理(Service Manager);
    • 桌面支持(Service Desk Agent);
    • 现场工程师(Support Agent);
    • 配置管理员(Configuration Manager);
    • 门户增强用户(Portal power user);
    • 门户用户(Portal user);
    • 问题经理(Problem Manager);

    iTop基于Apache/IIS、MySQL和PHP,它可以在任何支持这些程序的操作系统上运行,如Windows、Linux(Debian、Ubuntu和RedHat)、Solaris和MacOS X等。此外,由于iTop是基于B/S架构的应用程序,不需要在用户电脑上部署任何客户端,只需要一个简单的Web浏览器(IE 8 、Firefox 3.5 、Chrome或Safari 5 )即可使用。

    CMDB介绍

    ● 第一个阶段:人人皆运维

    决定后,剩下来就是攻破结构与关系了。在那段时间的思考中,CI的结构是首先想通的,可能是因为以前是做ERP实施的关系,也可能是因为客户是汽车制造商的关系,最终我发现将CI组装时,它的呈现很象ERP中的BOM结构,这是个父子结构,它可展开任意的节点,这种结构具有很大的扩展空间,也解决了配置管理颗粒度大小变化的问题,经过几天的思考后,我已非常确定这个思路可以解决我们的CI结构问题。

    广通软件在2004年就开始ITIL落地的尝试,并独立自主持续研发积累,形成CMDB为核心的运维解决方案,这两年为海关总署、中国航信、铁路总公司、浙商银行、黑龙江农信等政企用户,提供了专业的CMDB咨询设计及落地实施服务,在整个过程中,笔者深深的体会到,CMDB项目的成功,重中之重在于CMDB模型的顶层设计,下面针对CMDB的设计过程进行深入剖析。

    3. iTop功能操作

    Django自定义用户认证

    在早期,一个公司的IT基础设施尚未达到一定的规模(通常在几台到几十台机器的规模),不一定有专门的运维人员或部门,运维的工作分担在各类岗位中。研发人员拥有服务器权限,自己维护和管理线上代码及业务。

    剩下的关系是花的时间比较久的,查了不少资料,我一直想确定到底CI之间有哪几种关系,这本身我一直觉得这个ITIL的推广组织本身需要制定或想通的,而不应该由我来思考,我也看了常态下象IBM他们的做法,但他们关系与结构是互为一体的,而且他们对关系的定义简单了些,所以最后没有采用。在思考CI的关系时,我甚至上升到哲学的层面,去思考人与人之间的关系有哪一些,事物与事物之间的关系有哪一些,看是否能对得出CI之间的关系有一些启发作用,也在网上查了很多关于事物关系的说明,可惜没有找到有用的说明资料。

    ·了解企业政策

    3.1 配置管理

    Restful 规范

    ● 第二个阶段:纵向自动化

    最终找到一个解决方法,是一个周五下午快下班的时候,当时正在画一个示意图,想向领导表达,日后如果我们完成配置的结构与关系构建后,呈现给我们的是一个怎样的东西,当时只把CI抽象成几个集合,CI是用一个圆圈图示代替,在画了几个图示后,突然有一点灵光闪过,我发现当把几十万个CI用这样方式串联起来时,象一个个灯泡一样,有的亮有的不亮,通过关系将这数量庞大的灯泡连接起来时,这种情况好象电路图,每一个CI 位于一个复杂的线路中,形成我们公司自已的配置地图,而且这是一个三维的图形,多个项目形成一个面,每个项目的根据结构展开的所有CI形成一个面,而每个 CI之间的关系又形成一个面,脑子里当时形成了这图象(这个三维的图形后来尝试了好几次用VISIO或PPT画出来,一直没有成功),想到这一点当时很兴奋,终于看到了一道门。于在是周末休息时,去书店把数字电路的书找来看了一些篇章,最终确定引入门电路的概念来解决关系的问题。

    企业政策,是企业管理的行动指南和共同纲领,它使企业在认识上形成统一,减少了不必要的沟通成本,并使企业在流程执行上事半功倍。对于构建CMDB而言,主要有以下两类政策需要重点关注:

    3.1.1 概述

    配置管理提供了一个虚拟数据库,用来记录企业中的基础设施信息以及它们之间的关联关系,并提供科学化的流程来负责核实IT基础设施中实施的变更和配置项之间的关系记录是否正确、监控IT组件的运行状态,以确保配置管理数据库(CMDB)能够准确地反映目前IT运行环境配置项的实际状况。

    从IT管理的角度上来看,对IT资产配置项(CI)的修改不应直接进行,而必须由变更管理流程发起,因此配置管理与变更管理是紧密结合的,变更管理流程引发和控制对配置项的修改和变更;相反,配置管理向变更管理提供详细的配置信息,以帮助变更发起人分析评估变更对IT运营所带来的影响。

    iTop应用系统提供了一个完备的CMDB管理应用,使得IT运维人员可以管理其IT资产的配置项信息。它通过识别、控制、维护和验证现有的所有配置项(CIs)的版本,提供一个IT基础设施的逻辑模型。由于CMDB会记录配置项之间的关系,因此IT运维工程师们基于其关联关系对基础设施与服务之间的依赖关系进行分析。

    新葡亰496net 4

    iTop系统配置管理

    所有配置项(CI)都在iTop系统的数据模型中得到展现,并且可以根据企业本身的应用配置需求进行自定义。针对CI的所有变更可以通过变更时间、变更的属性值(旧值和新值)以及变更人员来对配置变更进行跟踪。

    资产管理功能开发

    随着业务量的增长,IT基础设施发展到了另外一个量级(通常在上百台至几千台机器的规模),开始有专门的运维人员,从事日常的安装维护工作,扮演"救火队员",收告警,有运维规范,但运维主要还是为研发提供后置服务。

    上面介绍的是思考过程,在完成这个思考过程后,在项目启动会上,汇报了此构想,得到领导认可,同时为了验证可行性,我找了一个公司典型的项目做了一次试验,看一下这样的模型是否存在问题。这里要说明一下,我们把结构与关系分离,一是考虑结构与关系是互不对等的,二是可以让其独立作用在不现的地方,这样分离之后,结构与关系本身更加严谨,我们将结构用于事件定位,关系用于故障推演,一个着眼于现在,一个着眼于未来。下面将展开细节说明。

    ·宏观政策:主要是涉及IT部门层面指导性、方向性的政策,其目标是在IT部门自上而下形成统一认识,从而有利于项目的成功。

    3.1.2 配置项管理

    iTop系统提供了配置项管理功能,方便IT运维工程师可以通过配置项类型维护相关的配置项信息。

    iTop系统维护复杂的IT资产关联关系, 配置项之间的关系存在相互的关联,如下图所示。

    新葡亰496net 5

    配置项关联

    因此,在实际的CMDB配置数据库管理过程中, 一般按照硬件基础设施到软件基础设施的配置管理过程进行配置管理的。

    注: 以下配置说明过程可能与实际的系统有所差别(如后期系统定制),配置时以实际的系统操作为准。

     

    这个阶段已经开始逐步向流程化处理进行过渡,运维部门开始输出常见问题处理的清单,有了自己业务范围适用的自动化脚本,开始利用开源软件的拼装完成大部分的工作。

    一、配置管理规划

    ·运营政策:主要涉及到流程目标、人员、输入、输出、活动以及KPI(关键绩效指标)等各要素以及流程之间相互协调、信息交互方面的指导原则,其目标是使流程能够在政策的指引下稳健、有效地执行。

    3.1.2.1 准备工作
    1. 做好基础配置信息,IT资产的配置项依赖于基础的配置信息, 基础的配置信息包括组织、联系人、品牌、型号、OS系统及版本、用户角色、机柜、机位、电源等;

      新葡亰496net 6
      组织信息配置

      新葡亰496net 7
      联系人信息配置

      新葡亰496net 8
      基础类型配置

    2. 做好基础配置数据后,就可以对配置项进行增加、修改、删除等操作。

    浅谈ITIL

    TIL即IT基础架构库(Information Technology Infrastructure Library,ITIL,信息技术基础架构库)由英国政府部门CCTA(Central Computing and Telecommunications Agency)在20世纪80年代末制订,现由英国商务部OGC(Office of Goverment Commerce)负责管理,主要适用于IT服务管理(ITSM)。ITIL为企业的IT服务管理实践提供了一个客观、严谨、可量化的标准和规范。

    1、事件管理(Incident Management)

    事故管理负责记录、归类和安排专家处理事故并监督整个处理过程直至事故得到解决和终止。事故管理的目的是在尽可能最小地影响客户和用户业务的情况下使IT系统恢复到服务级别协议所定义的服务级别。

    2、问题管理(Problem Management)

    问题管理是指通过调查和分析IT基础架构的薄弱环节、查明事故产生的潜在原因,并制定解决事故的方案和防止事故再次发生的措施,将由于问题和事故对业务产生的负面影响减少到最低的服务管理流程。与事故管理强调事故恢复的速度不同,问题管理强调的是找出事故产生的根源,从而指定恰当的解决方案或防止其再次发生的预防措施。

    3、配置管理(Configuration Management)

    配置管理是识别和确认系统的配置项,记录和报告配置项状态和变更请求,检验配置项的正确性和完整性等活动构成的过程,其目的是提供IT基础架构的逻辑模型,支持其它服务管理流程特别是变更管理和发布管理的运作。

    4、变更管理

    变更管理是指为在最短的中断时间内完成基础架构或服务的任一方面的变更而对其进行控制的服务管理流程。变更管理的目标是确保在变更实施过程中使用标准的方法和步骤,尽快地实施变更,以将由变更所导致的业务中断对业务的影响减少到最低。

    5、发布管理

    发布管理是指对经过测试后导入实际应用的新增或修改后的配置项进行分发和宣传的管理流程。发布管理以前又称为软件控制与分发

     

    事件管理的目标是在不影响业务的情况下,尽可能快速的恢复服务,从而保证最佳的效率和服务的可持续性。事件管理流程的建立包括事件分类,确定事件的优先级和建立事件的升级机制。

    问题管理是调查基础设施和所有可用信息,包括事件数据库,来确定引起事件发生的真正潜在原因,一起提供的服务中可能存在的故障。

    配置管理的目标是:定义和控制服务与基础设施的部件,并保持准确的配置信息。

    变更管理的目标是:以受控的方式,确保所有变更得到评估、批准、实施和评审。

    发布管理的目标是:在实际运行环境的发布中,交付、分发并跟踪一个或多个变更。

     

    服务台:服务台是IT部门和IT服务用户之间的单一联系点。它通过提供一个集中和专职的服务联系点促进了组织业务流程与服务管理基础机构集成。服务台的主要目标是协调客户(用户)和IT部门之间的联系,为IT服务运作提供支持,从而提高客户的满意度。

     

    具体表现为:各产品线有自己编写的脚本,利用如SVN puppet或chef来完成服务器的上线和配置管理等工作。

    由于以前实施REMEDY时,我们积累了一定的经验与知识,也具备一些配置管理的概念,所以规划方面,相对单纯一些,我们以管理科为主导,各业务领域的主管为成员,目标是所有项目的CI项纳入管理,在此作业开展前,我制作了一个作业计划,主要分几个阶段。

    ·确定配置项管理范围

    3.1.2.2 录入配置项

    1. 配置网络设备

    (1). 在配置管理功能中,通过新建配置项或配置管理概览页面选择“网络设备”,新建一台新的网络设备;

    新葡亰496net 9

    添加网络设备

    新葡亰496net 10

    添加网络设备页面

    (2). 在创建网络设备前确认网络设备配置项依赖的基础配置项是否已经创建, 如组织信息、地理位置信息(机房)、机柜及机位信息、电源信息等, 如果未创建, 需要先进行创建, 或者也可以在创建网络设备后创建,最后再对创建的网络设备进行修改;

    (3). 录入网络设备的配置项信息;

    网络设备的基础配置项应该包括以下信息:

    • 名称: 网络设备名称
    • 组织: 所属组织, 设备所属的组织,如信息技术部
    • 状态: 生产/上线/下线/空闲
    • 业务级别: 关联业务的重要程度
    • 地理位置: 网络设备所在的IDC信息
    • 机柜: 网络设备所在的机柜信息
    • 网络类型: 路由器/交换机/防火墙,可自行添加
    • 品牌: 网络设备所属品牌信息, 可自行添加
    • 型号: 网络设备型号信息,可自行添加
    • 管理IP: 网络设备的管理IP信息
    • 序列号: 网络设备的序列号
    • 资产编号: 公司对于设备的固定资产编号

    新葡亰496net 11

    录入网络设备配置项信息

    (4). 添加网络设备的关联配置项, 如果关联配置项未定义,可在关联配置项定义后再对服务器的关联配置项进行修改,关联配置项包括联系人、文档、所属的应用系统(解决方案)、相关设备等。

    新葡亰496net 12

    添加联系人

    2. 配置服务器

    (1). 在配置管理功能中,通过新建配置项或配置管理概览页面选择“服务器”,新建一台新的服务器;

    新葡亰496net 13

    新建服务器

    新葡亰496net 14

    新建服务器页面

    (2). 在创建服务器前确认服务器配置项依赖的基础配置项是否已经创建, 如组织信息、地理位置信息(机房)、机柜及机位信息、电源信息等, 如果未创建, 需要先进行创建, 或者也可���在创建服务器后创建,最后再对创建的服务器进行修改;

    (3). 录入服务器的配置项信息;

    服务器的基础配置项应该包括以下信息:

    • 名称: 服务器名称
    • 组织: 所属组织, 设备所属的组织,如信息技术部
    • 状态: 生产/上线/下线/空闲
    • 业务级别: 关联业务的重要程度
    • 地理位置: 服务器所在的IDC信息
    • 机柜: 服务器所在的机柜信息
    • 品牌: 服务器所属品牌信息, 可自行添加
    • 型号: 服务器型号信息,可自行添加
    • OS家族: 服务器所安装的操作系统类型, 可自行添加
    • OS版本: 服务器所安装操作系统的版本,可自行添加
    • 管理IP: 服务器的管理IP信息
    • MAC地址:服务器管理IP地址所属的MAC地址信息
    • KVM目录: 服务器所在的KVM目录信息
    • CPU: 服务器的CPU信息
    • 内存: 服务器的内存信息
    • 序列号: 服务器的序列号
    • 资产编号: 公司对于服务器设备的固定资产编号

    新葡亰496net 15

    创建服务器

    (4). 添加服务器的关联配置项, 如果关联配置项未定义,可在关联配置项定义后再对服务器的关联配置项进行修改,关联配置项包括联系人、文档、所连接的网络设备、所属的应用系统(解决方案)等。

    • 添加联系人

      新葡亰496net 16
      添加服务器所属的联系人信息

    • 添加软件/应用实例

      新葡亰496net 17
      添加服务器所运行的软件/应用实例

    • 添加解决方案(应用系统)

      新葡亰496net 18
      添加解决方案

    (5). 确认服务器配置项信息无误后, 点击“应用”按钮便可完成服务器的添加操作。

    新葡亰496net 19

    确认服务器添加信息

    (6). 如果需要对服务器配置信息进行修改,可以选择具体需要修改的服务器信息, 点击“修改”按钮,便可对服务器进行修改操作(如上图所示)。

    3. 配置解决方案

    (1). 在配置管理功能中,通过搜索配置项或者在配置管理概览界面中选择“解决方案”,新建一个新的解决方案配置项;

    新葡亰496net 20

    添加解决方案

    (2). 录入解决方案的基础配置信息;

    解决方案必须录入的配置项包括:

    • 解决方案名称: IT系统名称,如:集中交易系统、融资融券系统、资管系统、OTC系统等)
    • 组织: 管理运维部门,如信息技术部
    • 状态: 启用/停用
    • 业务级别: 根据系统的重要程度设置其业务级别高低
    • 投产日期: 系统的上线运行日期

    新葡亰496net 21

    录入解决方案基础信息

    (3). 添加解决方案的关联配置项, 如果关联配置项未定义,可在关联配置项定义后再对解决方案的关联配置项进行修改,关联配置项包括联系人、文档、配置项(服务器/网络设备)、供应商合同、服务等。

    关联配置项说明

    • 联系人: 与该解决方案相关的联系人,包括供应商联系人信息、运维负责人信息、业务部门负责人信息及其他关键联系人;
    • 文档: 系统所涉及到的文档信息,包括安装部署文档、运维文档、应急文档等,由于iTop系统将文档文件存放于数据库中,因此建议将文档放置在项目管理平台上,该处创建的文档类型为网页文档,只存放文档所在的URL路径;
    • 配置项: 系统所涉及到的关联配置项信息, 包括服务器、网络设备和应用中间件信息;
    • 供应商合同:系统所涉及到的所有合同信息;

    新葡亰496net 22

    配置联系人信息

    新葡亰496net 23

    配置服务器/网络设备信息

    (4). 确认解决方案配置项信息无误后, 点击“应用”按钮便可完成解决方案的添加操作。

    新葡亰496net 24

    完成解决方案添加操作

    (5). 解决方案添加完成后, 我们可以点击上图右上角的“其他操作”菜单, 在弹出菜单中选择“依赖于”,我们可以看到该方案所有的依赖配置关系, 如下图所示。

    新葡亰496net 25

    配置项依赖关系

    本文永久更新链接地址:http://www.linuxidc.com/Linux/2017-11/148408.htm

    新葡亰496net 26

    CMDB介绍

    CMDB -- Configuration Management Database 配置管理数据库,CMDB存储与管理企业IT架构中设备的各种配置信息,它与所有服务支持和服务交付流程都紧密相联,支持这些流程的运转、发挥配置信息的价值,同时依赖于相关流程保证数据的准确性。

    在实际的项目中,CMDB常常被认为是构建其他ITIL流程的基础而优先考虑,ITIL项目的成败与是否成功与建立CMDB有非常大的关系。

    70%~80%的IT相关问题与环境的变更有着直接的关系。实施变更管理的难点和重点并不是工具,而是流程。即通过一个自动化的、可重复的流程管理变更,使得变更发生的时候,有一个标准化的流程去执行,能够预测到这个变更对整个系统管理产生的影响,并对这些影响进行评估和控制。而变更管理流程自动化的实现关键是CMDB。

    CMDB工具中至少包含这几种关键的功能:整合、调和、同步、映射和可视化。

    • 整合是指能够充分利用来自其他数据源的信息,对CMDB中包含的记录源属性进行存取,将多个数据源合并至一个视图中,生成连同来自CMDB和其他数据源信息在内的报告;
    • 调和能力是指通过来自每个数据源的匹配字段进行对比,保证CMDB中的记录在多个数据源中没有重复现象,维持CMDB中每个配置项目数据源的完整性;自动调整流程使得初始实施、数据库管理员的手动运作和现场维护支持功能将至最低;
    • 同步指确保CMDB中的信息能够反映联合数据源的更新情况,在联合数据源更新频率的基础上确定CMDB更新日程,按照经过批准的变更来更新CMDB,找出未被批准的变更;
    • 应用映射与可视化,说明应用间的关系并反应应用和其他组件之间的依存关系,了解变更造成的影响并帮助诊断问题。

    ● 第三阶段:一切皆自动

    1)CI分类规划

    ·确定CI宽度和深度,建议遵循如下原则:

    CMDB资产管理部分实现

    需求:

    • 存储所有IT资产信息
    • 数据可手动添加
    • 硬件信息可自动收集
    • 硬件信息可自动变更
    • 可对其他系统灵活开发API
    • API接口安全认证

    配置项分析

    新葡亰496net 27

    每个配置项的序存储的属性信息分析

    新葡亰496net 28

    立业之本:定义表结构

    •  各种硬件都能存
    • 资产变更有记录
    • 资产ID永不变
    • 资产要有状态机

     重中之重:接口设计好

    •  可对内外灵活开发接口
    • 接口定义要标准化
    • 一定要提供排错依据
    • 数据返回要标准
    • 要能增删改查
    • 所有异常要抓住
    • 接口安全要注意

    新葡亰496net:ITIL实施记实之配置管理经验谈,剖析CMDB的设计过程。 表结构设计

    新葡亰496net 29

    CMDB资产数据自动汇报及更新流程图

     

    新葡亰496net 30

    在互联网化的大潮中,越来越多的黑马团队应运而生,都曾有过短时间内用户访问量翻N倍的经历。在流量爆发的过程中,ICP的互联网基础服务设施是否能够很好的跟进,直接决定了业务内容能否满足海量用户的并发访问。

    2)CI属性设计

    ·企业IT服务的需要(为什么要实施CMDB)

    自定义用户认证:

     

    与此同时,运维系统需要足够地完善、高效、流程化。谷歌、腾讯、百度和阿里等规模的公司内一般都有统一的运维团队,有一套或多套自动化运维系统可供参照,运维部门与开发部门会是相互平行的视角。并且也开始更加关注IT基础设施在架构层面的优化以及超大规模集群下的自动化管理和切换(如图1所示)。

    3)CI命名规划

    ·相关法案和法规对IT管理的需求

    浅谈Restful API

    理解RESTful架构 : 

    RESTful API 设计指南 :  

    新葡亰496net 31

    4)CI模版制作

    ·IT库存和资产管理的需求

    如果实现安全的WEB API接口认证?

    MadKing开源CMDB源码

     

    cmdb文章推荐: 

    新葡亰496net:ITIL实施记实之配置管理经验谈,剖析CMDB的设计过程。 

    参考:金角大王

    图1.大型互联网公司IT基础设施情况概览

    5)配置数据收集

    ·服务目录的需求

    二、BAT(百度、阿里、腾讯)运维系统的分析

    细节的作业进程就不一一介绍了,在做这个计划与真正执行时,发现一些很有意思的现象,也算是经验了,这些点我会在下面逐一介绍到,下面将我们的整体的配置模型做一个介绍,

    ·企业IT服务管理的水平(依据目前的管理水平能做到什么程度)

    国内的互联网公司百度、阿里、腾讯(以下简称:BAT)所提供的主要业务内容不同,IT架构不同,运维系统在发展过程中有不同的关注点。

    示意1

    ·有没有制定与配置项相关的管理规范和制度

    1.腾讯运维:基于ITIL的运维服务管理

    说明:

    ·有多少人可以参与管理和维护

    预计到2015年腾讯在全国将拥有60万台服务器。随着2012年自动化部署实践的成功,目前正在进行自动化验收的工作。在网络设备方面,后续将实现从需求端开始的全自动化工作:设备清单自动生成->采购清单自动下发->端口连接关系、拓扑关系自动生成->配置自动下发->自动验收。整个运维流程也已由初期的传统IT管理演进到基于ITIL的服务管理流程(如图2所示)。

    客户组织:指我们的客户的组织及用户信息

    ·有没有一套可落地的变更流程来对CI项必要的维护

    新葡亰496net 32

    运维组织:指我们内部的服务机构及员工信息

    ·企业CMDB运营管理成本(后期能够投入多大的人力成本去维护和管理)

    图2.腾讯基于ITIL的运维服务管理

    服务目录:不作名词解释了

    ·为保障CI项的准确性和表单数据的鲜活性,配置项维护的人力成本

    2.阿里运维系统:基于CMDB的基础设施管理 逻辑分层建模

    运维对象:常态上说的配置管理,即CI的集合

    ·部门间的内部沟通成本

    CMDB(Configuration Management Database) 配置管理数据库(以下简称:CMDB),将IT基础架构的所有组件存储为配置项,维护每个配置项的详细数据,维护各配置项之间的关系数据以及事件、变更历史等管理数据。通过将这些数据整合到中央存储库,CMDB可以为企业了解和管理数据类型之间的因果关系提供保障。同时,CMDB与所有服务支持和服务交付流程都紧密相联,支持这些流程的运转、发挥配置信息的价值,同时依赖于相关流程保证数据的准确性。可实现IT服务支持、IT运维以及IT资产管理内部及三者之间的流程整合与自动化。在实际的项目中,CMDB常常被认为是构建其它ITIL流程的基础而优先考虑,ITIL项目的成败与是否成功建立CMDB有非常大的关系。

    这四个纬度构成我们需要关注的所有配置信息,每一个纬度都是一个结构独立的树状目录,它可以多层级多节点的细分下去(这一点非常重要),在CMDB中我只会放入运维对象的所有信息(结构与关系),而运维对象与其它三个面的关系,也是会存放在CMDB中的,当客户组织、服务目录、运维组织都与运维对象发生关联时,这时,运维组织与客户组织(一个服务人员服务的客户是哪一些,或一个客户对应的服务人员是谁),客户组织与服务目录(一个客户享用哪一些服务,或一个服务哪一些客户),运维组织与服务目录(一个服务人员可以提供哪一些服务,某个服务哪一些服务人员可以提供),这些都可以通过虚拟连接起来,这种模型的建立,会带来日后无比便利的统计分析与查询汇总,同时也会解决我们现在许多管理上的症结。

    ·确定CI生命周期

    3.百度自动化运维:部署 监控 业务系统 关联关系

    为了后续交流的方便,我还需要对项目这个名词做一个定义,我是把它当成一个CI的集合,它是运维对象的一个节点,你也可以理解一个项目就是一个CI,这个CI是一个虚拟CI,它可以展开许多子节点,每一个节点都是CI,项目由于是我们公司很重要的一个“单位”,它与结算、人员、组织、服务目录这些都会存在关联,所以后续会经常提到它。

    ITIL规范认为,CI的生命周期是从CI的接收到最终报废退出的全过程,但在具体实施过程中,由于流程管理主体的差异化,不同项目对CI生命周期的划分和定义会有所不同,主要针对如下两个问题的确定。

    百度主要面临的运维挑战包括:突发的流量变化、复杂环境的关联影响、快速迭代的开发模式以及运维效率、运维质量、成本之间的平衡等等。百度的运维团队认为,当服务器规模达到上万台时,运维视角需要转为以服务为粒度。万台并不等于"百台*100";机器的运行状态,也不再代表业务的工作状态;运维部门为研发提供前置服务,服务与服务之间关系也随着集群的扩大逐渐复杂起来。

    整体模型

    ·何时生?(识别CI并记录到CMDB)

    新葡亰496net 33

    上面介绍的都是规划阶段的事情,这时具体的配置工作还没有真正展开,上面的整体模型相当于战略,也是一个重要的基石,它决定了后续许多的事物构造,比如后续要介绍的内容,同时这种模型如此规划时,它如何在其它的流程中作用(比如事件管理、变更等)中发挥作用,也是做了考虑的。说到这个就有一个建议了:

    ·何时灭?(对CI记录进行删除)

    图3.百度自动化运维技术框架

    在构建ITSM系统时,我的建议是首先从配置管理开始,而不是通常人们建议的从事件管理开始,配置管理决定地你们的运维管理的精细度与作业方向,它如何规划设计,会直接影响流程,你的绝大多数的数据质量也是由配置管理所决定的,在这个基石没有想清楚与确定前,展开事件及其它流程,最后整个作业可能是松散的,甚至可能是错误的,你的配置管理越精细,它对你的事件流程及变更流程,都是会产生影响的,配置管理颗粒度越细,它对我们的服务人员的作业行为要求就越高,引发的变更控制措施也就越多。在我的想象中,配置管理是一个服务平台的最底层建筑,它也是一个约束整个服务机制的重要所在。所以在项目的最初期,我一直是想先开发CMDB的,先把CDMB搞出来,然后灌数据,直接维护,不用事件管理,也不要变更管理,而是光光的 CMDB,到时我想看看所有的CI信息进去后,整个运维地图是如何的,故障的推演是否能实现,如果这些都是稳固的,再在这个基础上构建其它的应用模块。

    ·构建符合用户的CI模型分类

    百度的自动化运维技术框架,划分为部署、监控、业务系统、关联关系四大部分,整个框架更多突出了业务与IT基础设施的融合,注重"关联关系"的联动。所谓关联关系,主要是指任务与任务之间的时序依赖关系、任务与任务之间的数据依赖关系、任务与资源之间的引用依赖关系,分别对应到任务调度、数据传输、资源定位的服务流程中,形成了多条服务链。

    CMDB先开发出来还有一个好处,解决了配置数据收集维护问题,我们的配置数据届时会非常庞大,如果先收集,那在系统还未上线前,只能用电子表格维护,考虑到关系、结构的复杂,这基本上是不现实,每天有事件发生,无法做到同步的更新,不先收集,要等到系统上线的准确时间点,完成数据收集,这个难度又太大。(做过ERP的朋友,应该知道在系统上线时,仓库盘点数据导入的难度,只要业务不停,数据总是一个动态的,而我们的配置数据远比这种数据复杂),有了CMDB后,我们有足够的时间去收集试验,同时还可以同步更新。

    定义配置项属性(一个原则 一套结构)

    关联关系的运维与业务较强相关,需要有一套系统能够理清楚关系的全貌,从而在复杂的服务链上,定位运行所在的环节,并在发生故障时预估影响范围,及时定位并通知相应的部门。在这样的一套系统中,自动化监控系统非常重要。百度的技术监控框架,主要通过数据采集、服务探测、第三方进行信息收集,进行监控评估后交给数据处理和报警联动模块处理,通过API接口进行功能扩充(如图4所示)。

    ...

    ·一个原则:“精而不多”。如果我们将大量的配置项或属性纳入到CMDB中,那么将存在大量信息需要进行维护,这无疑增加了成本。反之,如果属性过少,维护工作虽然减轻了,但是CMDB的有效性就大大降低了。因此,“精而不多”就是我们的平衡点,这个‘精’主要体现在对企业有实际意义。

    新葡亰496net 34

    ·一套结构:我们通常可以把一个CI的属性分为五大来源

    图4.百度自动化技术监控框架

    模型分类设计样例:

    其实无论是BAT等互联网企业还是其他行业的企业,在IT建设中都会遵循IT基础架构库(ITIL)或ISO20000服务管理的最佳实践,采用自动化IT管理解决方案以实现重要的业务目标,如减少服务中断、降低运营成本、提高IT效率等等。随着ISO20000、ITIL v3.0的发布和推广,两者已经成为事实上的某种标准。在当今企业IT管理领域,对两个标准有着很迫切的需求。特别是ISO20000的认证要求,已经成为企业越来越普遍的需求 。ITIL v3.0包含了对IT运维从战略、设计到转换、运营、改进的服务全生命周期的管理,相关方案往往覆盖了多个领域和多个产品,规划实施和工具的选择会比较纠结。如果选择开源的工具,从CMDB开始就会遇到很多的开发工作,对于很多注重成本收益比的企业,可以参考,但由于无法保证性能与效果并不一定适用。因此,成熟的商业方案会是更好的选择。

    最新的iMC V7版本,围绕资源、用户、业务三个维度进行创新,发布了SOM服务运维管理(基于ISO20000、ITIL标准)等组件,增加了对服务器的管理,能很好的满足更多互联网化的场景需求。

    确定CI项的属性

    通常认为,一个高效、好用的配置管理数据库一般需要满足6条重要标准,即联合、灵活的信息模型定义、标准合规、支持内置策略、自动发现和严格的访问控制。企业IT基础架构的元素类型、管理数据的类型往往有较多种,如网络设备、服务器、虚拟机等,因此对于多种信息的存储需要有合适的联合的方法。虽然 iMC智能管理平台在网络设备、服务器设备等方面已经能够较好的的满足,但是随着服务器虚拟化技术的发展,虚拟机正越来越多的成为IT基础架构的一大元素。因此,针对这一需求华三通信基于CAS CVM虚拟化管理系统,对服务器CPU、内存、磁盘I/O、网络I/O等更细节的重要资源以及虚拟机资源进行全面的管理。与BAT不同,华三通信的网管软件面向全行业,目前虽然没有对域名管理等特殊资源的管理,但是能够通过API接口等方式与特有系统进行联动,进而满足定制化运维的需求,尤其是在互联网化的场景中,针对不同的业务需求,可以实现很多定制化的对接需求,例如,iMC WSM组件与国内某大互联网公司自有Portal系统进行了对接,打通了iMC工具与用户自有运维平台,很好的实现了架构融和。另外,与阿里的逻辑分层建模相似,H3C "iMC CAS"软件体系在上层也做了很多的逻辑抽象、分层,形成了诸多的模块,也即是大家看到的各种组件。

    新葡亰496net 35

    三、网络自动化运维体系

    针对模型中的每个CI的属性项进行调研,根据用户实际需求进行调整、扩充或修改,包括:属性项采用什么类型比较合理(易于展现和维护),需要用户提供哪些资料,例如:字典、默认值等信息。此过程同样遵循“精而不多”的原则。

    "哪怕是一个只有基础技术能力的陌生人,也能做专业的IT运维;哪怕是一个只有初中学历的运维人员,也能够带队完成中小型机房节点的建设,并负责数百至上千台服务器的维护管理工作"--这是一些公司对自己IT运行维护水平的一个整体评价。看似有些夸大的嫌疑,但实际上依托于强大的IT运维系统,国内已经有不少互联网公司能够达到或者接近这一标准。

    新葡亰496net,属性设计样例:

    这些企业都经历了运维发展过程中的各个阶段,运维部门曾经也是被动的、孤立的、分散的"救火队"式的团队,在后来的发展过程中,IT系统架构逐渐走向标准化、模型化,运维部门建立了完整的设备、系统资源管理数据库和知识库,包括所有硬件的配置情况、所有软件的参数配置,购买日期、维修记录,运维风险看板等等,通过网管软件,进行系统远程自动化监控。运维过程中系统会收集所有的问题、事件、变更、服务级别等信息并录入管理系统,不断完善进而形成一套趋向自动化的运作支撑机制。按照云计算的体系架构,在这样一套系统中,主要的IT资源包括计算、存储、网络资源,近些年随着网络设备厂商的推动,网络设备管理方面的自动化技术也得到十足的发展。

    总结来看,一个企业在进行互联网化的建设初期,就需要考虑到随着用户访问量的增加,资源如何进行扩展。具体可以细化为规划、建设、管理、监控、运维五个方面。

    定义CI项之间的关系

    1.规划模型化

    新葡亰496net 36

    为了确保后续业务能够平滑扩容,网管系统能够顺利跟进,互联网企业一般在早期整体系统架构设计时便充分考虑到标准化、模型化,新增业务资源就好比点快餐,随需随取。

    所有配置项都有存在的意义,而他们之间的内在关系是CMDB的重要价值体现之一,关系明确了,运维人员就能准确的找到相关实体资源,当发生故障时能够快速定位故障来源及其影响范围,从而迅速的解决各种隐患。

    标准化:一是采用标准协议和技术搭建,扩展性好,使用的产品较统一,便于管理;二是采用数据中心级设备,保证可靠性、灵活性,充分考虑业务系统对低时延的要求。

    定义配置项关系,一般可使用两种方法:

    模型化:基于业务需求设计网络架构模型,验证后形成基线,可批量复制,统一管理,也适宜通过自动化提高部署效率、网管效率。

    ·自上而下——通常要求企业先明确对外提供的服务目录,然后基于服务目录按照“业务服务→IT服务→IT系统→IT组件”的顺序进行梳理

    新葡亰496net 37

    ·自下而上——则是逆流而上,先从对内部IT组件关系开始梳理,然后逐步将IT组件映射到IT服务

    图5.常见互联网IDC架构

    CMDB配置项关系设计样例(以某个业务系统为例):

    2.建设自动化

    互联网IT基础设施具备批量复制能力之后,可以通过自动化技术,提高上线效率。在新节点建设过程中,3~5人的小型团队即可完成机房上线工作。例如某互联网公司某次针对海外紧急业务需求,一共派遣了2名工程师到现场进行设备安装部署和基本配置,而后通过互联网链路,设备从总部管理系统中自动获取配置和设备版本,下载业务系统,完成设备安装到机房上线不超过1周时间。

    新葡亰496net 38

    要达到自动化运维的目标,建设过程中需要重点考虑批量复制和自动化上线两个方面(如图6所示)。

    设计图中,完整的展现了一个业务系统所有与之相关的配置项,分析如下:

    批量复制:根据业务需要,梳理技术关注点,设计网络模型,进行充分测试和试点,输出软、硬件配置模板,进而可进行批量部署。

    ·逻辑关系——可以了解到,业务系统使用什么中间件、数据库用户、实例以及表空间,运行在哪个操作系统上,使用了什么IP地址等

    自动化上线:充分利用TR069、Autoconfig等技术,采用零配置功能批量自动化上线设备,效率能够得到成倍提升。

    ·物理关系——可以了解到,业务系统安装在哪台PC服务器上,PC服务器是通过哪台交换机的什么端口连接网络的,同时PC服务器与存储如何连接的,PC服务器存放在哪个机柜和机房,以及PC服务器是通过哪个断路器和UPS供电的等

    新葡亰496net 39

    以上信息对于运维人员来说,能够更加清晰的掌握业务系统正常运转的支撑点和来龙去脉,从而做到掌控全局。

    图6.批量配置与自动化上线

    结束语:

    ○ Autoconfig与TR069的主要有三个区别:

    CMDB的设计过程是一个复杂且与用户交互性非常强的过程,在此过程中需要充分让用户理解CMDB的概念以及相关原则,需要我们将后期维护CMDB可能带来的风险和成本跟用户做好充分的沟通,让用户去逐一去斟酌、考虑和规划,从而避免CMDB项目的失败,同时可以帮助用户优化和完善CMDB管理制度,定义人员角色,并结合变更流程来保持配置的准确性和鲜活性,真正帮助用户持续做好CMDB的维护,发挥CMDB应有的价值。

    ○ Autoconfig适用于零配置部署,后续一般需要专门的网管系统;TR069是一套完整的管理方案,不仅在初始零配置时有用,后续还可以一直对设备进行监控和配置管理、软件升级等。

    作者简介:本文作者谢亚涛,任职优云软件:秉承devops的理念,从监控、到应用体验,到自动化持续交付,全栈运维解决方案服务商。

    ○ Autoconfig使用DHCP与TFTP--简单,TR069零配置使用DHCP与HTTP--复杂,需要专门的ACS服务器。

    优云全线产品免费试用:https://www.uyun.cn

    安全性:TR069更安全,可以基于HTTPS/SSL。

    而H3C iMC BIMS实现了TR-069协议中的ACS(自动配置服务器)功能,通过TR-069协议对CPE设备进行远程管理,BIMS具有零配置的能力和优势,有灵活的组网能力,可管理DHCP设备和NAT后的私网设备。BIMS的工作流程如图7所示。

    新葡亰496net 40

    图7.H3C iMC BIMS工作流程

    3.管理智能化

    对于网管团队而言,需要向其他团队提供便利的工具以进行信息查询、告警管理等操作。早期的网管工具,往往离不开命令行操作,且对于批量处理的操作支持性并不好,如网络设备的MIB库相比新的智能化技术Netconf,好比C和C ,显得笨拙许多。因此使用的角度考虑,图形化、智能化的管理工具,往往是比较受欢迎。

    智能化:使用新技术,提升传统MIB式管理方式的处理效率,引入嵌入式自动化架构,实现智能终端APP化管理(如图8所示)。

    新葡亰496net 41

    图8.消息、事件处理智能化

    ● Netconf技术

    目前网络管理协议主要是SNMP和Netconf。SNMP采用UDP,实现简单,技术成熟,但是在安全可靠性、管理操作效率、交互操作和复杂操作实现上还不能满足管理需求。Netconf采用XML作为配置数据和协议消息内容的数据编码方式,采用基于TCP的SSHv2进行传送,以RPC方式实现操作和控制。XML可以表达复杂、具有内在逻辑、模型化的管理对象,如端口、协议、业务以及之间的关系等,提高了操作效率和对象标准化;采用SSHv2传送方式,可靠性、安全性、交互性较好。二者主要对比差异如表1所示。

    新葡亰496net 42

    表1 网管技术的对比

    ● EAA嵌入式自动化架构

    EAA自动化架构的执行包括如下三个步骤。

    ○ 定义感兴趣的事件源,事件源是系统中的软件或者硬件模块,如:特定的命令、日志、TRAP告警等。

    ○ 定义EAA监控策略,比如保存设备配置、主备切换、重启进程等。

    ○ 当监控到定义的事件源发生后,触发执行EAA监控策略。

    4.监控平台化

    利用基本监控工具如Show、Display、SNMP、Syslog等,制作平台化监控集成环境,实现全方位监控(如图所示)。

    本文由新葡亰496net发布于服务器网络,转载请注明出处:新葡亰496net:ITIL实施记实之配置管理经验谈,剖

    关键词: