标签： CMDB

CMDB具体功能有哪些

2021年5月11日
CMDB
CMDB具体功能有哪些已关闭评论

怎么能学好云计算技术？CMDB具体功能有哪些？云计算是近年来比较火爆的技术，人才需求大、薪资待遇好吸引了很多人加入。由于云计算所涵盖的技术点较多且具备一定的专业性，参加专业学习成为人们的一直选择，下面就给大家讲解一下CMDB相关知识。

%title插图%num

CMDB，即Configuration Management Database 配置管理数据库，它可以帮我们收集服务器的信息，并且自动的记录我们的变更信息，常用于整合、调和、同步、映射和可视化数据。

CMDB的具体功能如下：

1)信息整合

将IT设备、服务、甚至是运维人员整合到一个库里，将多个数据源合并至一个视图中，并生成相应的报告，从而大大提高了IT管理与服务水平。

2)自动调和

通过对每个数据源的匹配字段进行对比，保证CMDB中记录的数据没有重复和遗漏，维持CMDB中数据源的完整性，这样就让运维人员的手动操作和现场维护工作降到*低，降低了人员成本。

3)流程支持

CMDB可以为其他IT运维流程提供准确的IT设备和服务的配置信息(包括设备故障、变更、发布的信息等)，在这些变更的流程中，可以迅速查询当前设备变更所涉及到IT资源的准确信息，更快找到问题源。

4)应用映射

能够准确了解应用和其他组件之间的依存关系，判断变更影响和帮助解决可能出现的问题。

CMDB的术语来自于ITIL体系里，传统“稳态”业务建设，在ITIL的体系下，CMDB主要服务于管理流程的建设和离线的数据支撑。现在很多金融公司都在向FinTech转型，在搭建DevOps体系时，CMDB的核心价值就底层数据的提供方，通过数据的共享和协同，来帮助DevOps平台和能力之间的串联。

有了CMDB后，还需要应用配置管理，因为CMDB是面向资源的管理，是运维的基石，而应用配置是面向应用的管理，是运维的核心。一个优秀的云计算运维工程师，一定要了解CMDB，并精通应用配置管理。

为什么要有CMDB?

CMDB –Configuration Management Database 配置管理数据库.

1.为了实现资产的自动采集,资产的自动更新,

为了搭建公司自动化平台的基础则需要资产的管理.

2.优点减少了人工干预,降低人员成本.

CMDB三种工作方式

1.Agent

Agent工作流程:

1.首先在每台服务器都装上agent. agent定时执行指令

2.agent将处理过的数据通过requests发给API

3.再由API更新到数据库中.

Ageng优点:

速度快;

缺点:

每一台服务器都需要Agent

2.ssh类

%title插图%num

ssh类的工作方式:

1.资产采集器(中控机)先向API获取未采集的服务器列表

2.中控机通过paramiko模块里的ssh远程连接到服务器.(主机名,密码,命令)获取服务器的数据

3.获取完所有未采集的服务器后,将数据发送给API.

优点:无agent

缺点:速度慢

适合用在服务器少的情况下.

3.salt-stack

%title插图%num

salt-stack流程:

1.安装了saltstack-master的中控机先去API获取未采集的主机名列表.

2.通过RPC的模式来获取数据.

(RPC模式:

将主机名,密码,命令放在a消息队列里

装有salstack-slave的服务器会去a消息队列里拿命令,检查是否是自己需要执行的.

服务器执行完命令后将数据放在b消息队列里,中控机去b消息队列里获取数据

zeromq软件)

3.将获取的数据发送给API,API存数数据库.

优点:速度快,开发成本低

缺点:依赖saltstack

4.puppet

1.要用ruby写.

2.有点自动汇报数据

缺点:必须用ruby

为什么要有API

1.提供接口.系统调用数据的时候,提供接口.不让外界直接接触数据库

2.对提交的数据进行统一化的管理.

3.比较安全.如果没有API如果服务器给黑了,可能会把数据库删表.

连接API的安全认证

1.API和服务器端各有一个相同的key

2.当服务器端想连接API的时候,将key进行md5加密,发给API

APi的key也进行MD5加密,两个密文对比.,相同则代表通过.

