随着企业业务飞速发展，越来越多的系统和应用会同时进行上线和测试，运维部门会面临大量的IT资源申请需求来保障开发测试部门的工作得以顺利进行。而且随着现有系统面临用户量剧增、过时硬件支撑能力出现瓶颈、开发架构的变更等多种因素挑战，也会出现大面积申请IT资源的情况发生。因此企业内部IT资源的申请可以说是运维人员面临的普通常见而又繁琐耗时的基础工作。

从非运维人员视角简单看，应对IT资源的申请无非是提供个机器，安装个系统、配置个参数、预装点软件，耗点时间罢了，如果企业自动化运维做的到位，可能运维人员在资源申请系统页面拖拖拽拽就搞定了。大部分时间成本都耗在了填写资源申请表格、走资源申请流程、沟通资源细节上面。但实际情况真的如普通用户想得那么简单吗？

佛曰：三生，即生存、生活和生命。凡世间万事万物需历三世磨炼、改造、升华，而至纯至臻，止于至善。企业中IT资源的申请之路也是一个不断的经历痛苦、改进、优化的发展旅程，让我们扒一扒图化资源申请之三生三世那点事儿，看看能从中得到什么启示。

图化资源申请之前世，即生存之世

在企业内部申请资源传统的方式是要填写一份符合企业标准化的资源申请表格。里面的信息大概包括使用申请资源用于哪个系统、申请几台机器或虚拟机、机器或虚拟机的配置情况（CPU多少？内存多少？磁盘空间多少？网络如何？）、机器上安装什么样的操作系统、操作系统版本如何、预装什么软件环境、申请人是谁、所属部门是什么、申请日期、联络电话等等，如果紧急还要标注环境到位的期限（一般只要申请资源都会说急用，越快越好）。如下表所示：

前世之困惑

这种枯燥乏味的表格式的资源需求在企业中比比皆是，可想而知，当运维人员看到包含密密麻麻的文字信息的表格时，内心会有多少个南美羊驼在奔跑啊。**这种传统方式的资源需求表格不仅缺乏直观识别、认知周期冗长，而且无法判断申请的资源之间内在关系如何、所属系统如何、是否存在先后顺序等等。**无疑造成了在交付资源的过程中出现反复和错误，既浪费了时间成本也影响了交付质量。

同时，**传统方式的资源申请也给企业用户带来了另一个挑战：即申请的资源需求可复用性差。**客户申请的资源往往有相同的特征，例如申请中间件集群环境，每个AppServer除了IP、主机名信息不同，其他如硬件资源、操作系统情况、中间件环境等信息都一样，但往往由于客户的内部规范需要重复填写表单，或申请时间不同而反复填写相同的表单信息。还有一种情况是申请一个通用的组件资源，如Web服务器资源，每次填写的内容可能除了项目名称或部门不同，其他信息也大部分雷同。因此这种申请资源中重复性的劳力工作也是我们常遇到的困惑。申请人员也不仅一次抱怨能否进行模版化、复用化的变革，从而提高工作效能，避免浪费大家宝贵的工作时间。

有困惑就会有思考，有思考就会有创新，部分经历资源申请前世痛苦的客户已经走在了今生不断探索、不断变革的资源申请之路。

图化资源申请之今生，即生活之世

经历了传统资源申请的种种挑战和痛苦，一部分IT标准化成熟的企业开始思考一个问题：有没有新的方式或者手段来改变这种资源申请过程中遇到的各种挑战呢？**据科学家统计，在向人类大脑传送信息的三百万条神经纤维中，视觉神经纤维占了二百万条，视觉是人类感受外界事物、获取信息的重要的感官。具有很强的模式识别能力，对可视符号的识别和感知速度，比对数字或文本快多个数量级，且大量的数据信息处理发生在潜意识阶段，所以视觉是获取信息的重要通道。而视图是人眼处理可视化符号常用的方式，人类思考的过程，就是建立思维视图的过程。**所以，如果在资源申请的过程中采用以视图为中心、以视图为数据基础的情况下，是否能够给我们带来一些变化和创新呢？令人高兴的是有企业已经在使用这种资源申请方式并取得了很大成效，归纳下来今生资源申请之路我们可以分为两步来走。

1

先将资源申请需求画出来

即用画图的方式将使用者要申请的资源以组件的颗粒度表达出来，下面是一个制造业用户的资源申请视图的局部展示。

通过上面局部视图的展示，我们通过可视化的方式可以直观的认知如下信息：

机器信息

客户要申请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中的配置信息。这个过程往往对于前台客户并不完全透明，造成了更多的前后台沟通成本，也影响了后续工作的部署进度。

