某企业信息系统在线故障报修平台的设计与实现

张敬苒

(长春中医药大学附属医院 信息中心，长春 130021)

1 系统设计目标

随着企业信息化的不断深入，企业内部的信息系统越来越多，规模越来越复杂，信息系统的故障维修工作难度也越来越大，主要体现在:第一，故障发生的时间不确定，当故障集中发生时，维修人员的电话就成了热线电话，应接不暇，不仅难以顺利执行维修工作，也影响了故障处理的及时性;第二，故障类型不确定，并不是所有故障都是系统运行故障，有些只是用户操作问题或者用户所使用的计算机的故障，但这些非运行故障往往会耗费运维人员大量时间，甚至可能会耽误关键问题的处理;第三，运维人员工单确认问题，以往运维人员只是通过电话接单然后即刻处理，这使得运维人员的工作量难以统计，运维工作的质量难以得到有效监督和管控［1］。

针对上述问题，故障报修平台的设计目标是建立一个方便快捷的在线故障报修系统，方便用户及时提交问题，方便系统运维部门安排工作，使运维人员能够根据故障的轻重缓急来灵活安排维护任务，并能够通过任务记录来对运维工作进行监督和管控［2］。

2 系统结构

在线故障报修平台采用典型的B/S(Browser/Server，浏览器/服务器模式)应用程序架构。B/S结构是Web兴起后的一种网络结构模式，Web浏览器是客户端最主要的应用软件。这种模式统一了客户端，将系统功能实现的核心部分集中到服务器上，简化了系统的开发、维护和使用。客户机上只要求安装一个浏览器(Browser)，如Internet Explorer或Firefox等，浏览器通过Web Server同数据库进行数据交互。这种模式大大简化了客户端电脑载荷，减轻了系统维护与升级的成本和工作量，降低了用户的总体成本(TCO)。B/S结构最大的优点就是可以在任何地方进行操作而不用安装任何专门的软件，只要有一台能上网的电脑就能使用，客户端零维护，并且系统的扩展性非常容易，只要能上网，再由系统管理员分配一个用户名和密码，就可以使用了［3］。

报修平台基于.Net技术构建，Web前端使用由HTML语言和JavaScript脚本构建的Web页面，用户通过前端页面和后台服务器进行交互，整个过程通过HTTP协议进行数据传输。Web服务器采用微软的IIS并运行.Net Framework服务以及其他必要的系统程序，平台应用程序在这个环境下运行，向前端输出页面，接收前端用户指令进行逻辑处理，并和数据库系统进行交互。数据库系统采用微软的SQL Server 2005数据库系统，负责存储和处理数据。整个平台的设计结构如图1所示［4］。

图1 系统运行结构

报修平台的人机交互界面由Web页面来完成。用户通过Web浏览器向应用服务器提交操作请求，Web服务器接收用户传来的请求和数据，并和数据库进行交互，进行必要的数据处理，最后把用户需要的数据处理成Web页面，然后通过HTTP协议传输给用户的浏览器，用户的浏览器解析数据流，还原Web页面并展示给用户。用户直接面对的是Web页面，而不需要关心后台服务器是如何处理的，通过Web页面实现操作界面和逻辑处理的分离。对于页面的控制，一方面通过Web服务器向用户浏览器输出，另一方面通过页面上JavaScript脚本来进行必要的控制，配合服务器端进行数据验证、页面功能和样式的控制等［5］。Web服务器运行着平台系统程序，一方面向前端输出页面，一方面要执行逻辑处理，同时还要和数据库进行交互，读取和写入数据。整个故障报修平台的系统层次结构如图2所示。

图2 系统层次结构

3 系统的业务流程

系统业务流程示意图如图3所示，系统报修平台可以通过接入企业局域网的电脑或者移动终端设备(手机、平板电脑、PDA等)访问，只要是具有Web浏览器的设备并且能给接入企业局域网就能够使用报修平台。为避免报修平台被滥用，系统采用登录认证方式使用，即必须先登录系统才能使用，并且登录系统的帐号不能任意注册。开发专门的接口程序，使报修平台和企业OA系统(自动化办公系统)的账户系统同步，这样就限制了只有OA系统的用户才能使用报修平台，并且由于OA系统的账户是和人力资源绑定的，这样就实现了实名使用系统。

