关于一次线上应用异常的奇幻之旅

2017-05-26 01:02:10

    博主所在的公司 有一个多半年前的项目 后端研发人员已经离职 突然有一天一个平台需要用这个服务 鉴于之前的经验认为他们已经对接过 应该主要问题是程序bug 造成的  第一天洗洗排查下来 的确应用入口存在一个可能性的bug 经过反复测试 最总想到了折中的方案修复了 本以为万事大吉 没想到上线后 主平台没事 业务平台故障依旧 博主拿来业务平台 跟踪调试发现 有个解密字符串始终无法解密 怀疑是加密时 key 错误 跟业务平台细细交流后发现 的确是key的问题  然后业务平台修复上线  故障减缓 接着又发现 下的单子都变成同一个人的 经过解密身份code 得知 业务方将身份信息写死  此时博主倍感惆怅 我的天呢 代表身份的为何能被写死呢  这不是通用平台固定的方式吗  为啥会错呢  随之而来的是 创建订单异常 这个之前不是百分之百发生的事情  经过跟第三方和原研发(已离职)沟通 发现的确会存在第三方创建后 无法立即查询到订单  所以将关键程序延迟500毫秒在查询   测试 上线  发现故障缓解 基本不会出现  就在即将雀跃的时候 故障再次出现 下的单子异常  当多个人操作 或者操作频繁的时候 发现 订单里关键信息和本人下的单子 异常 细细研究所有流程发现 一个关键主键可能在多实例情况下 发生不同步或者重复 更改方案 再次上线 期待能够解决问题  好奇幻的旅行   


      经验教训

       不了解项目不要轻易下结论 一定要归根到底查询当时设计的所有关键节点

        不要过于经验化 一定要亲眼看到和排查对接环境和关键节点数据

        不要轻易使用非数据库主键的方法

你打算打赏多少钱呢?

打赏
(微信扫一扫)