记一次事故分析

绝地灬酷狼 2022-05-14 04:37 256阅读 0赞

1.  事故业务  
    通过Web项目将计费明细数据发送至EBS(2.7亿)
2.  事故时间  
    事故产生时间: 2018-8-16 22：54：00  
    事故发现时间: 2018-8-17 8：35：00  
    事故结束时间: 2018-8-17 9：15：00
3.  事故起因  
    在通过web项目向EBS发送项目计费明细数据时，数据发送的速度非常慢，速度大致为2000/s,这样2.7亿数据需要37.个小时，不能够及时响应。于是想知道程序中哪个位置成为了速度的瓶颈，我的做法是增加日志，希望通过日志能够看到一些蛛丝马迹，没想到在添加日志的过程中，由于自己的粗心大意将一行业务代码不小心删除了，而那行代码正是给一条更新（update）的SQL 的where语句赋值的。  
    ![这里写图片描述][70]  
    由于where条件使用了Mybatis的标签，当参数为空时相当于没有where条件，结果你懂得····
4.  事故影响  
    由于是全表更新，非常耗费数据库的性能，导致数据库变得特别慢，当时项目正在给业务出数，同事希望用晚上的时间就能把数跑完，于是下班之前上传跑数任务，点击执行，正常的话第二天早上就能看到计费结果了，然而第二天早晨迎接他的不是计费结果而是dba的报警（计费项目因数据落库太慢，超时结束）。这样不但耽误了计费时间，给业务留下了不好的印象。也耽误了同事的工作时间。好在同事对自己的包容，帮助我一起分析问题原因（当时还不知道是什么原因），这让我感受到了团队力量的强大。
5.  事故分析  
    当我在添加完那几条日志时，我完全没有意识到会造成如此严重的问题，潜意识的想法是“只是增加了几条日志，能有什么影响“，于是匆匆上线，打开logbook，发现前几条日志都正常出来了，只是最后一条统计时间的日志，出来的很缓慢，但一看到日志全出来了，就以为程序是没有问题的，至于为什么这么慢却没有深思，毕竟这么晚了，也想快点回家。于是关上电脑，回家。结果就是第二天早晨的DBA报警，发现有慢sql在执行，根据sql定位到问题原因。而自己却迟迟不敢相信，事情的起因竟是自己加了几条日志。此时心里的滋味真是······
6.  事故预防  
    1) 修改任何代码都要认真仔细，反复检查两次，不能盲目乐观。  
    2) 方法要有对应的单元测试，每次修改完成之后都要执行一下，检查结果与自己的预期是否相符。  
    3) Mybatis 更新语句不要使用标签。  
    4) 代码判断update 语句影响条数，不符合就执行相应操作。  
    5) 线上观察logbook日志时，如果与自己的期望不符，一定要深入追踪，再次梳理下代码。  
    6) 有耐心，不急躁。

[70]: /images/20220514/c3e0cde7f5eb48fa9a6b044c28f1c48c.png