用户登录系统以后就可以填写故障申报单。故障申报单包含的项目有:标题，故障申报单的标题;故障系统名称，发生故障的是什么系统;功能节点，故障出现在那个功能节点上;发生时间，故障发生的时间;操作过程，出现故障时用户的操作过程描述;故障描述，对出现的故障进行详细描述;截图，故障出现时的屏幕截图。用户填写的故障申报单保存后正式生效，状态标记为“已提交”，并且不能被删除或修改。

系统运维部门的调度员登录故障报修平台后，可以查看用户所填写的故障申报单，并为每张故障申报单指定处理人员，对于不需要处理的故障给予“无需处理”的答复。故障申报单被指定了处理人员后，状态标记为“已派工”，已被调度员答复的申报单状态标记为“已处理”。负责系统运维的工作人员登录报修平台后可以查看分配到的故障申报单，并可根据实际情况安排处理顺序。故障处理完毕之后，工作人员再次登录系统，填写故障处理报告，包括完整的故障处理过程、处理时间和处理结果，然后由调度员确定是否可以关闭故障申报单或者继续处理。处理完毕并且被调度员关闭的故障申报单状态标记为“已处理”，同时故障申报单的申报人会得到系统发送的故障处理结果提醒邮件。

用户还可以通过系统查找以往提交的故障申报单，并可以查看对应的故障处理报告。所有的故障申报单和处理报告都在数据库中保存，并且可以通过不同维度进行检索，比如可以根据故障处理人和时间范围来查看某个运维工作人员的的工作情况记录。

图3 系统业务流程示意

4 系统功能

4.1 用户帐户

故障报修平台的帐户系统是通过接口和OA系统同步的，因此禁止自由注册用户、禁止用户修改任何信息。系统设置一个系统管理员用户，用以配置系统功能。对于用户的权限，划分成四个角色进行管理:管理员，具有配置系统功能的权限;调度员，具有派工和关闭故障申请单的权限;维护员，填写故障处理报告的权限;普通用户，提交和查询故障申报单的权限。只有系统管理员才能指定调度员和维护员角色，只有调度员才能派工和关闭故障申报单，只有维护员才能填写故障处理报告，只有普通用户才能填写故障申报单，所有用户都具有查询的权限。一个用户，只能拥有调度员、维护员和普通用户角色中的一个角色。

4.2 故障申报单的填写功能

故障申报单是故障申报处理的第一步，这个表单只有具有普通用户角色的系统用户才能填写。故障申报单记录的内容包括:标题、发生故障的系统名称、故障发生的功能节点、故障发生的时间、出现故障时用户的操作过程、故障的详细描述、故障出现时的屏幕截图、故障申报单的填写时间、申报人。其中除了填写时间和申报人通过系统自动填写外，其余各项需要申报人自行填好。

故障申报单的填写界面上提供三个操作按钮:重置按钮，清空当前表单上的所有数据，以便于重新填写申报单;保存按钮，首先触发一个页面上的JavaScript脚本，用来验证表单填写的有效性，验证通过后把表单提交到服务器，使申报单被保存到数据库中并正式生效;取消按钮，关闭申报单填写页面，返回到平台主菜单界面。

4.3 派工和申报单关闭功能

对于用户提交的故障申报单，要能够在系统中指定一个处理人;对于已经处理完毕的申报单，要能够在系统中把它关闭。派工和申报单关闭的功能只能由具有调度员权限的用户来操作。调度员在接到用户提交的故障申报单后，要为其指定一个维护员作为故障处理人。若被指定的维护员因故无法处理这张申报单，可以联系调度员重新指派处理人，调度员在维护员填写故障处理报告之前可以重新指派故障处理人。维护员填写完故障处理报告后，对应的故障申请单视为已被处理，此时调度员可以选择关闭故障申报单。如果用户对处理的结果不满意，调度员可以重新指派故障处理人，以对故障再次处理。

4.4 故障处理报告

故障处理报告由维护员填写，用以记录维护员对故障的处理过程和结果。故障处理报告要记录的内容包括处理的时间、处理的过程、处理的结果。维护员只能针对分配给自己的故障申报单填写故障处理报告，一次只能填写一张报告单，报告单一旦保存即生效，不能修改或删除，也不能追加。维护员一旦填写完处理报告，其对应的故障申报单就视为已被处理，转交给调度员处理，维护员将只能查看但不能对其进行任何处理。对于被多次处理的故障申报单，其对应的故障处理报告均予以保留，在数据库中以一对多的关系存储，以备查阅。

4.5 查询和统计的功能