?存在问题. 如果这个key给别人截取了,那么其他的人就可以向API发无用的数据.

3.那么就让key动态起来,我利用了本地的时间和key组合成一个字符串,用md5加密同时也要将本地的时间发给API

因为API接收到的时间会延迟. 然后APIkey和服务端的时间,md5加密然后两个密文对比.

?存在问题,发现有更多的key可以进入到API

4.将*次发送的密文放在一个列表里.第二次判断是否在该列表里,在则登录失败.

?那么需要存放的密文很多

5.失效.让服务器发的这个key10秒钟后时间,每次密文判断之前,先判断是否超时了.

清空失效的密文

def api_auth_method(request):
    auth_key = request.META.get('HTTP_AUTH_KEY')
    if not auth_key:
        return False
    sp = auth_key.split('|')
    if len(sp) != 2:
        return False
    encrypt, timestamp = sp
    timestamp = float(timestamp)
    limit_timestamp = time.time() - ASSET_AUTH_TIME
    print(limit_timestamp, timestamp)
    if limit_timestamp > timestamp:
        return False
    ha = hashlib.md5(ASSET_AUTH_KEY.encode('utf-8'))
    ha.update(bytes("%s|%f" % (ASSET_AUTH_KEY, timestamp), encoding='utf-8'))
    result = ha.hexdigest()
    print(result, encrypt)
    if encrypt != result:
        return False

    exist = False
    del_keys = []
    for k, v in enumerate(ENCRYPT_LIST):
        print(k, v)
        m = v['time']
        n = v['encrypt']
        if m < limit_timestamp:
            del_keys.append(k)
            continue
        if n == encrypt:
            exist = True
    for k in del_keys:
        del ENCRYPT_LIST[k]

    if exist:
        return False
    ENCRYPT_LIST.append({'encrypt': encrypt, 'time': timestamp})
    return True

ITSM平台和CMDB集成的主要场景

2021年4月10日
CMDB, ITSM
ITSM平台和CMDB集成的主要场景已关闭评论

本文主要谈CMDB和ITSM的集成的一些应用场景，以及非常关键的一个话企业，就是CMDB的自动化发现问题。*近在越来越多的上市企业的运维组织看到这样的需求，没有CMDB，很多工作甚至无从下手，比如如何有效的控制变更的风险。包括越来越多的专业厂家，已经将CMDB作为一个单独的产品来做。
企业随着业务的发展，应用系统越来越多，以及新信息技术的不断引入，基础架构越来越庞杂，IT资源规模是越来越大，IT架构的复杂性也与日俱增导致信息科技管理与运维服务工作面临相当大的挑战，因此很多企业引入科技服务管理平台来确保科技运营管理、服务体系落地及日常工作的风险管控，ITSM与CMDB平台的对接帮助客户解决了很多方面的问题。

在具体项目实施中往往会与企业内已有的平台做对接（如：监控系统、SSO平台、协同办公/OA、运维自动化平台、云管、安全审计系统、CMDB平台等），形成数据和流程的联动，便于数据资源更好的“消费“与”被消费“。

众所周知CMDB平台的作用是管理一切IT硬软件资源、状态及关系映射，为上层平台提供数据消费。主要的场景如下图所示：
%title插图%num

针对其中一些场景，我来举几个例子，并展开来谈一下：

1）读取CMDB平台中的数据为各大管理流程用于资源定位、故障根因分析、变更影响分析等，比如说一个应用系统、CI的变更会有哪些联动的上、下游系统受到影响，进而帮助评估变更的风险等级和需要哪些CAB参与会签；
2）读取配置数据为服务级别(SLA)提供数据因子，在流程执行过程中自动匹配对应的SLA；传统来讲，一般的SLA主要是和服务目录、优先级（优先级=影响度*紧急度）来定义，所以更多是还是依靠人工的选择和判断，进而人工决定了SLA的级别。实际上有CMDB的模型，可以更客观和智能一些。
3）读取配置数据为健康检查提供支撑；巡检可以按照业务系统的维度去上下游支撑关系的维度去巡检，而不是依靠依靠经验固化的巡检模板或固定的、粗颗粒的系统或者资源维度。
4）读取配置数据为容量管理及分析提供支撑；
5）读取配置数据与流程记录关联形成全生命周期管理；也就是可以从流程的维度去看CI，也可以从单独的一个CI或者一个业务的维度去看有哪些生命周期流程，比如事件、问题、变更、发布等等。
6）读取配置数据与供应商、合同管理及任务进行关联，便于数据的一致性及完整性；很多传统的CMDB是有资产属性和资产管理的应用场景的，那么自然就会涉及到类似于维保厂商、维保的起止日期、过保提醒之类的诉求。
7）对于不能通过自动发现且需要依靠人工或变更流程来更新的配置项需要返写到CMDB平台。
8）事件的处理，自然就不用多说了。关键时，不知道它是谁？有啥影响？有哪些上下游的关系，就很麻烦。

