腾讯蓝鲸自动化运维沙龙-北京站

一、CMDB的定义和行业现状

存储IT设备和业务相关信息

CMDB是一个企业运维的数据库管理企业运维自动化智能化的底层数据 2.能为自动化的流程提供操作对象信息验证
所有服务支持和服务交付流程紧密相连支持这些流程的运转发挥配置信息的价值

在运维体系中的定位

传统CMDB解决的痛点

一致性

数据一致性不同部门大家的数据不一致
大家对同一个数据的理解不一样数据不互通

2.准确性

人工维护的话容易出差错

3.可审计

关心数据被谁动了什么时候修改的

新技术的发展对CMDB的要求

云技术的发展容器化的发展 DEVops的理念

应该具备的特性

动态扩展
- 多种多样的数据以前是主机现在是虚机容器
自动发现
- 减轻人工的工作量
关联分析
- 数据不能是孤岛之间要关联
- 关联关系需要维护
API
- 不能只做展示可以让上层进行调用
跨云管理
- 海外业务
- 云技术需要支持

二、如何构建要点是什么

要点1 信息模型的管理

难点-数据的种类越来越多内容多

- 业务逻辑
- 主机进程
- 网络架构

难点-技术演进对模型灵活扩展的要求

实体机 --> 虚拟机 --> 容器、云需要不断的扩展场景、模型、字段

解决方案 CMDB的模型设计

传统的CMDB都是硬编码
可视化界面增删模型

字段的扩展

模型要能够自定义字段

难点模型之间的关系

资产之间不是孤立的点互相需要联系

解决-关系设计

模型和模型之间的关系
梳理关联关系
- 一对一
- 一对多
关系下探

案例

要点2 面向业务的管理

行业差异大业务差异大环境多

运维场景的应用

如何建设?

1.搭建业务基本模型

3层

业务层

- 例如xxx业务对应 一批运维人员和业务人员
- 人员权限的隔离

集群层

- 运营环境的定义(测试、正式环境)

模块层

- 一个模块就是一类特定的进程 
- 模块常用于绑定进程 端口, 部署的定义

2.如何解决业务架构的差异

企业组织架构的差异业务灵活的拓展 - 3层设计的基础上 - 增加层级以满足公司的需要

3.层级属性动态扩展

业务各层级的属性要支持自定义以适配各类业务特性管理

4.业务的状态管理

从资源入库到模块应用 CMDB状态管理贯穿整个业务的韵味流程

资源池

- CMDB的入口
    - 环境部署
    - 生产、购买的主机都要先到资源池
    - 自动发现
- 新机器没有标准化, 先放资源到资源吃 然后做初始化、标准化

业务

空闲状态
- 故障自愈: 预留一些空闲的机器配置一些贴合业务的脚本随时可以被启动替换线上生产环境的服务器
故障状态
- 机器重启
- 磁盘满无法清理掉就会被标记为空闲
- 自愈

扩所容分配到集群

集群

正式、测试

模块、主机

主要是监控部署具体的功能上
举例停用模块可以标记一下运营停用的状态, 如果是没有启用的模块就不需要半夜打电话要智能一点

要点3 面向运维场景

监控的接入

- 配置监控策略
    - 监控 应该配置应用、模块 应该以什么方式去监控
- 监控能自动发现主机录入 自动应用监控上去
- 机器下架后 监控自动下架 
- 判断主机所属的层级 有对应的监控策略
    - 主机属于测试环境的话 监控告警就不用生效
- 智能的判断 
    - 如果某个人收到告警的频率太高的话 需要降低告警的频率
    - 如果业务的频率高 可以调整
    - 高优先级的告警 还是要发

集群模版

正式环境部署多套
- 定义集群下的角色模块主机属性
测试环境删除重新部署的时候
集群的模版可以用过一键部署可以复用配置
- 游戏的上线预估10个区可能需要20个区用模版就很方便了

业务配置文件管理

绑定模块和进程精确无误管理业务的配置文件

配置文件模版

可以使用一些平台上的的原生数据例如IP 模块信息进程信息
可以以变量的方式将这些数据加入模版
- 实际部署的时候可以根据主机的属性自动的分层贴合实例的配置文件
- 避免人工配置海量配置犯错误的问题

进程管理

进程端口的管理

GSEkit 可以从平台拿到端口、进程的启动方式、参数从而可以操控进程
- 基于底层管控
蓝鲸监控记录模块的进程、端口信息然后可以监控自动启动的服务如果没有启动的话就会告警

样例

要点4 活起来的CMDB

自动发现信息

减轻手工录入

装一个agent 自动安装agent 自动将数据采集然后录入CMDB
要保证录入的数据是标准化的
对接一些底层的网络协议网络路由、拓扑管理起来

实时快照

不常变动的属性之外
- cpu信息
还有一些常变的信息
- 底层的采集能力 cpu mem disk的使用率
不仅仅是死的信息也能看到活的信息
这套数据上报支持用户自定义采集

变更推送

用户和系统的变更实时推送给周边关联系统

内存容量、磁盘容量的变化怎么发现怎么提醒运维?(例如机器问题硬盘掉了 )

所有的对象、模型属性发生变化的时候位置转移、录入删除主机都会产生事件
- 提供一个API 注册一下每次发生变更可以推送信息给周边的系统
内存变化的时候对接到工单系统某台机器发生了变化
- 需要确认是人为操作还是机器故障

角色设定

例如定义网络管理员只能看网络设备的权限

网络基础设施都会管理起来

API对接

现有的CMDB 怎么切入蓝鲸的平台

企业不是白纸不可能从0开始都会既有的CMDB
根据企业的实际需要奖企业的数据同步到蓝鲸

自定义查询

组合查询条件成为一个自定义API的集合

例如找主机找一个模块的时候需要关联查询

可视化的界面可以定义业务条件、集群条件、主机条件然后查询到自己的资源

使用案例

腾讯内部的情况

基本覆盖运维的所有场景

新集群搭建流程

1.获取资源

使用主机资源池
从资源池将主机转到业务模块

2.新建大区实例

建设集群和模块

3.主机注册

将主机从空闲机划到业务模块下

4.创建DB

获取端口和域名

5.部署程序

不同的主机部署不同类型的应用

6.初始化

从CMDB读取业务的信息

7.拉起进程

获取进程的端口、启动信息

8.部署监控

模块的关联关系的拉群

9.验证

写入操作把状态转换从未上线---测试状态

10.清理脏数据

11.对外开放

整个过程和CMDB的关系密切

通过自动化每个流程都应该有状态流转

业务发布流程

模块故障替换流程

CMDB那些事儿

ansible-cmdb模块

现状多套CMDB并存监控系统一套 CMDB一套

要求 CMDB做了变更其他周边的系统要能够感知到并且应用到这些数据

信息怎么分类？后期的系统建设能够体现什么价值如何保证数据的准确性 - 线下数据线上数据怎么保持一致

避免人工干预要通过自动话的方式

可变信息和固定信息

有的数据可以用脚本拿到

怎么管理和设计？

资源交付后初始化脚本走CMDB的API将数据同步进来后期引用这些资源的时候就可以知道归属就可以进行关联所以这个地方需要多个系统进行联动自动化系统和CMDB系统的联动

CMDB的价值？

支撑运维体系的建设
数据统一起来

稳定效率成本成本可以体现出非常大的价值

服务器的成本价格
- 每个月机器费用的投入
假设服务器资源快满了需要拿数据去找老板

难点

和其他部门的沟通协调推进数据的准确性怎么保证 - 数据的盘点 - 自动化采集但是要注意方法和规范

CMDB