失败的一次客户现场软件实施经历总结

    续接上篇：草根程序员转型做项目管理走过的点点滴滴之(十六、七)人团队2013年始于足下 

    经历了三个来月的忙碌工作，我们团队的问题，终于在这次客户现场实施过程中暴漏了出来。

    2013年7月15日晚坐卧铺第二天(16日)到达DEF城市，直接来到客户现场做系统现场实施工作(称呼为A系统)。第一天倒还相对的平静，可后续的事情一件接一件，让我又一次感受到天底下没有任何两次出差经历是相同的。

    由于客户没有提供单独的服务器，与我们公司另外一个软件系统(称呼为B系统)部署在同一台服务器上。由于我部署期间该台服务器上的sql server服务器突然异常终止服务了，而且出现了三次，客户直接找到我，问我是不是因为我部署系统导致B系统不能正常工作了，一听这话，我就猜到了接下来的工作不会好开展，显然公司商务上跟客户谈的不是很融洽。后来我跟客户的解释了好一通，并告知他们以后B系统再遇到类似问题，可以先从排查服务器上sql server服务是否异常终止服务进行排查。初步定为为sql server2005没有安装好，导致不定时的会终止服务。计划重装数据库。这一关勉强还算简单的过了，可下一件事情就比较曲折了。

   客户的数据库服务器是sql server2000的版本，而且电脑硬件也稍微的差一些。由于我们针对的这个行业每年都是6月1日至10月1日是软件使用的高峰期。我刚把A系统涉及到的三个iis应用加一个gis服务部署完成后，客户又找了过来，问是不是我们架设A系统影响到了数据库服务器，他们以前的旧软件运行一段时间就卡死了。面对这个问题，我做了如下几点分析：第一：sql服务器上是仅仅是对应的库访问卡还是所有的库都卡(因为有一个主库是几乎所有行业软件都要访问的)，后来经过与客户一起证实是单库造成的卡死现象。第二：打开了sql server自带的事件查看器，把需要监视的项目勾选上做实时监视分析，后来发现我们系统A确实存在一些空的数据库操作行为，而且一秒内就有多条请求，由于A系统底层使用是spring.net原因在客户现场也没顾上细找。由于考虑是在客户现场处理问题拖太久对公司影响不好，我果断的采用了我们公司另外一个产品C(标准业务数据库库数据实时同步软件)在应用程序服务器上把数据库服务器上的业务数据库实时的交换到这新建的一个数据库服务上。把A系统对原来业务数据库的影响几乎降为了零，在用数据库事件监视器看A系统没有再向2000库发起过任何请求。但是2000库还是会造成他们业务系统顿的现场，但是现在他们旧系统还勉强能运行。我把sql server事件查看器的使用办法也交教会了客户，好让他们自己学会分析造成卡顿的原因，而且客户因此也认可了即使没有A系统运行，他们的库也会消耗内存不断增加，导致他们的旧软件出现卡顿的现象。  由此现象推断出，即使sql server耗掉内存相同的情况下，对应用程序的影响也会有不同的。至于现有A系统的优化调整，在后续分享。

    随后A系统的部署过程更是“恶心他妈看到恶心回家，恶心到家了”，暴漏了我们团队一件又一件的问题，现在20来人的团队一团乱。团队管理上的问题是导致这次失败经历的最直接原因，发布版本回归测试严重不足；测试过程项目负责人没有参与；形成的成果物也是不忍心看。成果物管理混乱，根本达不到成果物管理的最低要求；文档缺乏，给团队造成巨大的成本隐患，东西都在程序员脑子里，是件巨可怕的事情；代码走查做的严重不到位，三令五申的编码要求都无法得到落实；日志的记录更是有一搭没一搭的，零零散散，导致出错后没有日志输出，对问题的排查造成了巨大的影响；等等问题都暴漏的那么的明显。造成了原本应该在1到2日就可以完成的系统部署及与客户交流工作，现在经过四天的持续加班还是没能拿出理想的发布版本。

   通过此次现场实施系统经历，遇到了一些问题，暴漏了一些问题。遇到问题、暴漏问题都不可怕。关键是后续的总结与团队调整一定要跟进。后续的跟进等出差回到单位后陆续的进行，有成果了我会分享出来，望有相似发展经历的软件团队引以为戒。

     希望能与更多的软件同行进行交流，交换想法，共同进步。