February 27th, 2013

设计冗余

ITSM试图构建一个可以通过配置来完成不同业务需求的IT服务管理系统。尽管ITSM在设计上号称符合ITIL,但是ITIL本身在落地上就有不少困难,不同的公司需求差异很大,很难在应用程序层面通过配置满足需求。在这种情况下,就要求供应商进行所谓的“定制化”。殊不知,“定制化”到最后的结果经常是表面看似没变,实际进行了大刀阔斧的开发工作,费时费力,还必须顾忌ITSM本身的bug,到最后ITSM反而成为了系统的包袱。究其原因,个人认为,主要还是ITSM产品的复杂度实在太高,用户其实根本不需要。

性能问题

性能是ITSM的一大诟病。AR系统本身实际上不算一个十分庞大的产品,但是在安装ITSM后,AR系统整体会变得十分慢。我们曾经完全基于AR开发过一些系统,这些系统工作的都十分良好,用户和测试人员很少抱怨性能问题。但是最近的ITSM项目却完全暴露的性能问题。就拿事件举例,我们在定制化结束后,事件单的字段数量尽然多达390个,即使这些字段什么都不存也会占用数据库文件的空间,这无疑增加了数据库的IO负担(我统计过,事件表中,sql server一个8k数据页只能存放3条事件记录!)。而这些字段通常不敢轻易的去除,很多字段都是用来进行“无谓”的工作流驱动用的,只能不断的增加新字段。提到工作流,ITSM产品中的工作流数量多的惊人,实际上其中的绝大部分都无用!!要知道执行工作流的开销是很大的。我们曾经对事件单进行数据导入动作,每秒钟竟然只能导入2-3条,这还是对导入程序经过过优化的结果,究其原因就是庞大而复杂的工作流!

设计不一致

在进行深度定制化的过程中,我们发现ITSM的各个模块在设计上存在严重的不一致性,而且冗余的设计不在少数,这对需要进行深度工作流跟踪造成的困难。开发人员对此抱怨不断。结果就是“宁可保留原有功能,只是简单的隐藏,也不去动它”。

BUG不断

当一个系统的复杂度提升的时候,随之而来的一定是BUG的增多。BMC的ITSM产品也不例外,从安装到使用,BUG无处不在,有木有?

一般产品都有相当完善的开发和测试流程,当然,相信BMC的产品也不例外。不过,我很难想象一个完全基于AR的应用如何进行基本的“单元测试”或“白盒测试”,如果只做集成测试的话,怎么保证产品的持续迭代。所以,就我个人理解,AR只适合开发一些简单的应用,大型复杂的应用还是需要考虑一下的。

售后支持乏力

我曾经跟很多支持人员打过交道,他们基本无法真正给予我们实际的帮助,总是无谓的要求我们提供各种日志,最后要求我们升级。最终,我们一般是自己研究发现问题并通过直接或间接的方式解决的。我很难想象,如果没有很扎实技术功底的实施人员如何解决问题的,无脑升级?对BMC的售后支持已经无力吐槽了,我发现不少技术支持没有什么扎实的技术基础,感觉仅仅是“熟读文档”。

升级困难

如果在定制化过程中介入产品较深的话,几乎无法对ITSM进行升级。因为,所谓的ITSM的升级就是导入表单、工作流,如果表单加过字段(基本上不可避免),如何接受其他途径的导入呢?

Web用户界面

用户界面也一直被人所诟病。在web高速发展的今天,bmc remedy那套早己过时,无论是响应速度还是操作方式早已不适用了。而且在浏览器竞争的大背景以及HTML5的风潮中,ITSM的界面在非IE浏览器下的糟糕表现已经让人受够了,冗余的js和html元素已经严重影响了用户的体验。但是话又说回来,我也是程序员,我也清楚在web上要实现所见即所得的开发方式有多难,看看微软的asp.net设计器才多少人用就知道了。抛开性能不说,BMC的mid-tier能够做到这样已经实属不易。

本文没有别的意思,仅仅吐槽一下罢了!


1块2块也是钱,小额赞助