服务器生命周期管理，运维有话说！

现状

先来介绍下我们的服务器在CMDB的“身份证”信息：由于运维团队的岗位进一步划分为基础运维和应用运维，针对服务器上架场景基础运维和应用运维在CMDB中的分工如下：

1. 基础运维：

• 新服务器上架；
• CMDB维录入新服务器的资产信息，如带外管理IP、品牌、型号、维保等信息；

1. 应用运维：

• 新服务器安装操作系统，分配业务IP、关联带外管理IP；
• CMDB将服务器转移到相关业务、应用下；
• 在监控平台、堡垒机中添加相关主机信息；

生命周期管理

针对服务器的生命周期，我们将服务器的生命周期分为以下几个阶段，与CMDB中”服务器状态“字段一致：

• 入库
• 待分配
• 在线
• 关机
• 下线
• 出库

我们对每个阶段的操作流程进行了定义，并做了一个大致的梳理形成服务器生命周期，大家可以参考下：

分析

以上是一套比较完善的CMDB操作流程，但是大家忽略了权限分离，即基础运维和应用运维是有业务区分的，而CMDB是有权限分离的，可以做到细粒度管理：

• 系统权限，面向基础运维，可对基础设施管理，如：网络设备、物理机的型号、维保、SN、服务状态等资产信息；
• 业务权限，面向应用运维，可对所属业务下的服务器，分配至相应的应用模块；

通过权限隔离，团队明确了CMDB中服务器的操作界限，但问题还是出乎意料的发生了。

问题

CMDB使用过程中我们忽略了以下几个问题：

• CMDB的主机管理是以业务IP为主键的，这就意味着基础运维在新服务器上架录入CMDB时必须确定服务器的业务IP，否则无法录入；
• 业务IP的分配是滞后的，应用运维安装操作时才需要确定；

此时我们的上架流程就出现了问题，原因为「业务IP和管理IP同时存在于主机模型中。」

解决方案

我们需要将「业务IP和管理IP」分别隶属于不同模型，由于业务IP肯定属于主机模型了，因此我们新增并扩充了以下三个模型，并且专门由基础运维管理：

• 机房，主要是机房位置
• 机柜，主要是机位信息
• 物理机，主要是管理IP、品牌、型号、维保等信息

其中我们将硬件服务器的主要字段都放到物理机这个模型中，而主机模型虽然包含了物理机和虚拟机，但是只有业务IP，而不包含管理IP及其他字段信息。此时大家可能会有一个问题：物理机的业务IP如何与管理IP进行关联，以应对物理机故障的风险？因此我们需要对CMDB进一步深入探索：「关联管理」。通过关联管理，我们可以做到：

• 将物理机与机柜、机房进行关联，由基础运维操作；
• 将主机（主要是带有业务IP的物理机）关联到物理机模型，而虚拟机无需关联，由应用运维操作；

通过关联关系，我们可以清晰看到物理机的业务IP、管理IP及机柜、机房信息。通过新增物理机、机柜、机房模型以及关联关系，在权限隔离的基础上，我们实现了：

• 基础运维与业务运维的操作分离
• 基础运维管理物理机、机房、机柜之间的关系
• 应用运维管理虚拟机、物理机与业务之间的关系

权限隔离、操作分离正好解决了我们服务器上架的痛点。

总结

基础设施的管理虽然看似简单，但还是有很多意想不到的问题会挡住我们前进的道路，正所谓「技术都是现成的，剩下都是管理问题」，同时也利用这个机会来检验团队直面困难的魄力。