软件技术实施人员处理数据问题

软件业务系统在升级切换上线的时候一个很重要的环节就是数据移植。数据移植人员往往在行业性软件业务系统上线升级的时候扮演着重要的角色，其重要性也不言而喻。一些大中公司往往还有专门的数据移植部门和专门的数据移植人员，也具有其一套标准的数据移植步骤和数据规范性检测办法。然而，在业务系统上线升级阶段以及上线后的维稳阶段都会不断的出现一些由于数据问题造成影响业务进行下去的情况。


                        01

根据以往的工作经验来看，造成这种原因的情况有以下几个方面:

第一,业务系统多年来历史数据遗留下来的数据问题。很多行业性业务系统自使用软件系统办公以来已经具有十多年的历史数据了，但是十多年来的历史数据中有些数据本身就是不规范的，多年沉积下来的历史遗留问题在新系统上线使用的时候得到了爆发体现。比如，在一些公积金业务系统中个人账号已经做了销户，但是个人账户余额却不为零。

第二,业务系统上线的时候数据移植人员由于技术能力不足或者由于疏忽造成的。很多数据移植人员由于系统上线计划紧迫，做数据移植并未对数据迁移与处理的全面和充分。这类数据可能对于一些主要业务不会造成大的问题，但是对于一些个性化业务往往是致命杀手。例如，在一些公积金业务系统中进行数据迁移的时候贷款职工历史还款记录中都是银行现金还款的到了新系统的还款明细表中却变成了公积金对冲的。

第三，新的业务系统由于程序存在重大的bug造成的数据问题。软件系统没有完美一说，总会或多或少的存在着若干问题，由于这种行业性业务系统bug也是无处不在的。程序的本质就是作用于数据，bug的体现要么就是阻碍了业务流程的进行，要么就是没有阻碍业务但是破坏了数据，让数据变得不规范。

第四，由于做业务的人员业务能力不足，对于业务不熟悉，做业务时不规范导致的数据问题。这种数据问题一般出现的概率较少，但是也是存在的。


                        02

作为一名合格的软件技术实施人员（有时候有的公司没有专门的数据移植人员，因此这里统称为软件技术实施人员），不可避免的会遇到上面四种不同原因造成的数据问题。这里针对每种原因造成的数据问题总结一些专门的应对方法，以及处理数据问题都必须要注意的事项。

对于第一种原因造成的数据，由于是历史性遗留问题，一定要妥善处理，处理得当可能会得到客户的表扬。万一处理不当，则会牵一发而动全身，出现更为重大的数据问题。如果这样的话那么得不偿失的。但是如果是一些基础性数据问题的话，那么我们可以根据行业性基础数据的规范处理就行。例如，这个人的人名不对，这个人的×××少了一位，如果是公积金数据的话这些大可根据住建部贯标数据规范GB的相关文件处理就行。

对于第二种原因造成的数据问题，往往是技术人员写的数据移植sql代码有漏洞。因此，我们我们首先需要去检查下历史数据移植脚本，这里重点强调下，历史数据移植脚本一定要保留下来作为资料备案，因为这样以后有问题了可以去查看相关脚本。这种问题一旦发现了应该马上进行书写数据库编程脚本进行数据纠正，防止更离谱的数据问题发生。处理这类问题要善于发现数据规律，要对数据很敏感，抓住数据的本质。

对于第三种原因造成的数据问题，如果由于bug造成了比较大的数据问题。首先应该防止错误数据错上加错，这时如果有必要的话可以和客户方进行说服沟通先停止掉业务；其次，应该马上组织数据人员对编写sql脚本对错误数据进行纠正处理，包括函数，视图，存储过程，触发器都有可能用到；第三，应该彻底测查造成数据问题的程序问题，从跟本上杜绝。尤其是一些与资金计算相关的字段，我们要格外注意。在下就曾经经历过由于数据移植造成的两个字段数据不对，造成职工个人账户余额不准确的重要数据问题。三个技术人员连续作战三天三夜才将问题解决。

对于第四种原因造成的数据问题，应该和客户业务部门进行合理沟通，明确责任。甲方做错了业务，我们乙方可以帮助他们处理，但是一定要说清楚这个不是我们软件系统造成的。这类问题一般比较好处理。总得来说，最难处理的数据问题是前三种。


                        03

另外，处理数据问题针对于任何行业的业务系统都要注意的几条事项在这里总结下，以供小伙伴学习下:

A.处理数据前一定要理清业务逻辑，理清业务流程。任何行业的业务系统都有其一套特定的行业业务，行业逻辑。业务就是甲方行业的工作知识。不要把业务离不开甲方行业工作，这样难免会闭门造成。教育系统，医疗系统，金融系统每个行业的系统业务逻辑都是不相同的。其实做这些系统往往能让我们了解另一个行业，透过这个行业去折射我们的生活。只有理清了业务逻辑和业务流程后处理数据，才不会出现处理了A表的数据没有处理B表的数据，处理了这个字段却漏了那个字段没有处理。

B.处理数据前一定要与客户沟通确认，甚至要有书面申请文本，书面签字确认。如果没有这些，乙方技术人员一般不要去随意修改数据，修改不好反而造成工作失误。

C.处理数据前一定要先数据备份，先备份，先备份，先备份，重要的事情说三遍。数据备份也要根据情况进行，如果重大数据问题处理，涉及到多个主要业务表，对于oracle的话一定要利用emdp/impdp进行逻辑备份；如果是中型数据问题，那么可以利用create table A_backup as select * from A;一般情况下也可以用导出sql或者导出excel的方式进行备份。

D.处理数据后一定要对数据和脚本备份，后备份，后备份，后备份，重要的事情说三遍。

如果数据技术工程师处理完数据后一定要对处理后的数据和处理数据的脚本进行后备份，便于如果有后续问题进行对比查看。

E.处理完数据后到业务系统中进行测试，确保业务系统能够按正常逻辑进行。

F.最后应该专门建立可以insert,update,delete数据的用户，专门建立只能select的用户，这样可以一定程度上防止数据管理误操作中带来的问题。


总之，在这个数据时代，软件系统数据问题非同小可，一定要谨慎又谨慎！