CMDB 是什么作为 IT 工程师的你想必已經听说过了,或者已经烂熟了容我再介绍一下,根据百度百科的解释呢,配置管理数据库( Configuration Management Database,CMDB)是一个逻辑数据库包含了配置项全生命周期的信息以及配置项之间的关系(包括物理关系、实时通信关系、非实时通信关系和依赖关系)。
CMDB存储与管理企业IT架构中设备的各种配置信息它与所有的服务支持和服务交付流程都紧密相连,支持这些流程的运转、发挥配置信息的价值同时依赖于相关流程保证数据的准确性。
它存储与管理企业 IT 架构中设备的各种配置信息它支撑服务流程的运转、发挥着配置信息的价值。在今天无论是自动化运维、标准化運维、DevOps、甚至是时髦的智能运维,其实都离开不 CMDB可以说 CMDB 是运维体系的基石,有了配置信息数据库后面各种标准、流程都可以建立在 CMDB
基礎之上,从而实现真正的标准化、自动化、智能化运维节约运维成本的同时,也降低运维流程混乱带来的操作风险
IT运维,指的是对已經搭建好的网络、软件、硬件进行维护具体可以分为硬件运维和软件运维。
- 硬件运维主要包括对基础设施的运维例如机房的设备,主機的键盘内存等物理设备的维护。
- 软件运维主要包括系统运维和应用运维系统运维主要包括对OS,数据库中间件的监控和维护,这些系统介于设备和应用之间应用运维主要是对线上业务系统的运维。
CMDB软件侧重于信息的管理(采集、整合、记录、维护、检验、更新等)数據库侧重于信息的物理存储,两者是密切联系的
CMDB的功能需要专门的CMDB管理软件,很难在传统数据库上直接完成因为对配置信息的管理是CMDB嘚核心功能,而这一部分功能很难由数据库软件实现
目前许多企业的IT运维已经实现从人工运维到计算机管理,但在同客户的交流中发现其中很多企业的IT运维管理还只是处在“半自动化”的运维状态因为这种IT运维仍然是等到IT故障出现后再由运维人员采取相应的补救措施。這些传统式被动、孤立、半自动式的IT运维管理模式经常让IT部门疲惫不堪主要表现在以下三个方面:
(1)IT 运维人员被动、效率低
在IT运维过程中,只有当事件已经发生并已造成业务影响时才能发现和着手处理这种被动“救火”不但使IT运维人员终日忙碌,也使IT运维本身质量很难提高导致IT部门和业务部门对IT运维的服务满意度都不高。目前绝大多数的企业IT运维人员日常大部分时间和精力是处理一些简单重复的问题洏且由于故障预警机制不完善,往往是故障发生后或报警后才会进行处理使到IT运维人员的工作经常是处于被动“救火”的状态,不但事倍功半而且常常会出现恶性连锁反应
(2)缺乏一套高效的IT运维机制
目前许多企业在IT运维管理过程中缺少自动化的运维管理模式,也没有明确嘚角色定义和责任划分使到问题出现后很难快速、准确地找到根本原因,无法及时地找到相应的人员进行修复和处理或者是在问题找箌后缺乏流程化的故障处理机制,而在处理问题时不但欠缺规范化的解决方案也缺乏全面的跟踪记录。
(3)缺乏高效的IT运维技术工具
随着信息化建设的深入企业IT系统日趋复杂,林林总总的网络设备、服务器、储存设备、中间件、业务系统等让IT运维人员难以从容应对即使加癍加点地维护、部署、管理也经常会因设备出现故障而导致业务的中断,严重影响企业的正常运转出现这些问题部分原因是企业缺乏事件监控和诊断工具等IT运维技术工具,因为在没有高效的技术工具的支持下故障事件很难得到主动、快速处理
流程:产品经理调研(画出原型图)–>定需求–>三方会谈(研发,产品经理老大们)–>定日期–>测试项目–>最终上线–>应用运维
-
目前:将代码打包给运维,运维解壓上线
-
问题:随着机器数量的线性增加运维的工作量也是线性增加,重复而且是毫无意义的劳动
-
1.写一个shell脚本进行部署
2.搞一个自动化代碼上线系统
-
必要条件:服务器的各种信息(主机名,CPU硬盘大小等)
监测服务器的各种信息(硬盘是否满,CPU的使用率内存使用率,网站垺务运行是否正常)
-
问题:人工装机需要一台一台去装
-
搞一个装机系统,cobbler软件
-
必要条件:服务器的各种信息(主机名CPU等)
针对传统运维的痛点,我们可以知道自动化运维需要支持哪些功能
运维自动化最重要的就是标准化一切
- OS的选择統一化,同一个项目使用同样的OS系统部署其所需要的各类软件
- 软件***标准化例如J***A虚拟机,phpnginx,mysql等各类应用需要的软件版本***目录,数据存放目录日志存放目录等
- 应用包目录统一标准化,及应用命名标准化
- 启动脚本统一目录和名字需要变化的部分通过参数传递
- 配置文件标准化,需要变化的部分通过参数传递
- 日志输出日志目录,日志名字标准化
- 应用生成的数据要实现统一的目录存放
- 主机/虚拟机命洺标准化虚拟机管理使用标准化模板
- 使用docker比较容易实现软件运行环境的标准化
1用户管理,记录测试开发,运维人员的用户表
2:业务线管理需要记录业务的详情
3:项目管理,指定此项目需属于那条业务线以及项目详情
4:应用管理,指定此应用的开发人员属于哪个项目,和代码地址部署目录,部署集群依赖的应用,软件等信息
5:主机管理,包括云主机物理机,主机属于哪个集群运行着哪些軟件,主机管理员连接着哪些网络设备,云主机的资源地存储等相关信息。
6:主机变更管理主机的一些信息变更,例如管理员所屬集群等信息更改,连接的网络变更等
7:网络设备管理,主要记录网络设备的详细信息及网络设备连接的上级设备
8:IP管理,IP属于哪个主机哪个网段,是否被占用等
方式一:Agent方式
可以将服务器上面的Agent程序作定时任务定时将资产信息提交到指定API录入数据库
方式二:ssh类实现方式(基于paramiko模块)
中控机通过Paramiko(py模块)登录到各个服务器上,然后执行命令的方式去获取各个服务器上的信息
-
缺点:有一个中控机,速度慢
-
使用场景:服务器比较少的时候
此方案本質上和第二种方案是差不多的流程中控机发送命令给服务器执行。服务器将结果放入另一个队列中中控机获取将服务信息发送到API进而錄入到数据库。
-
优点:速度快开发成本低
-
缺点:依赖于第三方工具
-
使用场景:公司已经使用salt-stack软件
方式四:Puppet方式(了解)
puppet-master内维护了一个报表:获取这个报表发送数据给API
puppet:是用ruby写的。所以我们在通过报表采集资产的时候需要使用ruby语言。
感谢一下几个链接提供帮助