以上几点只是列举了部分场景，从集成的广度和深度可结合企业实际情况做具体分析,截至目前国内市场已有很多不错的对接CMDB平台厂家，并且在企业实际应用中取得了非常好的成效。

对于CMDB，除了尽可能有更多的有价值的应用场景来驱动之外，当然尽可能去做自动化发现，这些目前主流的观点。手工维护，领导有要求，下定决定一时是可以做好的，但是热情一过，95%就准确率也是等于0，因为在*终发现不知道哪些是那5%。

目前市场上主流的CMDB，比如BMC的CMDB、优维CMDB、神州信息的CMDB其实都是有自动化发现能力的，尤其是有些CMDB厂家借助于自身的自动化能力，可以把CMDB的自动化发现能力很强，脚本扩展性也很强，还可以支持有代理和无代理两种方式。
%title插图%num

%title插图%num

更高难度：云时代下的CMDB

2021年4月10日
CMDB
更高难度：云时代下的CMDB已关闭评论

前言
*近在社区多次看到CMDB的分享，大多是在探讨CMDB如何建设（How）的问题，虽然如何建设的问题非常重要，但在当今人人谈云的云化时代下，究竟该建立一个什么样（What）的CMDB更为重要。

首先要说明的是，今天在这里的分享都建立在传统企业存量环境中，暂时不考虑互联网企业。这种假设的考虑主要基于两个方面：

本人相对于传统行业更为熟悉

传统企业的运维理念和组织架构设定和互联网不同，进而导致了运维工具架构、选择、以及IT标准化策略等方面的不同

CMDB发展史
我先简要回顾一下十几年来CMDB的建设历程。

2004年
我从04年开始参与国内某银行的CMDB建设，这时CMDB的典型场景是资产信息的电子化。配置信息的采集主要采用Excel导入的方式，CMDB模型需要提前预设，不具备动态扩展能力，暂且称之为CMDB1.0。

2006年
到了06年，我在某银行主导实施了国内*个基于BMC Atrium CMDB架构的CMDB项目，这时的CMDB开始侧重于与其他ITSM (IT Service Management，IT服务管理 )流程的协同以及故障、变更影响分析等诊断场景。

但由于配置数据的初始化工作仍然需要手工Excel导入，同时配置信息的更新也不及时（无法在一个变更窗口内更新完成），导致上层场景没有发挥作用。这个阶段我们称之为CMDB2.0。

2007年
从07年开始，配置自动化发现工具的引入，帮助企业*大简化了配置数据初始化工作。

2008年
紧接着，08年左右业界提出变更闭环的概念，即在变更结束后重新进行配置自动发现并更新配置信息。相比CMDB2.0阶段，配置信息更新实时性有一定程度提高。

2012年
12年一些银行开始尝试通过配置自动发现工具实现配置比对场景，尤其是灾备与生产环境配置比对，以及集群环境内任意两节点间的配置比对。

近几年
应该说，配置自动发现工具一定程度上降低了配置数据初始化和维护的难度，但限于配置自动发现工具的技术局限，发现时间往往较长，发现的信息也存在一定盲区，同时还需使用root等管理员账号，这些约束一定程度上影响了自动发现工具的实际使用效果。这个阶段我们称之为CMDB3.0。

云化CMDB时代
随着云计算在10年国内的兴起，大约在12年后逐步在大型企业内部落地。落地过程中，我们发现云化资源的管理是一件比CMDB管理更为棘手的事情。

