说一点小故事,业务发展中心为客户部署了一套FTS软件,这是一个BS软件,但程序在客户的服务器上,我们需要不定期的维护这个软件,如发送一些更新文件给客户方的某个负责人,然后由他覆盖程序文件,完成软件的更新。由于客户在江西,每次都需要华很长时间和客户方的这个负责人取得联系,所以软件更新不是很方便。
前两天客户说软件又出现了C盘无法访问的问题,导致网页访问出错。这个问题出现的原因是软件运行时在C盘根目录下面记录那些出错的SQL语句,便于我们跟踪调试,但是客户机器不允许其它程序访问C盘,所以出现了错误。解决这个问题很简单,只需要把软件配置信息中有关记录SQL日志的功能关闭或者设置一个可以访问的日志目录即可。上次出现该问题的时候找了我仔细询问了有关同事,他们“确认”发送到客户那里的程序这个“日志记录”功能是关闭的,而且在本地测试也没有问题,询问客户联系人,也说确保配置文件是更新过的,最后在项目负责人的要求下,把软件中的这段“日志记录”代码直接屏蔽了,临时解决了该问题。
由于这个“SQL日志”记录功能对于我们开发维护是比较重要的,所以我又把这段代码恢复了,仔细检查了所有相关源代码,重新发布了软件,期望找出真正的原因。这就是前面说的客户程序又出现C盘无法访问的原因。我给同事说希望客户把他们机器上的那个配置文件发回来看看,同事说很难跟客户联系上,每次更新都非常麻烦,而且客户方负责人对软件不是很了解,需要电话或者在线方式详细的指导操作过程。为了查明问题的真正原因,在我的一再坚持下,让客户把这个配置文件发回来让我看看。
跟客户联系的确不是很方便,直到第二天中午,我拿到了这个配置文件,果然不出我所料,“SQL日志”功能没有关闭。这时,同事也感叹到,问题的原因居然真是这样啊!
这件事情的前前后后,让我感触很深,一个问题的相关信息,经过层层传递,最后就可能失真了,正所谓“
眼见为实,耳听为虚”啊!
看来,我们的软件远程维护,不能再靠这种“刀耕火种”式的工作模式了,必须探索一种“
自动化的软件远程维护”方式,而完成这个功能的关键,就是我们需要强大的工具--“
千里眼”,看到客户那里发生的真实事情!
目前我正在研究的“
WCF邮件通信系统”,致力于解软软件的更新,数据的同步,远程诊断、远程维护、异构系统的通信等等我们原来不是很方便,甚至是无法解决的难题,相信有了这个通信系统,这个事情解决起来不再是“难事”了。
-------------
后记:
上周5,我们在确定深圳中行3期的程序问题的时候,发现之前一天客户说的“功能已经更新”实际上没有更新,升级程序1号就停止运行了,网站不可能更新。所以,
有时候客户说的事情不一定是真实的,需要我们多方面核实才行。如果有一个“远程维护系统”,系统的维护不需要太多的人工现场支持,那么问题会少很多,或许,这样的课题属于“运维自动化”吧。