**2、配置关系信息无法自动同步生成：**在一个CMDB系统比较完备的企业，配置信息的关系在资源生成之后需要客户手工梳理和输入组件之间的关系信息。因此后台运维人员需要花费时间和提交资源申请人员理解消化和反复沟通各个配置信息之间的关系情况，从而在CMDB中建立准确而符合企业规范的CI关系数据。这不仅会出现由于沟通信息衰减而导致数据错误，而且会随着系统的不断变更带来大量的反复工作，增加了运维工作的复杂度和工作强度。

企业的CMDB数据的重要性和消费性还停留在理论上，如何将数据和视图进行整合、联动、升华，实现CMDB生产工具图形化、场景化、众创化才是我们的终极目标。

图化资源申请之未来，即生命之世

古人云：前世之债，今生来偿，终其一生思考以谋未来之福祉。从生活到生命，区别在于一个是我们生于其间的现实世界，一个是我们心向往之的理想国度。对于企业内部IT资源申请的来世，可能没有我们遥望的那么久远，因为变革已经发生，即使是潘多拉的魔盒也没有将希望完全泯灭，让我们来感受一下资源申请美好的未来。

1

通过视图让资源申请进度可视化

通过视图来表示资源申请的情况还不是我们的目标。在申请者提交资源视图之后，他们的关注点已经转移到了资源申请的进度如何，客户希望对申请资源的到位情况能够实时掌握，从而有计划、有目标的开展下一步的工作。请看下图：

从上图中我们可以直观的感受到申请资源的进度情况。左边的Client组件仍然是灰显状态，说明资源还未到位；中间的WebServer资源的机器和虚拟机已经ok，因为视图中显示高亮状态，但虚拟机中的操作系统和WebServer平台软件还在部署中，因此状态为灰显；而右边的AppServer组件无论是硬件级别、操作系统级别还是平台软件级别都是高亮状态，说明申请需要的资源已经完全到位，用户可以开展下一步的测试或部署应用工作。

实现上述资源进度可视化功能是离不开企业的CMDB核心配置库的。还记得我们在画图中要对每个CI配置信息进行输入吗？这就为我们能够通过视图进行资源申请进度跟踪埋下了伏笔。在使用者申请资源画图中，会根据需求在代码段中填写相应分类组件的部分配置信息。当运维部门在交付资源的时候会参考并补充完整这部分CI配置信息，待资源交付成功后会手工或自动化的在企业核心CMDB中生成CI的配置数据。这些配置数据会定时回传给视图管理平台。当用户通过视图查看进度的时候，视图管理平台会自动根据视图中组件信息和回传的CI数据进行匹配，从而选择灰显或高亮组件来呈现资源交付进度。这种方式不仅在资源申请过程中实现了数图结合，数图互动，也扩大了企业CMDB的使用价值和自动化进程改革。

2

CI关系数据自动生成和回写

以往我们CI关系数据需要客户进行梳理和建立，但采用视图方式之后，由于在资源申请的时候申请人会完善CI关系代码信息，CI关系也只有开发、业务和申请人这类角色工作人员清楚，后台交付人员对CI关系信息不敏感。如果交付人员建立CI关系数据也需要和前端沟通和确认，十分麻烦而且也容易造成理解误区。以此我们把CI关系数据的梳理和建立放在了视图管理平台中，由申请人或有权限修改视图的业务人员进行梳理并确认。当视图中所有资源交付成功后，即灰显状态都成为高亮状态时，视图管理平台根据视图中的CI关系代码信息自动建立CI关系数据，之后将这些关系数据回写到CMDB核心库中。到此为止客户申请资源的业务流程形成了一个闭环，视图在资源申请的过程中，扮演着直观显示资源情况、描述资源CI信息、生成CI关系数据并回传，校验视图中组件资源申请进度的角色。

3

视图的资源变更扩展能力

在申请资源交付给使用者后，资源有可能发生变更和淘汰，我们还需要视图的一些扩展能力予以支撑。

• 客户由于架构改变，或机器替换的时候，CMDB中的数据发生改变，这些改变的数据会同步回视图管理平台。当客户浏览视图的同时，这些变化的数据会以视图可视化的方式提醒客户，帮助客户校验、修改和完善资源申请视图。

• 数据校验和修改后，视管理平台提供视图的版本管理功能，记录由于数据改变而带来的视图变化痕迹信息，用于日后申请者进行历史查询。

这样，通过视图的方式提供给企业一个资源申请全生命周期的可视化管理能力，帮助企业更好、更快、更敏捷的进行资源申请业务的开展。

未来的生命之路所以美好而令人期待，就是因为“未来”这个字眼就意味着无限的可能性，我们完全有理由相信通过视图手段实现业务需求这种理念，会在企业IT发展上带来更多的奇迹、更好的明天。优锘的DMV可视化平台了解客户的前世之痛、今生之憾和未来之梦，携手我们，让我们一起和未来赴约。