为此我们帮助国内一些银行实施了云化资源管理平台，除了管理以往CMDB中常见的物理配置外，进一步丰富了LPAR、端口、HBA卡、LV、VG等逻辑配置。这个阶段我暂且称之为云化CMDB1.0。

从CMDB在国内发展的历程看，随着客户对于CMDB认知不断深化，CMDB的场景已经从传统的资产台账管理逐步演化到流程协同管理、影响分析、配置比对、云化资源管理等方面，但在CMDB的技术架构上，无论是开源产品还是商业化产品都没有一个明显的改进，发展比较缓慢。这在一定程度上也影响了CMDB场景的拓展。

为了便于大家有更为直观的认识，我整理了下表罗列了不同阶段CMDB的特点

0?wx_fmt=png

需要说明的是，云化CMDB2.0是我现阶段设定的一个目标，未来也希望通过开源的方式实现的一个项目。

CMDB建设常见问题
回顾十几年的CMDB建设，大家普遍的反映是CMDB建设很困难，下面我有必要分析一下当前CMDB建设遇到的一些常见问题。

1. 缺乏合理化、整体化的规划
需求不清晰，定义了不合理的配置广度和深度。

在大而全? 还是小而深? 方面犹豫不决：
这种决策机制在项目初期往往耗费了大量时间，但随着新技术的不断涌现，这种方式已经无法适应越来越敏捷的IT环境，我们发现一种相对静态的CMDB模型已经不能满足纳管新IT组件的要求。

如何解决？
用一种更为灵活的CMDB模型扩展机制。

采用了不正确的管控策略：
按照经典ITIL的管控和项目实施机制，配置管理规划，尤其是CMDB模型的规划往往由项目组承担，一旦规划完成后整个模型也就变得很难再进行扩展，应该说这里采用的是一种集中管控的策略。

但在实际IT运维工作中，我们发现对于CMDB使用*多的是各个二线团队，不同团队之间对于CMDB 深度和广度的要求，以及管控方式都有较大差别。

如何解决？
基于集中分布式的理念建立CMDB管控体系

2. 配置管理人员职责定义不清晰
配置经理、配置管理员、配置Owner之间职责不清晰：

按照ITIL或ISO20000中对于这三类角色的定义往往过于宽泛，没有进一步考虑实际运维人员的运维场景，以及使用的运维工具，导致职责定义和实际做事方式脱节。

如何解决？
结合运维场景、运维工具、流程角色职责，对于各角色的职责进行重定义。

角色职责和岗位的对应不明晰：

在没有ITIL以前，在企业IT部门或数据中心往往找到不到一个现成岗位对于IT配置信息进行集中管理，而是每个人各管一摊。

实施ITIL后，究竟由哪个部门的哪个岗位承担配置经理这一职责往往是*让人伤脑筋的，*后往往是赶鸭子上架。这种角色定义方式*终导致体系无法运转。

如何解决？
基于集中分布式的理念设定角色和岗位的对应关系

3. 配置管理成了IT运维的负担
这其实是CMDB在企业落地所面临的*大挑战，无法充分调动运维人员的积*性，主要体现在：

初始数据收集工作量大：
存量的配置数据往往基数很大，一般配置的量级在5000以上，考虑到云化环境的海量运维场景，这个基数还会更大。

随着分布式应用架构以及微服务架构的兴起，未来一套新应用系统上线引入新的配置项数量也无法简单通过手工输入的方式来完成。

如何解决？
借助自动化手段进行数据采集

单一的自动化配置发现工具只是一种幻想：
如前所说，约从2007年开始，业内引入了自动发现工具用以解决配置数据的初始化问题，但由于这类工具往往由某个厂商提供，导致了配置发现的局限性，企业往往也要付出较大成本。

如何解决？
建立适配多类自动化工具的CMDB架构，将企业现有的脚本、监控工具、自动化工具、云平台都转化为配置数据的提供方。

投产后由于变更频繁，数据无法保证及时准确：
以往企业一般采用变更操作驱动配置修改（人工修改、或自动化发现修改）的方式以确保配置数据的准确性，这种方式往往出现了配置信息的不一致。

