请选择 进入手机版 | 继续访问电脑版

ITIL,DevOps,ITSS,ITSM,IT运维管理-艾拓先锋网

 找回密码
 

扫描二维码登录本站

QQ登录

只需一步,快速开始

查看: 567|回复: 0

[提问与解答] 配置管理流程的落地有哪些难点和需要注意的问题

[复制链接]
发表于 2020-10-16 23:02:20 | 显示全部楼层 |阅读模式
{分析} 对于配置管理和IT服务管理人员而言,判别配置管理流程落地的程度和效果,关键不是看配置管控流程是否全面,也不是看CMDB数据模型是否包罗万象、尽善尽美,其核心还是在于配置管理的价值是否得到了实现和认可,换而言之,配置管理落地的核心还是在于如何促进数据的消费,减少各管理业务重复维护数据的成本,以及在消费过程中持续改善数据的质量。数据质量的改善,我们可以参考全面质量管理理论中经典的人机料法环五个质量影响因素来进行分析和提升。

7 ~$ }, o+ f: j; i" j
{实践}  以下我们就来分析在促进数据消费和提升数据质量中常见的难点和需要注意的问题:

1 b8 b, E% P8 w! Z
  • 缺乏数据的消费场景:消费场景不明确或者场景过于单一,容易造成消费场景覆盖度、消费价值与生产成本的失衡,无法全面支撑服务和日常操作管控要求,也会导致CMDB的运行只能依靠“运动式”方式,无法形成可持续的运行模式。在配置规划阶段,我们必须很好地设计好配置信息的消费场景,并在消费场景中加入纠错行动和支持工具。CMDB的数据消费场景主要有以下几类:
    ) m% z3 E" G6 U% B/ P7 m8 A

) \" s0 Y" K1 @5 B! Z; \
  • 流程管理:如故障/问题管理 、变更管理 、服务请求管理 、灾备演练管理 、可用性管理 、容量管理等;
  • 举例而言,如事件管理,配置管理可以支持故障树分析及历史追溯:通过反向追溯该CI最近是否有出故障,是否有现成知识,是否有做过变更,可以为故障诊断提供辅助支持。
  • 监控管理:如告警、关联分析等;
  • 资产管理:如资产信息查询、资产生命周期管理、资源分配管理 、维保信息管理 、软件资产管理等;
  • 服务-资源关联分析:如架构可视化 、应用关联分析、业务影响分析、
  • 跨部门资源关联分析等;
  • 交易分析:如交易-容量分析、交易路径分析等;
  • 日常操作管理:如自动化操作管理、应用发布管理、脚本管理等2 }3 _! \. C& n( h  A% Y" g

% m- E. G4 L& ]9 [$ q# N
  • 流程管控不足:( s3 H& v* j3 |' j
5 ?/ w2 `) v: {8 d  v/ T# q
一方面,如果配置管理流程定义不够完整规范,未实现全生命周期管理,或者与其它流程协调不够,会影响配置管理的覆盖度和实施效果。例如,配置管理与变更管理和发布管理的配合不够,使得配置管理没有严格遵照变更管理流程的控制,或者由于其他流程没有很好地与CMDB集成,没法让配置信息得到充分利用。

0 N6 a( {1 b% E; h
另一方面,流程执行不严格,会导致配置信息的不完整或准确度不高,影响用户对配置数据的信任和消费热情,更难以配合做好配置信息的更新维护,也会使得配置管理难以取得预期的结果;
4 o2 \/ L% A0 b: _/ _3 B& u
  • 数据质量低,数据的完整性、标准化程度和准确性不足:' j3 U% A1 O9 U! ]( I  o# A) Z0 Y& L
! n8 m& z' E! C: a  E3 y
在CMDB建模阶段,如果缺乏明确的消费场景分析,以及消费场景与维护成本的投入产出分析,单纯地为数据而数据,生成许多无用的数据和表格,或者根据标准凑数据,忽视企业管理习惯,直接套用模型来形成CMDB。这些都会造成配置项定义和CMDB设计不合理,不符合企业的实际情况和习惯,容易造成数据不足或者产生许多无用数据,数据收集和维护成本过高,使得数据的准确性和实用性难以保证。以配置项定义为例,如果配置项的层次太多,维护配置管理数据库需要花费太多的时间和精力,如果配置项层次太少,配置项信息不够,就不利于事故、问题和已知错误的解决;
7 l  O, z+ w/ P3 B! |9 |3 \
此外,如果CMDB模型的定义没有充分考虑到组织工具和自动化技术对于配置管理的支撑能力,或者流程执行不严格,都会导致数据维护成本过高,数据维护的积极性降低,数据质量随之降低

+ C, z2 W9 k: L" V
  • 缺乏整个IT层面的统一规划、管控和部门间协调:5 }/ i8 E! m+ L
$ i: C, n7 j" S+ c5 X
配置管理是一项繁杂、琐碎的工作,往往涉及到多个IT部门,数据维护的日常投入很高,但消费价值的获得收益较大的部门与数据生产投入较大的部门往往并不是一类部门,因此容易导致各部门在CMDB的建设目标难以达成统一的共识,或者由各部门以自身需求为导向,自主建设和维护配置信息,造成信息分散、孤立和缺乏规范管理,因此建议此类项目应由整个IT部门角度来统一规划和推动,充分考虑全面的IT服务和配置管理消费场景,制订科学的数据标准(如标准化、调和等规则),构建共享型CMDB,将各部门都关心的数据及相互关系统一纳入CMDB管理,并建立配置管理流程制度。
  j0 V4 i% U5 I2 a, }6 p, s
在IT部门统一规划、建设和推动配置管理制度和CMDB时,还需要注意避免以下常见问题:

; d& X+ \: z5 ~3 b
  • 准备不充分,没有计划好适当的投入代价,这里不单单要规划启动阶段的资源开销,更重要的是运维阶段的资源开销;
  • 时间太紧张,一开始贪大求全,没有设定分步实施的Fast win策略,造成整个局面失控,让用户对CMDB失去兴趣和信心;
  • 决心不坚定,配置管理是一项繁杂、琐碎的工作,涉及多个IT部门,如果没有管理者的支持和承诺,配置管理人员可能就缺乏完成配置管理工作的积极性,而没有他们的积极参与,配置管理的效果就难于体现;
    ) T+ ~4 f- \6 b/ M4 S: o% d0 B

* U3 c: i1 `% {! b8 N
  • 缺乏工具和自动化能力支撑:2 k% R, B6 c/ ~" C, l7 j$ ?
. D4 P) n' C& k; y4 i
如果缺乏自动化的配置数据采集、分析和管理工具,如自动发现工具、CMDB、配置与变更管理工具等,会造成运营过程效率低下,数据生产和维护成本高,准确性低,不利于配置数据质量的持续提升。

. G) D' R5 o$ q; K6 u" K* w, h8 Z4 P
因此为支持配置管理的落地,建议在规划和建设阶段,就考虑自动化工具的引入,同时工具支撑不能从单个产品的角度来看问题,需要综合变更管理、资产管理、配置库、配置管理、自动化和各类专业领域数据采集工具打包来规划,形成有效支持管理需求的解决方案。
" g4 x+ {" q% E3 w8 o( P& ^
8 P( a! s" l) g# q; w2 t& y' Q
1、导致CMDB失败的因素
( h7 ]$ P+ u* p3 s
A、缺少管理层承诺----没有管理层的承诺,CMDB不可能成功。
B、在复杂流程上消耗太多的时间---我们是创建一个CMDB库,不是一个流程系统。
C、没有创建相应的工作指导文档---指导如何管理和维护CMDB。
D、没有指定配置项负责人----确保配置项有人专职维护。
E、目标过大,涵盖太多的功能----比如说IT采购和预算管理等等。
F、颗粒度不合适----配置合理的CMDB的配置项层次和粒度非常重要。
G、存在组织隔阂----CMDB是一个集成体系,靠流程中的每一个人通力协作,而不是某个人。

' l1 j; i% U9 O
* C# }' O4 D; }- t
2、导致CMDB成功的因素
4 h+ j7 }  x' ~
A、业务导向。比如说我们在CMDB的新的系统中实时加入QR码技术,为了降低资产盘点的工作量。
B、能自动发现就自动发现,降低配置管理的成本,但自动发现的信息不能用来做告警。
C、配置项的管理员必须全程参与,需求定型、测试及验收等等。
D、CMDB系统建设完成之后,其他系统必须和他联动。比如说监控、质量、容量等等,用场景驱动配置项的管理。
E、流程一定要平台化,不要让流程脱离CMDB存在,比如说搞一个OA流程,这个是很致命的。
F、CMDB要持续演进,特别是云端资源的管理。
G、配置项和流程必须要文档化,后期要进行CMDB培训。
- }% g& k+ n7 T, q1 x' M
. g$ `: ]& E5 O) k. D: h; V4 U# V




上一篇:配置流程一般应配备哪些三级操作规范文件
下一篇:配置管理员与配置经理的职责具体有哪些
您需要登录后才可以回帖 登录 |

本版积分规则

参加 ITIL 4 基础和中级专家认证、v3专家升级、DevOps专家认证、ITSS服务经理认证报名
本站关键字: ITIL| ITSM| ISO20000| ITIL培训| ITIL认证| ITIL考试| ITSS| ITSS培训| ITSS认证| IT运维管理| DevOps| DevOps培训| DevOps认证| itop| itil4| sre| 开源ITSM软件

QQ|ITIL先锋论坛 ( 粤ICP备11099876号-1 )|网站地图

Baidu

GMT+8, 2021-6-16 15:33 , Processed in 0.152077 second(s), 29 queries .

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2020, Tencent Cloud.

快速回复 返回顶部 返回列表