记一次历时六小时的上线经历

　　这是农历去年（阳历2016.1.29）的事了。公司的一个项目已开发得七七八八了，要准备上线了。项目经理与公司领导及用户协商，定于2016.1.28日（周四）上线。但这天由于项目经理需要去机场接人，加上运维组同事也忙着。就推后一天上线。这里就不得不谈下公司的项目从开发到上线的过程：公司项目分开发，测试，预发布，正式四个环境。开发和测试环境由开发人员部署，预发布环境由开发人员协助测试人员部署（我们组的测试不懂，全程操作还是由开发来部署），正式环境由开发人员协助运维组部署。

　　

　　这个项目上线所需要部署的有DB，WEB程序，WCF接口程序，Windows服务程序以及文件服务器部署。 由于我们这个是崭新的项目第一次上线。就有有很多工作要做。一周前已由项目经理申请了三台机器：DB一台机器，WEB，WCF,Windows服务共用一台机器，文件服务器一台机器。定于周五上午九点半正式开始上线，我（开发）准时去找运维同事，运维没来，加上其他一些事直到10点多上线正式开始，我也是在这家公司的第一次协助运维做新项目上线，首先，找到运维人A（女），催促其上线。上线一般都是先部署DB（大家都知道），A说DB的部署不归她负责，叫我找B（男），我就找B并转发上线邮件包括上线说明文档，B知道后说知道我们的这个项目要上线这回事，但这三台机器好像没交到他们运维手上（没收到邮件，由另外的同事发出的，具体谁不清楚），然后和A及其运维领导讨论说了下，说机器应该是已经在运维手上了，然后B查了下，果然他们已有权限操作。B又说，这个DB部署的话要装数据库，这台机器应该是没有装SQL的。然后说要现状SQL，那就装吧。因为是年底了，技术部很多小组的项目都在等着上线或执行DB脚本，运维的都很忙。中间时不时有人打断，运维组的中午又有聚餐。11点半，我回到自己的座位，下午2点半，又拿着电脑去运维组那边。催促B，此时B开始装SQL，大约4:20分样子，SQL安装好了。然后DB配置这台新机器的环境以及部署我所提供的本项目的数据库。下午5点过点部署完成。因为项目有数据同步，需要访问其他项目组的数据库，B还需要配置其他数据库针对本项目的权限及安全措施什么的。 我看他这边差不多了，在去找A，让A部署程序包。A这边部署比较顺利，三个部署包加配置文件修改差不多三十多分钟。至此，A,B这边都已部署完成。项目正式部署完成。

　　问题来了：由于一些主数据是Windows服务从上游数据库同步过来的。好，先启动服务程序。查数据库同步的数据及看服务Log，嘎嘎！数据没有同步过来，但服务日志没有报错信息。初略的想了下，感觉部署配置什么的没有问题，我去找开发数据同步功能的同事C（女）过来看。好吧，她也没找到问题所在。又请教了下另外一位开发同事（架构师），猜想应该是哪里异常没记录，没办法，我只得看代码了，果然：此段代码中有try catch但catch中没有记录日志和抛出异常的处理，加上异常处理重新部署Windows服务程序，还是无数据无异常日志，继续看代码，发现方法内调用的一个方法（因为代码的逻辑并不是都在一个方法里，而是方法1中会调用方法2方法3或者更多）也有try catch但catch中没有记录日志和抛出异常的处理，加上并检查其他方法，然后重新部署，好了，服务LOG中记录了异常信息：无权限访问本项目的数据库，去找B，B重启了下DB这台机器，然后又报另外一个异常：无权限访问USERbase数据库，完了，上游数据库出无权限访问了。此时B已经下班走了，幸好另外一位运维同事D也有权限操作，让D加权限。再次启动同步服务。同步的数据还是没有过来，继续看日志，出来了两个异常。上游DB库M没有某个视图，上游DB库N某个视图中缺少某个字段。完了，上游其他系统提供给本项目的一些东西都还没有上线，没办法了。此时已经差不多八点多了。之前同事C和其他组确认过，都是说已经上线了，临了居然没上。项目经理和我们商量着说，只有等到明年在上了（因为下周我们组人差不多都回家过年走了）。运维这边说上线单还是按已完成来做，发邮件说明明年来了在上。然后各回各家了。

　 悲催的一次上线经历。待续。