中台迁移故障盘回顾

— 1 —

背景

为了业务的合规，3个产品决定在本月25号凌晨，迎来将近一个月中台迁移交割的日子，一切都是非常顺利的进行。 原定计划4:00--7:00交割完成结束,提前完成交割任务了。大家开心吃的早饭做等业务高峰过去回家睡觉，但是随着业务的白天业务达到了小高潮。业务突然故障了,9:15-10:00 业务持续time out,其中从cat监控中看 xx-apiserver 请求错误一致达到了99%，大家都非常紧张这个原因到底是什么原因。整个人都不好了，而旁边的跟xx-apiserver 调用关系一模一样的xxx-integrate 只是偶尔time out出错，排查思路毫无头绪。 做为本次PM的我整个都不好了。

— 2 —

当天排查思路

研发侧排查

1、采用了限流服务等方式 觉得线上代码和X一模一样的方式 @李君 @刘君

2、抓JAVA 堆栈的方式 一轮又轮的进行分析 。发现明显变化连接数据库卡住 ，只是此时只是觉得请求mycat数据库 线程池卡住。@李君

3、以为是mycat 这边的问题，然后进行对这边连接方式多重转换 。变数据库实例 要求提供新物理mycat实例配置 （用k8s提供配置），但是无所收获 故障持续进行 @研发

运维侧

重启应用服务 @A君

添加pod 添加节点 @王君 @张君

修改数据库连接方式 @高君

提供新的数据库实例名 @高君

让大家检查apollo配置 @A君 研发反馈没有问题

有人也提出让抓网络看看 我也没有听到，A君也没有坚持（要是那时候发现 我们都问题早就解决了 可惜后面方向错了）

测试侧

测试的时候有时候可以 有时候不行，因为业务在国外有点不稳定以为是正常的

得出结论公司可以 印度不行

— 3 —

第一阶段解决

（过程中确认影响面）

大家从凌晨3点钟从家出门，到上午09:15故障出现一直在排查这个问题点。我觉得时间上周期上已经非常长了 都是同一波同学，（持续12个小时的战斗 看大家精神面貌都比较非常劳累）。我有点想放弃这个应用服务， 跟业务同学确认到底影响面 3个产品中哪个APP受影响 了 大家的影响面是否主流程， 得知影响面只有一个马甲包app 想跟当事的这个产品技术产品 B君 C君来确认业务量级及影响面， 确认每日的PV UV 确认主流程的影响面 ，决定是否可以在今天暂时放弃这个业务，明天在来修复 ，最终得出来一个特别不好的消息 （过程中确认影响面）

新增有x 万多 日活差不多有几百万

（一首凉凉送给整个迁移项目组）

马上放弃 有放弃业务的想法 我觉得的基本上是凉凉了，然后重新回过头来分析。在 B君 C君建议下，我们重新复了一次盘 发现整个迁移流程应该是没有问题。但是业务故障还是没有头绪，此时@李君 提出了 用老的连接方式直接连接数据库 而不是通过dubbo调用的方法（主要问题是数据库） 看看是否正常。重新部署 业务居然终于正常了

。这个时间点上确认已经16：30分钟。业务终于稳定，大家终于ok 。但究其原因还是没有发现问题点，因此时业务已经正常运行稳定 .我让大家提前回家。好好休息一下是那么不容易的一件事。

过程中也让印度同学验证测试的说法 ，是不是真的公司正常 而 印度区域不正常这个现象。

— 4 —

最终解决

（故障问题最终定位原因之一）

为了一杯奶茶的故事继续抒写。运维侧反馈是研发的问题，研发同学反馈是运维的问题。迟迟得不出最终的答案 或者说大家满意的结论，测试环境弄起来之后 打算复盘跟进。 因为排查的过程中之前定义为数据库连接拿不到，往网络方向原因，问题比较大 我也加入这个分析原因战斗（想喝奶茶） 进行了wireshark抓包 然后进行网络抓包分析。一抓不知道一看吓一跳

抓包明显发现 mysql error 1045 数据库账号密码错误。经@dba 研发同学 分析发现，apollo配置是配置数据库账号错误了。。但是历史问题这个应用服务连接apollo的加密方式跟其他业务模式不一样。。调整数据库账号密码业务正常！！！

痛哭流涕啊 真的，业务上用的是无加密账号密码 而配置的时候用的是有加密的账号，数据库本身就连接不上。密码密钥本身没有错 .老业务的连接方式有问题

总结我们核心错误点

dba在aws采用了二套用户体系 方便数据库更好管理，但是部分研发同学不知情

apollo配置上明显没有做check list

测试同学测试的时候 大概率本地有缓存 没有成功清理包 而是原有的基础上测试，所以请求一直正常

运维侧和护航的同学没有明显看Mysql 访问错误日志 只是从在监控图发现数据库资源负载正常 ，其实访问日志里面有大量access denied。

人员发布没有做checklist，而测试同学测的时候忘记了缓存，用了一个老包在测试

业务上最简单的数据库连接错误都没有

没有一个人要为这个事情上负责，要负责的是我们在技术上要走的路。如果真的要负责，做我迁移负责的我没有很好的在把流程点接受检讨 希望下一次自己能做的更加好

至于为什么有时候可以有时候不行，大概率是有缓存，测试同学用了老手机在测试，没有重新包吧，（建议下次删包重新测试 清除一下缓存）

至于@李君 改了数据库连接方式可以启动，业务正常是因为数据连接方式不一样 传输方式不一致所以业务正常了

至于为什么说没有回退，回退计划呢：其实是有的 只是因为这个在测试过程没有问题 出故障的时候已经业务高峰了 回退的成本非常大 所以没有尝试回退

最简单的应用连接数据库错误没有打印出来，这个我也不知道

— 5 —

最后的最后

技术的真相往往在最后一刻发现 我们离大神之路还很远很远，下一波的迁移务必要做好 上面的核心点，从晚上熬夜人员分布 和 排查的人员分布 都是同一波人。过程中感谢兄弟们支持 没有大家不可能后续那么顺利

还有在其他国家的同步帮忙排查。整体是多么辛酸的 那天都快放弃了 但是我们坚持了下来。今天很残酷，明天更残酷，后天会很美好，但绝大多数人都死在明天晚上，却见不到后天的太阳，所以我们干什么都要坚持！因为我们坚持下来 所以问题解决了

谢谢大家！！！

这边文章让我职场陷入一个比较尴尬的境地 但是对我来说问心无愧，以自己良好的心态迎接新的工作和机会。人生处处不相逢！！！表扬一下自己写的真好