《专项梳理zlhis系统升级》由会员分享，可在线阅读，更多相关《专项梳理zlhis系统升级（23页珍藏版）》请在金锄头文库上搜索。
1、系统升级的流程成都中联信息产业有限公司- 18 -版本信息版本创建时间版本变化调整描述完成人主要参与人完成时间1.02015.07.03于陈于陈注：单击此处输入文字。目录1进场前- 0 -1.1 目标版本确认- 0 -1.2 升级团队成员确认- 0 -1.3 数据库环境确认- 0 -1.4 模块接口使用情况确认- 0 -1.5 测试服务器准备确认- 1 -1.6 测试客户机准备确认- 1 -1.7 注册码申请- 1 -1.8 梳理重大修改说明- 1 -1.9 梳理BUG、需求列表- 2 -1.10 重大问题通告- 2 -1.11 待升级处理问题列表- 3 -2测试期- 3 -2.1项目启动会议
2、- 3 -2.2测试服务器搭建- 3 -2.3测试客户机及环境准备- 3 -2.4测试升级- 4 -2.5FTP升级- 4 -2.6个性化对比- 5 -2.7功能点测试- 6 -2.8院方操作人员测试- 7 -2.9重大修改培训- 7 -2.10接口测试- 7 -2.11每周问题汇总- 7 -3正式升级前准备- 8 -3.1最新安装包、特殊部件准备- 8 -3.2升级PC机、网络、电源环境准备- 8 -3.3升级问题汇总及脚本整理- 9 -3.4升级方案整理签字- 9 -3.5升级确认书整理签字- 9 -3.6预升级- 9 -4正式升级- 10 -4.1中联及院方人员工作分配- 10 -4.2
3、科室钥匙收集及全院通知- 10 -4.3数据备份- 10 -4.4门诊诊室等相关站点FTP部件升级- 11 -4.5正式升级操作- 11 -4.6站点自动升级- 16 -5正式升级后- 17 -5.1门急诊收费室、挂号室、入出院处、药房等科室重点巡视- 17 -5.2每日问题汇总- 17 -5.3升级总结- 17 -6小结- 18 -1 进场前1.1 目标版本确认在接收到医院的升级需求后，根据医院当前待实施的项目等因素来确认升级的目标版本。对于应用比较深、客户价值比较高的医院，在升级至低版本的SP版本时应该慎重考虑。因为低版本的SP版本往往还存在较多的BUG。1.2 升级团队成员确认项目进场前
4、，由部门经理指定本次升级团队的各个成员，以明确各自的职责。升级负责人：全面负责整个升级项目，与院方协调沟通升级事宜升级协助人：协助升级及测试工作对应服务经理：协助升级及测试工作、配合升级负责人与院方沟通DBA:全面负责升级期间数据库事宜程序备勤：负责升级期间BUG、需求处理1.3 数据库环境确认由升级负责人向院方确认，正式库的数据库环境。如服务器操作系统是LINUX还是WINDOWS，是否实施了RAC、DG，日常的备份方式是逻辑备份、数据泵还是RMAN，目前的数据量是多大，主库的硬件环境如何。1.4 模块接口使用情况确认与院方负责人确认目前医院正在使用的模块是哪些，以便于功能点测试工作的开展。
5、确认医院接口的使用情况，并登记到部件接口清单表中，明确接口名称、接口服务器ip地址，接口部件名称、接口类型、中联接口负责人及联系方式、接口方负责人及联系方式。只有在准确的知晓医院接口使用情况后，才能在项目进场后迅速的开展接口测试工作，并且下FTP自动升级时，才有处理ZLFILEUPGRADE表的依据。部件接口清单见图1。图1 部件接口清单1.5 测试服务器准备确认进场前与院方确认，测试服务器是否已经准备到位，硬件环境是否满足（针对数据量较大而测试库硬件性能较差的情况下，应该及时与院方协调更换测试服务器硬件），如：磁盘空间，CPU、内存、网络等。在测试服务器已经准备到位的情况下，可以提前远程恢复
6、数据，搭建测试库，针对数据量大并且实施了RAC的情况，应该将DG切换至MANT状态导出备份集，以免恢复后测试库出现ORA-00600错误。针对数据量较小的医院，备份和恢复的方式比较灵活，可以视实际情况而定。1.6 测试客户机准备确认进场前与院方确认，测试客户机是否准备到位，客户机只要求能正常运行ZLHIS程序即可，并且能连接测试库。要求每个升级团队的测试人员都应该有独立的测试客户机，最好与院方站点实际使用的操作系统相同，这样在测试期间就能提前发现部分与操作系统相关的问题。1.7 注册码申请 邮件申请待升级医院的注册码，以便测试升级后及时更换。1.8 梳理重大修改说明依据重大产品调整、专项产品说
7、明、升级说明、实际测试等来源，整理重大修改说明，明确来源、修改模块、修改内容、影响部门、重要程度。以便后续交予院方负责人，也便于后续升级培训工作的开展，根据医院实际使用的模块不同，重大修改说明的侧重点也不相同。重大修改说明见图2。图2 重大修改说明1.9 梳理BUG、需求列表从BH上汇总待升级医院的BUG及需求列表，如果进场前有相应升级版本的测试库的话，应该在测试库上验证BUG、需求是否在升级版本上解决，并填写验证人及验证情况。针对需求类问题，应该仔细查看原始需求的提出背景或者直接与需求提出人沟通，了解需求的详细轻内容。BUG及需求列表 见图3。图3 BUG及需求列表1.10 重大问题通告梳理
8、产品重大问题通告，梳理来源如下：https:/ 此链接，筛选对应版本的存在的重大问题，并注意处理方式和是否解决。如果存在需要手工调整或执行脚本的问题，务必在测试升级和正式升级后及时处理。1.11 待升级处理问题列表 为了让院方了解本次升级处理的问题，也便于测试期间的测试，应该从BH导出所有问题状态为待升级的问题。2 测试期2.1 项目启动会议在项目进场后，开展测试工作之前，应该开项目启动会议，并做好会议记录邮件发出。与会者包括：升级团队成员，信息科全体成员。具体情况视医院而定。会议要点：通报整个升级的详细计划和安排，明确需要院方配合的工作；通报升级团队成员，明确升级负责人；重大修改说明通报；目
9、前准备工作简单通报；确定升级期间每周汇总问题机制，指定院方负责人。项目启动会议能让院方了解升级的计划安排，有助与升级期间医院配合我们升级工作的开展；其次明确了升级团队各成员的职责，让信息科的成员与升级团队成员之间很好的配合。2.2 测试服务器搭建利用近期的备份数据，搭建测试服务器。注意调整数据库参数（PGA、SGA、LOG BUFFER等）来对数据库进行优化；在恢复完成之后，应该做一次完整的表分析，以确保测试升级的顺利进行，并安装好原始版本的HIS程序，完成基本的流程测试，确保测试库的正常。对于使用新版电子病历、新版LIS等新产品，并且独立安装时，也应该同步搭建对应系统的测试库，并确保测试库的
10、正常使用。2.3 测试客户机及环境准备应保障每个测试人员均有独立的测试PC机，对于测试PC级需要满足以下条件：1）正常运行HIS程序；2）最好是与医院站点使用的多数操作系统版本相同（部分程序问题只存在特定的操作系统版本上）3）身份证读卡器、语音报价器、就诊卡读卡器（含就诊卡）等外设应尽量配备 2.4 测试升级利用搭建好的测试库进行测试升级操作。测试升级前请尽量确保电源及网络环境的稳定性。可以考虑采用笔记本来升级或者接机房的ups来供电。以避免不确定因素导致的升级异常中断。测试升级期间需要注意：1）完全模拟正式升级时的操作，先进行预升级，然后正常升级；2）注意记录升级时间，及时处理升级期间的报错
11、；3）升级期间的的报错，应仔细检查后处理并详细记录报错提示、报错SQL、处理方式、处理脚本。以便于正式升级时迅速的解决问题；4）升级完成后注意执行总公司的特殊sp脚本，编译无效对象、更换注册码等操作；5）测试升级完成后，应该及时整理计算升级耗时，连同升级日志、问题处理记录一并邮件发出，主送升级负责人及部门经理，抄送升级团队成员。测试升级次数视实际情况而定，一般情况下测试升级2次。2.5 FTP升级测试升级完成后应及时替换总公司FTP上升级版本所有的特殊部件，并处理zlfileupgrade表，删除部件记录（如ZLLISDEV等），新增部件记录（如：医保部件、银医卡部件、zlplugin部件等）
12、，注意检查检查存放路径、文件类型、是否注册等字段是否正确。确认zlfileupgrade表正确无误，部件替换完成之后，进入管理工具进行FTP收集（收集所有），将部件收集并上传至升级FTP。测试客户机应该安装医院当前版本的HIS程序，然后通过自动升级程序还升级。（这样可以发现FTP升级存在的问题）如果医院没有备用FTP的情况下，应该在测试期间就搭建好FTP，FTP数量视医院的站点数量，网络划分而定。详细的FTP搭建方法这里就不一一赘述了。FTP升级后常见的问题： 1）非ZLHIS用户登陆，自动升级进度条完成后，又回到登陆界面。处理方式：利用跟踪工具跟踪，会发现报错：表或试图不存在，在PL/SQL
13、授予相应即可 2）在登录导航台时，输入完用户名和密码后导航台自动消失 处理方式：将客服端升级程序（zlHisCrust）复制到APPSOFT 目录下即可。这里只简单的举例，如果需要详细了解，可以参考何懿写的Zlhis 客户端自动升级原理和部分问题分享一文。2.6 个性化对比首先利用管理工具自带的过程管理工具或者其他文本对比工具找出个性化修改的过程，然后逐个检查个性化修改内容，并将个性化调整至测试库。关于管理工具的自定义过程管理工具，需要注意，在进行变动过程收集之前，应该对本地安装脚本进行处理（类似于32版本之前升级的调整），否则会导致收集的时候提示系统版本号不符，即：以32.40版本为例，在升
14、级脚本目录新建10.32.0文件，并将32.40sp版本的升级脚本复制至文件夹内，复制其他升级脚本文件夹内的配置文件至此目录，修改系统版本号为32.40，并且将应用脚本的版本号修改为32.40。管理工具过程管理见图4。图4 管理工具自定义过程管理 自定义过程管理工具可以用正式库登陆，选择当前数据库，来对比医院在用版本与标准过程的差异；也可以用测试库登陆，然后选择其他数据库，配置正式库的数据连接来对比。其原理都是拿医院在用的数据库中的过程与安装脚本中的过程进行对比，找出有差异的过程。在完成个性化对比后，若测试无误，则将个性化调整的所有过程汇总至一个脚本，待正式升级时使用。2.7 功能点测试功能点测试即按检查点报告，逐步完成测试检查点，检查点报告目前还不是很完善，所以部分流程可能没有涉及，所以在测试的时候，应该尽可能的考虑医院操作人员实际使用上的问题，如果院方有条件的话，可以由信息科成员参与功能测试，尽可能发现程序上的问题。在每次升级的过程中，应该将检查点报告并整理归档。功能点测试完成后，需要将检查点报告邮件发出归档。测试点报告中，涉及票据、执行单等问题，应该用打印机实际打印出来，交财务科、护理部等相关部门确认。测试发现问题后，仔细验证后，及时记录并确认处理方式，如果需要修改程序，那么按正常的Bug处理流程登记BH，在研发接收后及时申请特殊部件。