如何解决？
建立基于配置基线驱动的IT环境变更（操作）架构，即建立通过配置修改事件触发变更操作的事件响应模型。
对于未来软件定义环境，这种架构是一种必然选择。

如何让人人“乐于”参与：
这里的参与主要体现在二个方面：
1）需要使用与自己相关的配置数据时，CMDB可以立即提供；
2）遇到CMDB无法提供的数据时，IT部门可自行在一定标准和约束下扩展满足本部门运维CMDB模型，支撑部门级的运维场景。

如何解决？
建立小、快、灵的CMDB架构，支撑快速扩展、快速纳管、快速交付数据。

4. 配置数据的价值无法呈现
缺乏清晰的场景定义，包括流程价值、监控价值、BSM价值、云价值等：
单一流程驱动CMDB的场景，无法让CMDB中的数据流动起来，随着时间的推移CMDB中的数据就逐渐腐败—不及时也不准确。

同时，CMDB在技术上作为一个“数据库”，要让其中的数据能够流动起来，必须明确与之匹配的运维场景。

场景是用来描述与CMDB中某些配置项交互的一组活动，满足IT部门某一方面的运维管理目标，这一目标可以被度量、跟踪、改进、可视化，与此同时，CMDB的价值也随之呈现。

如何解决？
建立基于场景驱动的CMDB解决方案集合;

缺乏有效、明确的配置数据集成策略：
如前所述，CMDB是一个逻辑上的数据库，其中的数据需要和企业现有IT环境中的多类数据源进行整合，一套行之有效的数据集成策略和ETL（数据抽取、转换、转载）工具也必不可少。

如何解决？
建立数据集成策略，引入ETL。

通过以上分析，我们回顾了CMDB的历史发展过程，以及建设过程中遇到的挑战。接下来我们看看云化环境下CMDB又将面临什么新问题。

云化时代的特点以及带来的挑战
0?wx_fmt=png

应该说动态变化是云化环境下*大的挑战，无论对于配置模型还是配置数据的更新都提出了全新要求。我们势必不能再参考现有CMDB产品架构去定义或满足云化CMDB的要求。

对于互联网或互联网业务而言，海量会是一个比较大的问题，这里的关键可能不是海量存储的问题，而是如何在海量配置信息中快速配置定位、查找和可视化。

对于传统企业而言，异构永远是首要解决的问题，针对这个特点，以往厂商提出过联邦的技术，但一直没有找到可行的落地方法。这里我尝试借助类似于ETL的机制，实现多数据源的整合。

云化CMDB应具备的典型特征和范式
下面我们进入今天讨论的第三部分：云化CMDB应具备的典型特征和范式

在云化时代，CMDB需要从原有的单一工具转变为一种企业IT服务能力，即CMDB As A Service（以下为了便于叙述，使用云化CMDB代替）。

云化CMDB：是指 CMDB消费者可以通过网络随时随地获取、维护、管理CMDB。

服务要素
如IaaS中服务要素是指IT基础架构，在云化中的服务要素包括三个层面：

配置模型：用以描述CMDB的深度和广度，在技术上体现为一组配置标签（如服务器、网络、应用等，或生产环境、测试环境等）、与配置标签相关联的配置对象、以及用于描述配置对象的属性集合。

配置模型是用以描述配置项的元数据，其描述了某一配置项应该具备的属性，以及该配置项与其他配置项之间的逻辑关系，以及与配置项相关的一组操作。

配置项：用以描述某一配置对象的具体实例。如对于Server这个配置对象，其具体的IT环境中可能表现为IBM Server01，IBM Server02，IBM Server03等服务器实例。

配置项的关联操作：这个层面是对ITIL的补充。操作用来描述某个配置项在实际特定的IT环境中允许进行的一组行为集合。

举例来说，对于IBM Server01配置项来说，可能有的操作包括启动、停止；对于比较复杂的应用系统APP 01来说，可能有的操作就包括启动、停止、重启、配置等。

如果说配置项属性是对配置项的静态描述，那么配置项操作就是对配置项的动态描述，其描述了消费者可以对当前配置项施加的动作。

上述服务要素并不能单独存在，这就像数据库管理系统中的数据一样，在没有被业务系统使用前，都只是一堆0和1组成的数据，必须放到某个特定的上下文中才具备其特定的含义。

