LZN Site

# CMDB

在运维工作进行标准化的过程中需要将标准信息固化保存到信息管理平台中，即配置管理数据库--CMDB(Configuration Management DataBase)。
CMDB起源于ITIL(Information Technology Infrastructure Library，信息技术基础架构库)。ITIL理念体系成型于80年代末，在当时和后来的企业IT建设中作为服务管理的指导理论得到广泛推广和实施。
随着互联网技术的发展，微服务技术架构的落地和实践，CMDB不再指简单的硬件资源配置管理，微服务的核心对象应用以及以应用为核心的分布式服务框架、缓存、消息、DB、接入层等基础组件也纳入CMDB范畴。

# CMDB面向资源的管理

在建设运维的基础管理平台时通常需要按步骤梳理资源，如下：

  1. 确定资源的几大维度，如服务器、网络、IDC、机柜、存储、配件等。
  2. 把这些硬件属性确定下来，如服务器会有SN序列号、IP地址、厂商、硬件配置（如CPU、内存、硬盘、网卡、PCIE、BIOS）、维保信息等;网络设备如交换机的属性有厂商、型号、带完等;
  3. 梳理资源信息之间的关系，即拓扑关系，如服务器所在机柜、虚拟机所在宿主机、机柜所在IDC等;还有核心交换机、汇聚交换机、接入交换机以及机柜和服务器之间的级联关系;
  4. 资源关系的规划，如IP地址段的规划、哪个网段用于DB、哪个网段用于大数据、哪个网段用于业务应用等，哪些机柜用于放置做虚拟化宿主机、哪些机柜只放DB机器等。
  5. 基于这些信息进行流程规范的建设，如服务器的上线、下线、维修、装机等流程，需要将流程过程中的状态变更同步管理更新到CMDB中。
  6. 拓扑关系可视化和动态展示，如交换机与服务器之间的级联关系、状态(正常or故障)的展示等。

进行资源信息梳理时应通过ER建模工具进行数据建模，如：
(/imgs/devops/server-ER.png)

# CMDB面向应用的管理

应用管理非常重要的标识：应用名。最重要的关联关系：应用名-IP（这里也可以是定义的其它唯一主 机标识，如主机名、容器ID等等，因为我们使用的方式是IP，所以这里就以IP示例）。

CMDB是IP为标识的资源管理维度，有了应用名之后就以应用为视角的管理维度。应用会涉及到的信息：

  1. 应用基础信息，如应用责任人、应用的git地址等;
  2. 应用部署涉及的软件包，如语言包(Java、C++、Go等)、Web容器(Tomcat、JBoss等)、Web服务器(Apache、Nginx等)、基础组件(各种agent、如日志、监控、系统 维护类等);
  3. 应用部署涉及的目录，如运维脚本目录、日志目录、应用包目录、临时目录等;
  4. 应用运行涉及的各项脚本和命令，如启停脚本、健康监测脚本;
  5. 应用运行时的参数配置，如Java的jvm参数，特别重要的是GC方式、新生代、老生代、永生代的堆内存大小配置等;
  6. 应用运行的端口号;
  7. 应用日志的输出规范;
  8. 其它。

# 如何在CMDB中落地应用概念

# 如何有效组织和管理应用

小米在早期互联网运维实践的分享中提出服务树概念。服务树概念是有效组织和管理应用的方式，就是把应用组织成一个树形的层次结构。

基于业务维度的拆分，对应产生了我们的应用拆分原则。比如对于电商公司，大的维度会有电商、支付、广告、流量和搜索等业务领域；进一步，电商业务领域里最典型的会有用户、会员、商品、交易、商家、店铺以及物流等；这里面还可以再进一步细分，比如商品会有详情、SKU、SPU、库存、评价、标签等。

许多互联网公司的组织架构基本上是对应着整个业务技术架构的拆分的。即业务架构决定了技术架构，而技术架构又决定了一个研发团队的组织架构，这个组织架构中不同的团队单元分别承担着对应业务的需求开发和实现职责。

参考组织架构建设的逻辑和思路，应用管理思路可总结为：产品线-业务团队-应用。

对于应用名定义，要设定规范，如：

  • 应用名必须以大小写英文字母以及下划线组合;
  • 应用名长度不超过40个字符，尽量简单易懂;
  • 不允许出现机房代号和主机名称这样的信息。

# 应用的集群服务分组建设

由于需求场景的不同，需要根据实际场景对应用进行集群服务分组建设：

  1. 多环境问题： 常见的环境会有开发联调环境、集成测试环境、预发环境、线上环境等

  2. 多IDC问题：对于大型互联网业务，会做业务单元化，或者有海外业务拓展需求的场景，会在多个IDC机房部署应用，应用代码是相同的，但是配置可能会不同。

  3. 多服务分组问题:
    这个场景跟具体业务场景相关。举个例子，比如商品中心IC这样一个核心应用，对外会有商品详情、交易下单、订单、购物车、评价、广告、秒杀活动、会场活动、商家、店铺 等一系列应用依赖它，但是这些依赖它的应用优先级是不一样的。

    • 核心应用和非核心应用：比如交易支付链路上的应用属于核心应用，任何时候都必须要优先保障，但是对于评价、商家和店铺这些应用优先级就低一些。反过来理解就是一个应用出 现故障，是不是会影响业务收入，如果影响就属于核心应用，如果不是或者影响非常小，那就属于非核心应用。所以IC这个应用下面，就会有IC的交易分组，IC的广告分 组、IC的电商分组等，这些分组就会相对固定和静态。
    • 场景因素决定：这个对于电商就会比较典型，比如大促时的秒杀场景，对于参加秒杀活动的商品，瞬时的访问量就会非常大，而不参加活动的商品就不会有这么大的访问量。所以 这时为了隔离较大的流量，就需要有多个不同的秒杀IC分组，从资源层面进行隔离；同时上层秒杀活动的应用在配置中心配置依赖时，就要配置到对应的秒杀IC集群分组上，这样 即使秒杀IC出现问题，也不会影响正常的商品IC访问。所以根据场景，不同阶段就会有IC的大促秒杀分组，这种类型的分组就需要根据实际的业务场景来决定，是个动态调整的过程， 需要开发和运维一起来讨论和验证。