系统下线工作总结

       前两个月，我负责了公司老系统：ERP（第三代营运支撑系统）的下线工作，从4月份到6-1。这段时间对这项工作的有很多的感触，现在比较闲了，我就对这项工作做一些总结，也给有类似情况的各位同仁提供一些参考。

       首先，我先来讲下背景：公司为了将来的发展及上市需要，重金打造公司第四代营运支撑系统。这个系统从立项到最终上线，经历了2年时间。2013-06-01新一代的营运支撑系统即将要上线，很多其他的周边系统要配合进行改造，把原来对接到ERP的接口改为对接到新一代的系统（下面简称A），这包括ERP在内，总共周边系统加起来有16个，上线工程异常庞大，对公司影响巨大。  鉴于此背景，A与ERP的割接方案采取“一刀切”的方式进行（具体原因不讲），A对ERP提出了以下要求：1、由于A要进行数据迁移的需要，通过分析梳理，需要ERP进行相应的功能改造，来满足A系统数据模型的需要；2、6-1 10：00 ERP当中除了指定的一些功能之外，全部切换为只读状态，不允许对其进行增、删、改。

       接下来，针对这样的需求及背景，IT专门成立了“周边系统配合A割接上线项目组”，ERP包括其中。而由于我一直以来就是做ERP维护的，所以有幸被领导指定为“ERP配合A割接上线负责人”，而ERP这条产品线（需求、开发、测试、应用、DBA）的资源我都可以随意调动。

           再接下来，我针对A对ERP的要求，及现阶段的工作情况，做了以下分析：其实在成立项目组之前我不是作为ERP配合A的负责人，是另外一个人（接下来简称B）。等到项目组成立时，我伸手去接这个事情，B也没有做一些具体的工作，只会崔A那边的人员，而且不是B本人去崔，是通过另外一个人（简称C），而C由于本身工作也比较多，所以只是一段时间崔下，没有具体跟进。所以等我去接手时，B也没有做什么交接，也没有跟我说什么其他的，其实跟没做一样。

         针对这样的现状，我梳理了下工作的方向及思路：

1、明确用户需求，走需求流程，后有变动，走需求变更流程；

2、对A提出的两个需求，我和ERP另外一位开发负责人（简称D）共同简单讨论了一些方案；

3、针对方案中的一些未使用过的技术进行技术预研；

4、根据技术预研的结果，编写ERP下线方案PPT，并进行评审与相关问题决策；

5、走系统变更流程，明确开发、测试时间；

6、6-1 配合A进行部署；

7、部署校验及相应的值班计划。

 

“明确用户需求”这点，由于A针对ERP要放开的功能目前未确定，但是又不给出一个确定版的时间，我找A那边的负责人明确给出一个具体的时间，并把这个事情邮件发送给相关领导知晓，后来这件事情就按时给解决了。

“需求解决方案”这点，我找了ERP这条产品线中的D讨论了初步的方案，然后再跟应用及DBA进行相应的讨论。最后得出的解决方案是：ERP只读查询，除一些例外功能，解决方案是：Oracle权限控制实现。

 

“技术预研”这点，根据我们最终采用的解决方案，Oracle权限控制实现。有两种不同的手段，第一种是表空间权限控制(即新建一个表空间，把可以进行写操作的表移动到新建表空间中，其他表空间只读)；第二种是用户权限控制，即新建一个用户，分配给这个用户可以进行写操作的表权限。这两种方案无论哪一种，都需要把有写操作权限的表找出来，而要找这些表就得从可以进行写操作的功能里面找。经过开发的力量，最终查找出来这些表的清单，及这些表所对应的功能。经过对这些表的分析，发现有几张表不仅数据量大（上亿级）而且对业务有重要影响。如果采用表空间的方式，则移动这些表会造成索引失效，影响业务，而且这个移动不是说几分钟能够移动完毕的，而需要几个小时。所以最后没有采用这种方案。

 

