UINO优锘:深度扒一扒图化资源申请之三生三世那(2)
作者:网站采编
关键词:
【摘要】?? 编辑?通过上面局部视图的展示,我们通过可视化的方式可以直观的认知如下信息: 机器信息 客户要申请2台机器,共3台虚拟机。1个虚拟机用于webserve
??
编辑?通过上面局部视图的展示,我们通过可视化的方式可以直观的认知如下信息:
机器信息
客户要申请2台机器,共3台虚拟机。1个虚拟机用于webserver,宿主在单独1台机器(企业规范一个方框表示single System),2个虚拟机用于JBoss(企业规范2个圆圈表示集群模式),共享1台硬件机器(都在红色区域内)。后台交付部门可以清晰的从宏观上知道申请者对机器数量的要求。
层次信息
上图左侧中可以看出物理机器——虚拟机——操作系统——Web Server层次信息。右侧则可以看出物理机器——虚拟机——操作系统——JBoss集群——WebService和FileVault模块这种层次信息。运维人员能够直观的了解每个申请资源都包含那些CI项,以及他们的层次关系,提前思考CI的分类、CI之间的关系,为将来在CMDB中如何建立数据打下基础。
访问信息
我们可看到webserver会通过网络https方式访问JBoss组件,这种直观连线式的表达能让客户清晰的知道组件之间的访问顺序、访问方向和访问关系信息。
CI配置信息
通过进一步单击每个组件,会看到类似CI配置的代码信息。
通过上述描述,我们可以得出一个结论:采用视图可视化的方式开展资源申请业务,不仅能够让使用者和资源提供者都在统一的视图视角范围内对交付内容有清晰和直观的认知,而且摆脱了传统数据表格模式的乏味枯燥困扰,降低了使用者对IT行业知识的认知门槛,提高了沟通的效率和客户体验。
2便捷的资源申请画图
能够将资源申请情况用画图的方式呈现出来只是基础的功能。下图是制造业客户的一个资源申请视图的全貌。
编辑?从图上可以直观感受到如此多的组件,如此复杂的关系连线以及如此丰富的图标样式。把这些视图元素完整无误的画出来是非常耗时的,而且需要画图?者?需要极大的耐心和细心的。我们可以分析出图中某些组件组合方式是经常遇到,或重复使用的,例如下图中的组件包:
编辑?这是一个简单而且常用的申请资源情况,就是提供客户1台包含SuSE操作系统的机器,可能未来用于安装业务客户端、也可能只是个前置Web服务机器。无论如何这类申请的资源模式在企业中十分常见,如果每次都从零开始画图,难免体验过于低级。随着企业规范越来越完善,可复用的资源组件可能越来越复杂,越来越多,这类需求的呼声也会不断增加。
因此,视图平台要提供一种能力将常用组件整合在一起,形成一个可复用、可管理、可维护的资源包,这种资源包的制作和维护完全由客户根据企业规范和资源申请的需求自定义、自操作、自管理。资源包可以看成是视图的重要组成部分,除了可视化的内容显示,还包括了CI配置信息代码、CI关系数据代码等基本元素。从而降低资源申请者画图的时间,提高画图的效率。
今生之挑战
从生存到生活,其实是解决了企业资源申请基本的“活着”的问题,也可以理解成相对“活的好些”的要求,其实离“活的潇洒”还是有一定距离的,因为我们还面临着如下的挑战:
1、资源申请进度的不透明化:往往客户提交了资源申请表格之后就只有等待,等待资源申请表格的流程走完、等待运维人员交付环境、等待后台人员根据建立好的资源生成CMDB中的配置信息。这个过程往往对于前台客户并不完全透明,造成了更多的前后台沟通成本,也影响了后续工作的部署进度。