运维-运营体系标准化之配置管理CMDB

本文是极客时间《赵成的运维体系管理课》的读后体会之一。

运维配置管理实践中一些混乱现象

在公司的运维配置管理实践中，存在一些混乱的现象：

  • 信息安全收到fastjson的安全问题报告，但报告中的服务器对应的系统却有错位
  • 信息安全收到了报告，发现tomcat的某个版本出现了漏洞需要升级，但不知道到底影响到哪些系统，只能逐个请每个系统的负责人判断
  • 部分服务器（特别是开发坏境服务器）已经基本可以确认不再被使用，但服务器资源没有回收，每月持续占用硬件预算
  • 某系统上线后发现中漏配置了一个域名，导致部分用户打开首页报错
  • redis缺少规划，多个系统公用一个redis集群的情况下，无法根据键（key）来区分每个系统占用了多少缓存。遇到内存不足的情况很难深入排查是哪个系统导致
  • 生产消息队列中不少queue堆积着大量消息，但不知道是否还在用，不敢随意删除

这些情况很可能短期甚至长期内不会直接导致什么问题。可能就是让信息安全整理材料多费一点时间，开发排查多绕一点弯路，或多花一些硬件维持或扩容费用。但有些时候这些问题就是给未来出现的生产问题埋下隐患。
硬件的归属，服务器的使用情况，应用域名管理，软件版本，应用与中间件的关联等等，都属于广义上的配置管理。所以归根到底，是配置管理的混乱。

ITIL和配置管理CMDB

在ITIL（Information Technology Infrastrueture Library）中，有10个重要的IT管理关键模块。其中配置管理（CMDB）通常被认为是其他IT流程的基础。
CMDB（Configuration Managoment DataBase），配置管理数据库，是与IT系统所有组件相关的信息库。它包含IT基础架构配置项的详细信息。
在传统运维时代，CMDB的核心对象是资源，即网络和硬件设备。但在云计算和互联网运维时代，CMB的核心已经转变为了“应用”。随着微服务架构的推广，以应用为核心的注册中心、缓存、消息队列、数据库等都需要纳入配置管理的管理范畴。

以应用为核心的配置管理标准化可以包括：

  • 元数据属性:系统名、 BA Owner/开发Owner/运维Owner
  • 环境属性:拥有几套环境
  • 逻辑实体属性:架构评审和变更设计
  • 硬件和网络属性:服务器配置、SLB、域名、ip等
  • 代码属性:编程语言、代码库地址、需求空间地址
  • 应用日录属性:日志日录、应用目录、临时目录等
  • 应用配置属性:端口号、jvm参数等
  • 中间件属性:web容器、注册中心、缓存、消息队列、数据库等

最终目标是能达成传统CMDB和应用视角CMDB的统一。
CMDB统一

也有开源的CMDB，比如腾讯的蓝鲸智云。
可以参考它的架构

腾讯蓝鲸架构

CMDB的维护和流转

CMDB并不能只靠运维团队内部封闭来做，而要站在怎么能够打造和发挥出整个技术架构体系运维能力的视角。有部分信息也需要开发来提供，例如消息队列的queue名等。所以CMDB需要跨团队协作。一方面运维团队要主动出击，去沟通，去推进；另一方面，必须能得到上级主管甚至是更高层技术领导的支持。
配置数据也需要保持持续维护。过时的配置数据等于没有，甚至更差。这个首先需要在所有运维人员的重要性认识上保持统一。此外，也对每个应用的负责运维和研发人员提出相应的问责机制。
和货币类似，只是维护信息不会产生价值。只有把信息流转到开发，测试和信息安全等角色，对整体的研发效能和故障率做出贡献，才能使配置管理免于成为运维的纯负担。

本文永久链接 [ https://galaxyyao.github.io/2020/07/29/运维-运营体系标准化之配置管理CMDB/ ]