刚刚完成的一次实施支持,可算是给自己上了宝贵的一课,让自己明白在处理对产品的修改问题上必须严格按照操作流程,否则后果可能会非常严重!
事情经过简述如下:
我们开发的一个升级工具,被实施人员拿到一个客户处进行产品升级操作,由于客户数据中出现了一种特殊的数据,导致升级工具在备份系统数据的时候,发生了异常,并被系统强行关闭,因为数据量比较大,反复重复3次,用了将近3个小时的时间,已经确认是工具bug无疑。
于是,我们进行了远程的调试工作,因为没有办法直接链接到客户数据库,所以,只能通过将日志写入工具程序,并通过替换的方式来逐步排查问题,这一步进展还算顺利,很容易排查到了问题的原因,是因为在处理一个文件名超长的文件的时候,导致工具因异常而关闭,于是,我便进行修改处理。
因为在排查阶段,我们是通过远程桌面的方式进行的,所以,我修改一个版本,即发送给对方进行替换操作,最后的一个版本,已经将导致异常的问题进行了处理,现场也不会出现异常关闭的错误了,于是实施人员就用这个版本进行了升级……
或许,如果不是自己的一个小错误,这件事情就这么了结了……
但是,似乎是要对自己的一个教训吧,自己在处理bug问题的时候犯了一个小错误,当升级完毕,客户打电话过来讲述了问题的严重性后,我才意识到,自己没有按照公司的正常流程进行实施支持,因为最终版本并没有通过测试,就直接提供给了实施人员,这是一件很有风险的事情……
还好,这次“事故”只是让自己加班一天和实施人员进行返工,否则……有的时候,商务上的事情真的是没有回旋余地的。
希望大家能够以此为戒,不要我的重蹈覆辙……
事情经过简述如下:
我们开发的一个升级工具,被实施人员拿到一个客户处进行产品升级操作,由于客户数据中出现了一种特殊的数据,导致升级工具在备份系统数据的时候,发生了异常,并被系统强行关闭,因为数据量比较大,反复重复3次,用了将近3个小时的时间,已经确认是工具bug无疑。
于是,我们进行了远程的调试工作,因为没有办法直接链接到客户数据库,所以,只能通过将日志写入工具程序,并通过替换的方式来逐步排查问题,这一步进展还算顺利,很容易排查到了问题的原因,是因为在处理一个文件名超长的文件的时候,导致工具因异常而关闭,于是,我便进行修改处理。
因为在排查阶段,我们是通过远程桌面的方式进行的,所以,我修改一个版本,即发送给对方进行替换操作,最后的一个版本,已经将导致异常的问题进行了处理,现场也不会出现异常关闭的错误了,于是实施人员就用这个版本进行了升级……
或许,如果不是自己的一个小错误,这件事情就这么了结了……
但是,似乎是要对自己的一个教训吧,自己在处理bug问题的时候犯了一个小错误,当升级完毕,客户打电话过来讲述了问题的严重性后,我才意识到,自己没有按照公司的正常流程进行实施支持,因为最终版本并没有通过测试,就直接提供给了实施人员,这是一件很有风险的事情……
还好,这次“事故”只是让自己加班一天和实施人员进行返工,否则……有的时候,商务上的事情真的是没有回旋余地的。
希望大家能够以此为戒,不要我的重蹈覆辙……