《系统上线方案.docx》由会员分享，可在线阅读，更多相关《系统上线方案.docx（19页珍藏版）》请在课桌文档上搜索。
1、*系统上线计划(VLO)目录1 上线的总体说明错误!未定义书签。1.1 需要考虑的因素错误!未定义书签。1.2 上线方式52 上线单位网点上线主要指标52.1 系统功能范围72.2 性能指标113 上线过程113.1 关键环节（按操作顺序）113.1.1 概述113.1.2 环境搭建及版本管理123.1.3 系统基础数据迁移123.1.4 网点柜员权限数据维护133.1.5 账户数据迁移133.1.6 中心库存初始化133.1.7 实施网点数据初始化133.1.8 实时营业数据迁移133.1.9 数据库备份133.1.10 UO系统测试（测试卡）143.1.11 数据库恢复144 上线工作关键
2、时间安排75 上线组织结构56 上线后的问题处理流程146.1 设计的出发点146.2 网点问题的分类146.3 不涉及改源码的问题处理146.4 涉及改源码的问题处理146.4.1 紧急问题的处理146.4.2 非紧急问题的处理157 附件157.1 卡系统网点技术问题解决记录表157.2 卡系统网点技术问题解决跟踪统计表167.3卡系统问题修改情况跟踪表171概述为了保证*市卡一期系统能够顺利在试点网点从*卡系统切换，确保上线后卡系统的正常运行，现就各项相关准备工作和上线事宜明确如下。1.1 上线目标1）原*卡系统涉及到公交、出租、商业应用多个领域，并且服务网点达到60个以上，因此卡系统上
3、线必须确保原有业务不受影响，因此采用先上网点柜面系统（即卡管系统）、再上清结算，并且营业网点柜面系统上线采用先试点后分批上线的方式；2）根据目前的上线规划，原*卡系统和卡系统并行运行，首先*卡系统的所有卡账户数据以及基础运行数据首先同步到卡系统，并且在旧系统下线前，每天新老系统营业结束后进行业务数据的双向同步；3）在卡系统的外围系统中，园林的五个服务网点需要使用卡系统中园林年票开通的功能，因此需要园林的网络与联通机房网络连通，否则园林无法使用卡系统提供的功能。1.2 上线方式1）上线单位网点于9月28晚启动切换工作，9月29日上午开始正式营业；2）核心系统的基础数据（如应用类型定义表、卡产品定
4、义表、卡准备定义表等）采用初始化脚本的方式进行，在数据库部署时直接初始化；3）网点（建立账户）、终端、SAM卡信息、柜员信息通过迁移工具将数据从*卡系统迁移映射到卡系统；4）网点、终端、角色、柜员之间的关联关系通过卡系统提供的功能手工进行设置，网点库存、现金尾箱的初始化通过卡提供的功能进行：5）旧系统中超过IOo万卡账户数据、员工库、公交月票持卡人信息库等通过迁移工具从*卡系统迁移到卡系统；6）柜面系统上线后通过迁移工具将新老系统的营业数据进行双向同步。2组织结构卡系统投产之后，IT系统集中在卡公司联通机房、网点的技术工作相对较少，因此，技术人员主要集中在卡公司。考虑到网点在系统投产初期，对业
5、务操作的不熟练，还需项目组业务人员的现场支持。同时，在卡公司，除了技术人员之外，还需要留一部分业务人员负责出现问题修改的检验。基于上述考虑，卡系统上线的组织架构如下所示：各组职责和成员如下表:组别职责总体组 必要时调度、协调各方面资源； 根据各组进展调整进度； 决定特殊业务的处理方法； 跟踪控制所有问题的处理：根据情况决定新版本的发布；业务指导组对移植组进行业务处理的指导；对移植组进行数据核对的指导；对并行的问题做初步排查和分类，确定是属于业务操作、数据移植、旧数据、新系统程序、参数设置哪一种问题，提出问题；A关闭问题；环境组1 .负责中心机房环境搭建；2 .负责中心机房环境问题解决3 .负责
6、网点环境解决4 .数据备份恢复版本组1 .版本变更记录2 .新版本在各环境上的发布；3 .参数在各环境上的发布及一致性；移植组1 .账户数据导入；2 .实时数据迁移；3 .网点数据实施初始化开发组1.针对并行中发现的新系统错误进行修改并完成自测测试组1.针对并行中发现的错误修改做回归测试；网点支持组 网点软件环境确认 网点问题上报及简单说明；3工作进度安排4上线单位主要指标4.1 系统功能范围第一、交易功能本次上线范围包括标准卡制卡与库存、记名卡（学生月票卡、老年卡、老龄卡、园林卡）的充售补退换、不记名卡（普通公交卡、记念卡）的充售退换、应用开通、账务管理、库存管理功能。具体包括一级模块十个，
7、二级模块25个，三级模块IlO个。详细功能列表参见下表：*市卡综合业务系统功能菜单列表一级菜单二级菜单三级菜单四级菜单备注市民信息管理持卡人信息变更基础信息管理行业信息管理商户信息管理商户额度管理终端额度管理商户费率管理终端操作员管理终端信息管理SAM卡管理卡业务不记名卡售卡换卡换卡申请换卡审核换卡领卡退卡退卡登记退卡审核退卡退款制卡制卡任务生成制卡任务导出已完成制卡任务记名卡售卡公交学生月票售卡公交老年月票售卡公交高龄月票华卡园林年卡售卡补卡发卡换卡换卡申请换卡审核换卡发卡退卡退卡登记退卡审核退卡退款制卡制卡任务生成制卡任务导出已完成制卡任务标准卡申请待导入申请文件己导入申请文件比对信息比对
8、比对结果确认已确认查询制卡制卡任务生成制卡文件导出已完成制卡任务领卡待领卡片己领卡片补卡补卡领卡补卡登记换卡换卡申请换卡领卡注销注销登记注销退款充值电子钱包充值电子钱包充值撤销专用账户充值专用账户充值撤销应用开通停用应用年审续费挂失解挂口头挂失正式挂失解除挂失钱包转存补打凭证库存管理库存登记库存物品登记制卡返回文件导入库存数据导入未导入制卡返PI文件己导入制卡返回文件入库空白卡/半成品卡入库废卡入库物品入库入库撤销入库情况查询配送卡片配送（按任务）卡片配送（按明细）卡片配送（按数量）卡片配送撤销未接收配送单已接收配送单接收卡片接收接收情况查询出库空白卡/半成品卡出库废卡出库（按明细）废卡出库（
9、按数量）物品出库成品卡出库（按任务）出库撤销出库情况查询柜员库存卡片领用（按数量）卡片上交（按数量）卡片上交（按明细）柜员库存查询查询统计库存盘点库存台账账务管理账户开户网点账户开户网点领现网点领现登记网点领现撤销网点缴现网点缴现登记网点缴现撤销柜员领现柜员领现登记柜员领现撤销柜员缴现柜员缴现登记柜员缴现撤销柜员调剂柜员调剂登记柜员调剂撤销柜员交接柜员交接登记柜员交接撤销轧账处理柜员轧账网点轧赈交易管理不记名卡充值修补记名卡充值修补不记名卡临时交易调整记名卡临时交易调整不记名卡错账预调整记名卡错账预调整卡信息查询退换旧卡监控查询统计充值交易查询卡账户余额汇总系统管理柜员管理网点管理角色管理柜员
10、授权岗位管理岗位分配系统参数定义基础信息管理本地编码结构本地编码主表通用帮助打印服务配置打印服务器配置服务路由类配置服务路由规则配置卡业务参数管理黑名单管理黑名单维护黑名单查询参数管理卡产品定义卡产品应用类型关联收费规则定义应用类型定义应用收费定义统计报表卡公司消费统计报表卡人次消费统计报表每日营业审核报表网点业务统计报表园林查询统计报表第二、外部接口功能1、园林应用的接口设计及开发系统提供同园林应用的接口。具体向园林系统提供园林充值文件、园林年票持卡人信息、黑名单文件,采用数据库表的接口方式提供给园林应用。2、与*卡数据同步的接口设计及开发主要通过文件方式同*卡系统进行各类数据同步，接口文件
11、分析数据迁移实施步骤。3、与社保系统接口的设计及开发社保系统提供卡系统各类制卡文件，包括BLK*.mdbBLK*（补）.mdb、BLK（急）.mdb4.2 性能指标交易并发处理能力：IOO个并发数在100个是，单笔联机交易响应时间为510秒5上线方案5.1 关键环节（按操作顺序）5.1.1 概述*市卡系统切换工作可以分为以下九个环节的工作：1 .环境搭建及版本管理2 .系统基础数据迁移3 .网点柜员权限数据维护4 .账户数据迁移5 .中心库存初始化6 .实施网点数据初始化7 .实时营业数据迁移8 .数据库备份9 .系统测试（测试卡）10 .数据库恢复5.1.2 环境搭建及版本管理环境搭建的重点
12、是生产环境的搭建和维护（联通机房）、自测和UAT环境的维护（卡公司制卡间），以及迁移环境的搭建及维护（联通机房）。这三套环境的用途依次是：自测和UAT环境是开发人员和业务人员用于自己实施修改问题的检验：移植环境主要是用于上线前数据迁移和上线后每日数据同步；生产环境的硬件和系统软件的搭建及维护环境组负责，后期交给用户；5.1.3 系统基础数据迁移数据库系统通过脚本将如下基础数据进行初始化：1） CD_APP_KIND（应用类型定义表）2） CD_CARDP_DEF（卡产品定义表）3） CD_CARDP_PREPRULE（卡准备定义表）4） CD_CARD_APP（卡产品应用关联表）5） CD_T
13、RANS_CODE（交易代码表）6） AC_ACCOUNT_TYPE（账户类型表）7） AC_ACCOUNT_APP_TYPE（账户类型关联表）8） CD-BUSLPARAM（卡业务参数表）9） CD_TRANS_PARAM（交易参数表）10）应用参数表（AC_APP_PRM）11）终端操作员信息表（AjTMjDPRNFO）（只有出租车司机信息有用）12）交易类型信息表（ACLTXNLTP）13）会计分录设置表（AC_GL_DEAL）14）会计科目定义表（AC_GL_MAST）5.1.4 网点柜员权限数据维护权限数据维护的表格如下所示：1）网点（建立账户）2）终端3）角色4）柜员5.1.5 账
14、户数据迁移主要是通过迁移工具将*卡现有的账户数据迁移到卡系统中，主要实体如下：5）卡账户6）员工库7）公交月票持人信息库8）IC卡信息库9）标准卡信息5.1.6 中心库存初始化从卡公司获取所有的未售卡记录，并导入到卡系统中。5.1.7 实施网点数据初始化新系统营业前一工作日，下班后将营业网点卡片、现金进行清点，首先通过脚本将网点现金总和更新财务部的账户余额，然后通过将中心库存的各类卡通过网点配送和柜员领卡功能进行卡片在网点的初始化，通过网点领现和柜员领现功能进行现金在网点的初始化，检查现金是否初始化成功只要查看财务部的账户余额是否为零即可。5.1.8 实时营业数据迁移实时营业数据主要是指把26
15、、27、28号三天的卡网点营业数据更新到卡数据库中，这样可以保证原*卡系统与卡系统的数据保证一致，并且实时营业数据迁移在每天各网点营业结束后都要在卡系统和*卡系统间同步。5.1.9 数据库备份营业数据迁移完毕后，为试点网点的营业己经做好准备，为保证在正式营业后系统的正确性，需要利用测试卡再次进行系统测试，在测试前将数据库进行备份。5.1.10 系统测试（测试卡）通过发行二十张测试卡将准备营业的系统再次进行测试。5.1.11 数据库恢复测试结束后，将数据库再恢复到测试前状态。6上线后的问题处理流程6.1 设计的出发点对网点提交问题进行合理分类，采取不同的处理流程;对网点问题解决涉及代码修改的，进
16、行严格的控制；对网点问题进行详细记录，以实现经验共享。6.2 网点问题的分类技术组对网点提交问题分为需要改源码和不改源码两种情况。6.3 不涉及改源码的问题处理技术组接口人收到问题之后，落实问题解决人员； 问题解决人员首先到网点技术问题解决跟踪统计表中查询，这个问题是否以前出现过，如果有直接给网点答复。如果没有组织相关人员解决。 问题解决或者直接答复网点之后，承担这次问题解决的责任人必须负责填写网点技术问题解决记录表，经过技术负责人签字之后，由专门的人员录入到统计表中，以供下次参考。6.4 涉及改源码的问题处理6.4.1 紧急问题的处理第一、紧急问题的定义流程走不下去的问题；第二、处理流程 测
17、试人员/技术人员将需要修改的问题在缺陷系统中登记； 登记之后，填写卡系统问题修改情况跟踪表的前三部分（参霓附件）； 改文档必须经过技术或者业务负责人手工签字之后，技术人员就可以着手问题修改； 技术人员问题修改完成之后，必须在开发环境完成自测工作。测试通过之后，重新填写方系统问题修改情况跟踪表的第四部分,在征得质量经理同意，并签字之后，由配置管理员负责将修改涉及的文件纳入到Beta版本库中；如果不具备UAT测试条件，而网点急用，可以直接发布到生产环境。但是，这种举措需要经过应急小组主要负责人共同决策，而且，这个问题也必须在日后经过UAT测试。 业务组安排的测试人员接到先蔚统府嫁绥或始犯幽球之后，
18、按照跟踪表的要求，到UAT环境中检验修改问题涉及的功能点（或者是交易）。测试用到的版本，由配置管理员从Beta版本库提供； 测试人员检验之后，必须在卡系统问题修改情况跟踪表将署意见,并手工签字； 通过检验的问题，由版本管理员纳入下一个版本库。同时，由配置管理员负责填写声系统版本管理跟踪表,略），将问题修改的详细情况做统一记录。由卡项目版本控制委员会，决定是否正式升级卡系统试用版本及版本号，最后，进行正式的发布。6.4.2非紧急问题的处理 测试人员/技术人员将需要修改的问题在缺限系统中登记； 登记之后，填马卡系统问题修改情况跟踪表的前三部分（参见附件）； 改文档必须经过技术和业务负责人手工签字之
19、后，技术人员才可以着手问题修改； 技术人员问题修改完成之后，必须在开发环境完成自测工作。测试通过之后，重新填写片系统问题修改情况跟踪表的第四部分,在征得技术组质量经理同意，并签字之后，由质量经理授权配置管理员负责将修改涉及的文件纳入到Beta版本库中；同时，技术人员向业务组申请测试安排； 业务组安排的测试人员接到*系统府嫁修我懵次蜀第差之后，按照跟踪表的要求，到UAT环境中检验修改问题涉及的功能点（或者是交易）。测试用到的版本，由配置管理员从Beta版本库提供； 测试公总检验之后，必须在卡系统问题修改情况跟踪表居噜意见,并手工签字； 通过检验的问题，由版本管理员纳入下一个版本库。并在修改问题积
20、累到一定数量之后，由配置管理员负责填写优点裕钵管理用线表（略），将问题修改的详细情况做统一记录。当问题修改累计到一定数目之后，由消嗦线项目版本控制委员会，决定是否正式升级犬系统试用版本及版本号，最后，进行正式的发布。7附件7.1 卡系统网点技术问题解决记录表问题编号网点名称提出人收到时间问题类别问题名称问题的描述问题解决步骤网点反馈技术负责人意见同意/不同意不同意理由：签字：日期：年月日7.2 卡系统网点技术问题解决跟踪统计表编号问题名称问题描述问题解决步骤类别网点反馈提出网点提出时间12345678910111213141516171819202122237.3卡系统问题修改情况跟踪表第一、
21、基本信息：修改问题缺限系统编号：修改问题编号：修改问题名称：修改类型：业务发起技术发起申请人：申请日期：一年月日第二、问题概述：1、修改理由:2、修改内容:3、对相关模块的影响:4、问题修改的风险分析:第三、问题的业务描述:1、涉及的模块2、涉及的交易（是否新增交易码）3、涉及的外围系统功能接口4、涉及的会计分录5、涉及的业务参数定义6、涉及的业务流程更新第四、问题的技术描述：1、数据字典更新列表2、表结构修改（与脚本配套）3、配置文件修改列表4、前台修改文件列表5、后台修改文件列表技术负责人审批意见：业务负责人审批意见：同意口/不同意口同意口/不同意口不同意理由：不同意理由：签字：签字：日期：年月日日期：年月日测试人员意见：同意口/不同意口不同意理由：签字：日期：年月日技术组质量经理审批意见：同意口/不同意口不同意理由：签字：日期：年月日