这里说的业务系统其实说的就是场景。配置场景描述CMDB与某个具体运维活动或业务活动之间的关系，在一个场景中可能同时触发一组关联操作。

在没有JDBC或ODBC标准接口前，存放在数据库管理系统中的数据只能通过特定的数据库管理平台才能进行增、删、查、改操作，这种方式严重制约了数据库中的数据对外提供服务和消费，给业务系统的开发带来了*大的不便利性。

同理，在CMDB As A Service理念中，我们也需要通过把服务要素API化，将CMDB的服务能力真正暴露出去，以便于场景进行调用。

CMDB API与服务要素一一对应，包括三个层次：

配置模型的增、删、查、改（类似于DML）；

配置数据的增、删、查、改；配置项关系建立、移除（类似于DDL）；

配置操作的增、删、查、改；并建立配置操作与特定的IT运维自动化工具的关联（包括脚本、专业自动化运维工具、云平台、监控平台等等）；

注：其实Puppet、Chef在架构上已经采取了类似的理念，这里我们希望再往上抽象一个层次

0?wx_fmt=png

通过上述要素的组合，我给出云化CMDB的定义：

云化CMDB=模型 + 操作 + 数据 + API + 场景
云化CMDB的基本架构
下面我们进入今天分享的*后一部分内容：云化CMDB的基本架构。

0?wx_fmt=jpeg

整个云化CMDB平台自下而上分为四个层次，分别是：

系统管理层：该层为系统的使用提供了*基本的支持，包括组织、人员、角色、权限的管理。支持定义各类角色和权限的管理，有完整的角色管理和权限管理功能，权限配置支持组嵌套。并通过与外部IT管理云平台集成实现用户的统一认证功能

CMDB服务要素层：按照云化CMDB的理念，服务要素包括模型、数据和操作，与之对应的分别是模型维护、配置项维护和操作维护功能。

API层：通过封装底层CMDB服务要素层的功能要素，对外提供模型管理API、配置项管理API和操作API

场景层：场景层采用了一种可扩展的方式进行设计，CMDB ETL和配置可视化是CMDB的两个基本场景：

场景一：其中CMDB ETL主要实现对于多外部配置数据源的数据抽取、转化和处理，并将处理的结果通过API层的配置项API进行数据录入，并记录配置数据的变化，建立配置基线，并围绕基线形成基线比对等功能；

场景二：配置可视化主要针对配置数据提供一种展示（图形、声音、文字等）手段，包括配置拓扑展现（以图形化方式展现配置项间的关联关系）、配置项多维度查询、配置报表以及预警功能。

除了基本场景外，开发人员可以通过API层的功能，并结合基本场景实现自定义场景，比如在本次项目中实现架构标准配置比对功能就是一种基于配置比对功能基础上的新场景应用。

除了以上层次，平台提供了CMDB管理门户的GUI界面，便于系统管理员和配置管理相关用户对于模型、配置项进行维护、查询。

目前已经参考上述架构启动开源云化CMDB项目，并实现了模型动态扩展，模型/配置数据API、配置基线、配置比对、ETL和可视化场景，预计7月份开源*个版本。

今天就分享这些内容，请大家多多指教！谢谢大家！还有一些具体细节，今天由于时间的原因就不展开了，欢迎具体探讨。

精彩互动
Q1：云平台下运维与传统运维的*大差异包括哪个方面？从而导致运维平台进入一个新的发展时期。
A：云化环境下*大的挑战是配置信息的动态变化，以往在配置手工更新往往需要几个小时甚至几天时间，等更新后其实CMDB中已经是脏数据了。

Q2：海量配置对比的实现原理和准确性程度如何？
A：基本思路是将数据库记录级比对（传统CMDB技术实现）转变为文本级比对。比对过程中可以识别新增、修改、删除属性、配置项等信息。

Q3：如果已经有一个偏资产管理流程数据的cmdb了，那么想用这个云化cmdb思路落地是不是只能重构了？
A：是。

Q4：配置主动发现这个*重要。怎么去区分逻辑属性，物理属性，动态属性，静态属性，关联配置项目，怎么与资产关联？
A：应该说配置主动发现采用的是一种轮询查找机制，我希望在新的云化CMDB中采用的思路是配置事件驱动的模式进行配置更新。