故障申报平台提供对申报单和处理报告的查询功能。查询可以按照多个维度进行，用户可以自行选择查询条件进行查询。对于查询结果，还要实现穿透式联查功能。例如:点击查询结果中故障申报单可以查看其对应的处理报告。除了查询之外，系统还要提供必要的统计功能。例如:统计一段时间内故障处理的执行情况。查询和统计功能对所有用户开放。

5 故障报修平台带来的优势

5.1 解决了故障申报困难的问题

以往，当故障集中发生时，维护人员的的电话就成了热线电话，很难打得通。维护人员为了顺利处理故障，需要在电话里对用户反复、仔细地询问并记录，这势必会占用大量时间。维护人员在接到用户的报修电话后，在询问记录的同时也在针对问题进行处理，问题的申报和处理不能分开，占用了大量电话时间，使得其他用户不能及时提交问题。故障申报平台的使用，使用户不必再去关心向谁申报问题，不用再去抢拨维护人员的“热线电话”，只要连上网络，打开浏览器就能提交问题，并且按照系统给出的格式仔细填写，免去了维护人员的反复询问，故障申报从此畅通无阻。

5.2 提高了故障处理的效率和水平

故障申报平台的使用，改变了以往系统维护工作的方式。以前，维护人员接到故障申报的同时就开始了故障处理的工作，不能够根据实际需要灵活调整工作顺序。现在，故障申报和处理完全分开。调度员在接到故障申报单后，能够根据故障内容来分配处理人员，并且处理人员能够根据实际情况安排故障处理顺序，使得那些急需处理的故障能够及时得到解决。以往，故障的申报和处理缺乏记录，对故障的处理情况难以进行监督。现在，所有的故障及其处理都记录在案，随时可以查询和统计，对故障的处理情况有了监督和管控的工具。以往，对故障的处理完全依赖维护人员的个人能力，现在，依靠故障报修平台，相同故障只要处理过就能够被检索到，实现了知识共享，提升了运维部门的服务水平。

5.3 解决了运维工单的确认问题

以往，维护人员处理完系统故障后，需要填写系统运维工单，运维工单要交给用户进行确认签字。每隔一段时间，由专人整理这段时间内所有的工单，以确定运维工作量，并据此计算运维费用。但是，靠运维人员自己来填写工单往往不及时、不准确，漏填、错填频繁发生，影响了运维费用的支付。现在，借助故障报修系统，运维的工作量一目了然。因为所有的运维工作全都在系统中保存有记录，极大地方便了运维费用的核算和支付。

6 结语

在线故障报修平台本身也是一个信息系统，这个信息系统是用来服务其他信息系统的，是企业信息技术部门自身实现工作信息化的基本手段，这个系统也是企业基本信息系统建设项目之一。这个在线故障报修平台，直白的说，就是利用信息化来促进信息化，利用现代信息技术帮助企业信息技术部门提升工作效率和服务质量，助力打造全数字化企业。

故障报修平台改变了运维工作的方式，把故障报修、派工和故障处理工作分开，使得用户能够轻松方便地提交问题，也使运维服务人员能够集中精力在故障处理上，既方便了用户，也方便了运维服务部门，既提升了运维服务的质量，也有利于对运维工作本身的监督和管理。随着企业信息化的不断深入，运维工作的工作量和难度越来越大，建设一套故障报修系统已经成为了企业信息系统建设中不可或缺的一部分。但是，尽管故障报修系统在一些大型企业中取得了不俗的成效，但我们也看到，这个系统本身还具有很多局限性。例如，受限于用户自身计算机操作水平和对信息系统的掌握程度，在没有技术人员帮助的情况下，对于有些系统故障难以描述清楚，这种情况下用户需要得到信息技术人员的协助才能完成报修单的填写。另外，受原有工作习惯的影响，一些用户仍然觉得通过电话报修最直截了当，这需要加强对用户的培训，并通过相关制度来规范报修流程。报修系统毕竟也只是一个信息系统，不是所有的问题都能够通过信息系统来解决，说到底信息系统只是一个工具，必须配合必要的规章制度才能发挥出最大效用。

［1］王东红，魏广朝.信息系统运维基础［M］.北京:北京理工大学出版社，2012.

［2］王景光.信息系统建模与结构复杂性［M］.北京:机械工业出版社，2011.

［3］舍利.系统分析与设计教程［M］.史晟辉，译.北京:机械工业出版社，2010.

［4］汪洋.NET应用架构设计:原则、模式与实践［M］.北京:机械工业出版社，2012.

［5］Douglas Crockford，JavaScript语言精粹［M］.鄢学鹍，译.北京:电子工业出版社，2012.