构建cmdb的问题

运维自动化内容的层级划分

1. 服务管理 高层
   1. 运维总体支撑
   2. 流程规范
   3. 人力与成本
2. 技术决策 中层
   1. 规划技术架构和方案
   2. 运营环境管理
3. 技术执行 最底层  // <== 自动化的首要目标 
   1. 线上业务部署
   2. 线上业务日期维护

构建思路

1. 分析运维场景和痛点
   1. 深入运维一线，识别业务场景和痛点
   2. 对同类痛点抽象，形成模型
2. 规划
   1. 起步阶段着眼全局，分层设计和开发
   2. 对运维事务流程提前规划对外接口，保证数据一致性
3. 通用性
   1. 横向：方案适应多部门多平台
   2. 纵向：支持业务流程编排，单步动作解耦
4. 与流程联动
   1. 联动职能部门、人员角色、操作执行各环节

框架分层

1. 服务层：业务流程引擎
2. 功能层：各应用组件接口
3. 基础层：进程管控工具、cmdb、任务调度平台
4. 运营环境：os、各类中间件

实施要求

1. os层面
   1. 采集和输入的信息精准
   2. 统一管控入口
   3. 能远程批量管控主机
2. 应用层面
   1. 应用接口 + 流程引擎 = 自动化

实施路线

前提条件：数据标准化

1. cmdb
   1. 实施目标：信息数据统一维护，统一查询入口
   2. 功能块
      1. 基础架构信息
         1. idc节点管理
         2. 网络管理
         3. 服务器管理
         4. ip资源管理
      2. 业务信息
         1. 业务管理
         2. 公共接口管理
         3. 权限管理
         4. 审计
         5. 操作日志
   3. 使用者
      1. web用户
      2. api调用
   4. 关键点
      1. ci及其属性需要结合实际，同时兼顾长远规划
      2. 维护ci的属性值，ci间的关系和状态转换机
      3. 可扩展性，允许添加新属性
2. 任务调度平台
   1. 实施目标：批量执行运营环境的变更部署
   2. 功能点
      1. 可批量选择指定的运维执行对象
      2. 通过平台下发任务，执行并反馈结果
   3. 使用者
      1. 部署上线人员
   4. 关键点
      1. 平台与业务解耦
      2. 最大用户自由度
      3. 持续集成ci
   5. 建议
      1. 复用各种开源的部署系统，如puppet、salt、chef
      2. 使用web封装部署系统的api
      3. 对运维操作建模，分解为几类原子操作，自由组合
3.  

 

cmdb的核心是对运维元素ci的生命周期追踪和控制。

 

误区

1. 一开始就追求大而全
   1. 对模型的粒度不易过小
2. 全部自动化
   1. 20%的成本解决80%的痛点即可

 

成功要素

1. 确定建设范围
   1. 当前现况了解
   2. 建议从资产管理起步
   3. 低成本，出短期成果
2. 明确发展路线
   1. 对核心业务的支持
   2. 考虑公司未来成长的规模
   3. 使用合适的工具，容易扩容、招人、开源、易维护
3. 适当的模型设计
   1. 明确顶层ci结构
   2. 控制ci的粒度
      1. 支持当前交付的业务
      2. 2/8法则
   3. 统一配置流程标准
   4. 按自动化程度控制模型
      1. 信息采集
      2. 属性标准化
      3. 可信验证
      4. 审计
      5. 变更追溯
4. 持续优化-PDCA
   1. cmdb的分期建设目标
   2. 管控风险
   3. 逐步扩大管理范围

 

起步阶段常见问题

1. 使用cmdb的部门是谁？负责人是谁？
2. 对当前运维现况的评估
3. 明确初期建设的范围
4. 对用户培训

 

来源：oschina

链接：https://my.oschina.net/u/922576/blog/736210