作为程序员，谁还没写过几个BUG。但是BUG导致的后果差千差万别，有些可以忽略；有些却是灾难；有些一笑而过；有些哭爹喊娘，有些没被别人发现就偷偷处理了。
逻辑上的BUG很难避免，除非把所有场景都考虑清楚，但是很难。BUG今天没出现，运行一天，一个月，甚至好几年都不出现，突然就爆发了。
有些BUG就是没考虑周全导致的，但是有些BUG是太大意造成的。在做运维的几年里，下面几个BUG印象深刻，大部分是由于疏忽大意造成的，打个FLAG ，大家共勉。
BUG1：逻辑不严谨，导致死循环，给20几个用户下发400多条短信。
导致原因：当用户打热线电话10086的时候，系统会自动根据手机号码下发一条短信，和查询话费相关，一个不小心，写了一个死循环。
导致后果： 给当时拨打的20多个用户下发了大概400条短信。幸好当时有短信相关同事在，把将要下发的短信的删除了，否则短信就是几万条，手机内存直接爆了。
总结：写循环一定要注意。
BUG2：太疏忽，变量没有复赋值，导致台账信息没有登记，补数据花了三月时间，部分数据永远丢失。
导致原因：在帮其他的同时查询投诉，翻代码，发现有个BUG，顺便随手修复了，最后发现是if 判断 的 变量没有赋值 导致 条件无效，结果第二天的下午才发现有问题。
导致后果：
1、涉及台账记录8000条，数据没有登记
2、补数据 花了3个月时间。
3、部分数据永远丢失，后来一直找我要，尴尬
4、涉及金额130万左右（指的是台账流水，不是实际的经济损失）
5、营业员账目对不上，电话被打爆，手动补台表
6、部分业务办理无效
这个BUG虽然后期做了补救，但是是惨不忍睹的，所以说别人的BUG不要随意改，特别是未经测试的。
BUG3：忘了一个调试alert没有删，导致系统连续弹出日志信息，给业务员造成困扰。
导致原因：调试alert没有删 。开发功能的时候，业务逻辑没啥问题，直接上线了，第二天话务员反馈页面报错，要点十几下才能提交。
导致后果：话务员 一直点，造成困扰，虽然说没太大影响，但是非常尴尬。
总结：调试信息要还原。
BUG4：一个文件没有提交，导致所有关键业务中断40多分钟。
导致原因：由于代码中的SQL脚本是，通过文件的形式提交的，发布的时候忘了提交，而且是最底层，基本上所有业务都会用到这个脚本，编译时又不报错。
导致后果：整个移动业务挂了30多分钟，各大领导电话打爆了。
总结：防不胜防，上线时版本或文件一定检查仔细。
BUG5：建索引导致系统挂死
导致原因：需要统计一张表数据，但是太慢，随手添加了一个索引，由于建索引需要锁表。
导致后果：导致10086客服热线瘫痪办小时左右，最后杀了会话才恢复
总结：不熟悉的操作不要随便做，经验换个环境不适用，以前操作的都是小表，建一下索引，几秒钟，但数据量超过亿的时候的就嗝屁了。
BUG6：测试代码上传到生产导致查询异常
导致原因：为了方便开发测试，写了一段测试代码，没想帮别人的合版本的时候，测试代码更新到上生产了。
导致后果：查询异常，和领导一起看提交记录，SVN展示是我提交的，尴尬到不行了。
总结：测试代码一定要管控好，测试完了及时下线
BUG7：打印日志信息导致业务异常
导致原因：查询投诉的时候 打印日志 有个变量 String 类型 为null，我又 toString() 了一下
导致后果：业务报错，考核扣分
总结：防不胜防 不要随便toSting()
愿你我的代码从此无bug，加油！
