记一次事故分析

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语句赋值的。
   
   由于where条件使用了Mybatis的标签，当参数为空时相当于没有where条件，结果你懂得····

4. 事故影响
   由于是全表更新，非常耗费数据库的性能，导致数据库变得特别慢，当时项目正在给业务出数，同事希望用晚上的时间就能把数跑完，于是下班之前上传跑数任务，点击执行，正常的话第二天早上就能看到计费结果了，然而第二天早晨迎接他的不是计费结果而是dba的报警（计费项目因数据落库太慢，超时结束）。这样不但耽误了计费时间，给业务留下了不好的印象。也耽误了同事的工作时间。好在同事对自己的包容，帮助我一起分析问题原因（当时还不知道是什么原因），这让我感受到了团队力量的强大。

5. 事故分析
   当我在添加完那几条日志时，我完全没有意识到会造成如此严重的问题，潜意识的想法是“只是增加了几条日志，能有什么影响“，于是匆匆上线，打开logbook，发现前几条日志都正常出来了，只是最后一条统计时间的日志，出来的很缓慢，但一看到日志全出来了，就以为程序是没有问题的，至于为什么这么慢却没有深思，毕竟这么晚了，也想快点回家。于是关上电脑，回家。结果就是第二天早晨的DBA报警，发现有慢sql在执行，根据sql定位到问题原因。而自己却迟迟不敢相信，事情的起因竟是自己加了几条日志。此时心里的滋味真是······
6. 事故预防
   1) 修改任何代码都要认真仔细，反复检查两次，不能盲目乐观。
   2) 方法要有对应的单元测试，每次修改完成之后都要执行一下，检查结果与自己的预期是否相符。
   3) Mybatis 更新语句不要使用标签。
   4) 代码判断update 语句影响条数，不符合就执行相应操作。
   5) 线上观察logbook日志时，如果与自己的期望不符，一定要深入追踪，再次梳理下代码。
   6) 有耐心，不急躁。