“编写方案PPT”这点，采用的方案，各参会领导及架构师都是认同的，但大家争论的焦点是，方案实施后的测试范围。通过从DB中查找信息发现，现在的ERP系统中有1700多个菜单，可想而知，对1700多个菜单进行测试的工作量是多么的大，而且可能大部分的工作都是白费的。针对这个问题，第一次会议没有达成一致意见，我总结了第一次会议的情况，在第二次会议时给出了4种解决方案，并最终大家投票通过。结论是：例外功能都要测试+重点的查询功能。

 

“走系统变更流程”这点，起初不是走的这个流程。总的来说，公司的流程有点复杂，质量部对一些新制定的流程没有把控好，流程发布后问题非常的多，而且存在的争议较多。这个过程经历过流程没走对的情况，与B争吵过，并最终把B说服走”系统变更流程“。之后开发开始开发脚本并在开发环境测试，确定转测试时间，测试准备测试环境并测试。在这过程中也遇到一些问题，我负责跟踪解决，比如开发测试沟通机制，这确定了之后提高了问题解决时效。

 

“周边系统影响分析”这点，这点做了很长时间，跨越了几个阶段。这点我主要是从DB当中的用户所对应的应用，及这些应用中所提供服务的调用系统。召开会议一一确认影响及ERP这边的解决方案，最终成功消除了影响分析不到位的问题。这项目工作分析的最深层次出发点是，哪些操作会修改ERP的数据，所以除了上面说的周边系统影响，还有一个工作流的影响：我们公司有一种“数据变更工作流”，用来处理因系统问题或其他业务考虑不全情况下的数据更新措施，既然ERP只读，那么针对“ERP”的数据变更工作流，就在提前结束，为此我联合服务部向一线发布公告，在5-31  20：00之前起草完要处理的ERP数据变更工作流，开发员加班审批。

 

“6-1 部署上线”这点，这点前面的工作做得很好，包括配合A的模拟割接，但是在这点有一点没有考虑到问题在当时发生了。我们采用的解决方案是：新建一个用户，使其对所有表都有查询权限，但是只对某些表有写操作权限。这种方案的话，就涉及到对应用修改数据库配置文件。而ERP应用采用集群，有20个节点，其中4个节点是在一台刚换两个月的服务器上。而负责替换工作的应用组负责人，之前对ERP应用并不熟练，只部署过两次。我也考虑到如果所有节点没有覆盖全的情况，但是没有考虑到另一个问题：LINUX系统不同，相应的shell脚本会有所不同，这点没考虑到，而生产上确实就是这样的情况。由于这个问题，操作人员之前提前写好的shell脚本对两台机器不适用，就包括新换不久的机器。在正式操作的时候，只能临时想命令了。而操作人员把新换的一台服务器给遗忘了。这种情况在部署后的校验方面非常难校验出来。这个情况最终导致有一些数据进入到ERP系统，后面通过ERP与A的相关人员协商，把这些数据手工给处理掉了。

 

“部署后校验及值班计划”这点，主要是测试人员验证，提前准备好验证用例，对功能进行校验，最终由于F5随机分配，刚好测试人员都没有分配到有问题的机子上，导致从部署操作完成之后，到一线反馈问题已经过去40分钟，所以说这种很不容易测试。如果没有这个问题，ERP下线计划及最终取得的结果应该来说是完美的，但是即使出现了这个问题，最终的结果应该来说还是很成功的。ERP下线后没有接到除此问题之外的问题。

 

       最后，我总结了下，我对shell还不熟悉，一个是由于公司原因，分工很细，另外一个是自己还学得不够深入。我想，这总的ERP下线的工作思路及当中相关技术问题的解决与处理方案是适用于一些公司的实际情况的。从这个工作，也加强了我对整体把控能力的锻炼， 我在这项工作中收获很多，希望与各位一起学习。