来自于IT应用系统的问题的问题

在软件的生命周期中，最漫长的部分则是系统的运营，在这时间里面，需要大量的人力、时间和精力来对其进行维护、修改和监控。一个优秀的IT组织应该能够实时的监控他们所研发出的或引入的每一套IT应用系统，并且在最短的时间内以最高效的方式对其进行修改和更新，而对于IT咨询服务人员来说，这也是另一种挑战。

我以IT Service Desk为入口来阐述IT应用系统的问题主要有两个原因。第一，我是一名IT Service Desk Engineer，第二则是IT Service Desk是IT应用系统大部分Incident的入口，这里集中了绝大部分来自用户对IT应用系统最直接的问题和体验回馈。

首先要了解和分析一个IT应用系统，我们可以效仿研发部分所采用的多层架构的方式，那我们可以把IT应用系统分成四层，“数据层、逻辑层、表示层、配置层”，也就是说从这四个层面来分析和研究一套系统。

 

数据层

 

数据层，指的是从数据的角度来维护和分析应用系统。系统经过测试上线以后，主体工程和大部分程序是应该能顺利运行的，如果做不到这一点那也只能说明这套系统的上线是失败的，这个IT研发团队也是不成熟的。当系统正式投入使用以后，大部分的系统错误都来则与数据层，分表表现为数据缺失、数据错误、数据重复，我想这一点不管是IT研发 还是IT咨询服务人员来说都是感受良身。尤其是我们找BUG的同仁们话了一整天的时间最后发现问题出在一个数据库中一个Table中的某个栏位缺失或是因为History里面存在Duplicate Data，这是大多数IT工作人员都有过的经历。对于User来说，他不知道系统是怎样设计的，他拥有的就只有一套EUT的材料，在日常工作当中很难保证他们能股完全按照SOP进行操作，而这一点也是无可避免的，所以Incomplete、Wrong、Duplicate Data进入系统数据库形成了数据层错误。

错误明细

栏位缺失、数据重复、同一数据在多张表中不一致、数据缺失、数据信息错误。

 

逻辑层

 

逻辑层，通俗一点就是指的业务流程。应用系统的操作是遵循严格的业务流程来设计的，所以流程的错误同样会导致应用上的失败。作为IT Service Desk的一员我是深有体会，没有做Reverse就去跑新流程；还没有检查物料就去开PO单；Customer Master Data都没有创建就去下SO；没有查库存就做PGI…..，数不胜数。应用系统是很敏感的，而且也是被精确设计的，只有标准的业务流程才能保证其正常的运营，所以在分析User的一些列操作时首先就应该搞清楚他究竟要做什么事情，而他做了哪些步骤，这些步骤是否正确。

 

错误明细

流程选择错误、流程不完整、流程错位。

 

表示层

 

表示层指的就是应用程序的UI界面了，这是程序和操作人员进行沟通的最终平台，之所以我们一直强调User Friendly也就是为了让系统的使用者能够更轻松的更准确的掌握系统的功能，了解系统的设计，熟悉系统的操作。并且来自UI的错误也是最直观的，能够让所有人都看得见。来自于着一层面的Error主要有IT Application不可用（System Migration 没做）、系统连接超时、系统组件不可用（Disabled）等等。因为这些error都非常直观，所以一般情况下都是可以很快找到问题所在。

 

配置层

 

配置层其实应该属于表示层的延伸，我之所以要专门把它分做一个层次来看，因为这个层级是非常重要也是在维护起来非常麻烦的。配置分三层含义，软件配置、硬件配置和人员配置。对软件配置来说，指的是系统参数的设定，数据库table的设计以及一些Background Job、Trigger、Procedure的编写等。这里每一个微小的参数或者栏位的设计就会影响到系统某个模块的运行，重要的是这些错误是隐性的，需要一我们一步一步的去发现，这是一个比较艰难的过程。例如SAP 的Tvar（TVARV）中的某一项参数如果少了某个厂，那这个厂针对这个业务流程就没有办法成功的完成。然而要检查出是由于Tvar参数列表数据而影响到业务的进行是比较困难的，因为我们最先Check的肯定是逻辑层和数据层。除了这些参数以外其实还有一种配置项非常重要，这就是来自UI的延伸，即Error Message的设计，我把它也归到了软件配置当中来。你是否遇到过UI上显示的Error Message与你遇到的问题根本就鸡同鸭讲完全没关系或者Error Message太敷衍没有实际意义呢，肯定有过吧，这也是IT系统经常出现的问题。这种与错误不想符合的Error Message和Incomplete Error Mesaage造成的时间和人力成本是非常大的。另外还有来自于硬件很人员安排上的失误和Incident，这两类错误出现频率比较低，属于特殊异常情况，当然也得把它们列入Check点，至于细节就不多加讨论了。

 

总的来说，IT应用系统的错误分析是可以面向这四层展开的。如果要一个比较合理的分析逻辑的话，我觉得首先还是应该从逻辑层入手看操作的目的和流程，然后从UI Error Message结合数据层来进一步分析问题的成因。如果逻辑和数据都OK的情况下，那很可能是因为程式或者配置上出现了Change，需要联系相应的系统设计人员协助分析问题的根本原因。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/23144413/viewspace-662271/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/23144413/viewspace-662271/