比如在IaaS中，我们要申请一台VM，在申请的过程中已经收集了VM相关信息，以及安装的数据库、中间件实例等配置信息，从这个例子中我们发现变更-配置更新是一体的，也就不需要配置自动发现工具。

当然在实际环境中，我们要两者结合。配置自动发现工具也不局限于特定的如ADDM、TADDM这类工具，可以扩展到监控、脚本等工具。

Q5：cmdb etl如何解释？我知道etl但和cmdb一起完全没有概念，请解释，谢谢！
A： CMDB从本质来说就是一个数据库，我们要解决的是如何允许多个外部数据源同时录入配置数据，那么数据源之间会出现冲突，这就需要一个合理的技术去解决。

ETL其实在数仓里应用多年，我们完全可以借鉴过来加以利用。这个方案在三个大行已经得到了应用。当时我们用的是Kettl。

Q6:怎么区分模型还是场景？
A：模型其实简单说就是数据库的表结构，场景其实就是使用数据库的应用程序。

Q7:我觉得cmdb到后面就是个aws的json格式的api接口，殊途同归，不晓得老师怎么看？
A：这个问题比较有意思，从接口的发展趋势看，类似于RestFul的API目前已经是事实标准，在云化CMDB中所有API也将通过这种方式提供。

Q8：例如不管是阿里云还是aws，所有的运维活动都是围绕资源天然集成，似乎已经失去了传统环境下配置驱动流程的意义了？
A：这个是个好问题。一个非常有意思的是无论是AWS、还是Openstack都没有集中存放配置的管理组件。

前不久，AWS发布了AWSConfig，这个组件其实就是负责AWS上所有配置信息的集中管理，并已经和20多个软件厂商实现了整合，同时我们Netflix上也看到了类似的项目。

所以，答案已经比较明显了，配置管理的这类需求还很普遍。

Q9：在云环境下，资源都是服务，运维服务和资源服务天然的联动集成，我个人感觉云环境下cmdb的功能更多是一个ci全景的可视查询，还有其他场景吗？
A：可视查询是从配置消费角度看到的一个典型场景，从配置提供的角度看，由于云化环境涉及了计算、网络、存储虚拟化，以及大量自动化运维工具，因此比较复杂的是配置数据提供场景。例如，如何在一个VM的交付过程中，实时的更新配置信息。

Q10：cmdb在建设初期怎么发挥价值？或者说，如何在运维工作中发挥更大作用，而不只是一个电子台帐？
A：

建立场景驱动理念，确保配置数据有人去使用；

通过技术手段提升配置数据的自动化率，确保CI项中的属性*大多数都能被某种自动化工具覆盖。

Q11：请问下CMDB里的数据准确性是怎么保证的？
A：非云化环境，一般通过事后审计的方式，识别有问题的配置项，然后进行手工修正。

云化环境，由于环境都是软件定义的，基础架构的变更和配置更新是同时发生的，理论上来说CMDB中的数据是云化环境的快照。今天分享的内容主要侧重在云化环境。

Q12:逻辑关联信息，可以定义吗？如何进行关联关系的维护？
A：这个问题涉及模型定义问题。如果你有Puppet和Chef的经验，我们就可以看到这种关系的定义。关系是一种特殊的CI属性，在设计时，必须确保可以通过自动化工具提供数据。
0?wx_fmt=png
0?wx_fmt=png
在实际项目中，我们会形成上面的两个表格。

Q13：如何将cmdb1.0和2.0合并在一起实现？自动发现配置方面有没有成型的解决方案？
A：上面只是处于表述的原因，将CMDB分为1.0和2.0，从实现角度看是可以同时考虑的。自动发现配置方面常见的商业方案有BMC ADDM和IBM TADDM，开源的暂时没有找到类似的解决方案，一般功能都比较散。

Q14:老师,你好.能讲讲你们Apache kylin主要拿来做什么吗？
A：可参考http://www.oschina.net/p/kylin-olap

一	二	三	四	五	六	日
						1
2	3	4	5	6	7	8
9	10	11	12	13	14	15
16	17	18	19	20	21	22
23	24	25	26	27	28	29
30	31