大家好，我是阿粉。虽然这么多年在工作中经历了风风雨雨，但每次上线发布一个版本，都是一场硬仗。最近出一个版本，不小心写了一个bug，差点造成生产事故。还好云威老大及时发现了。背景是这样的。上周的一天早上，阿芬兴高采烈地去上班。到了座位上，还没来得及吃早饭，就收到了运维老大发来的一条微信，说服务Anginx日志暴增。从平时每天133M到29G，突然想起前一天刚出版本，一下子连早餐都吃不上了，赶紧拿着电脑跑到运维那边排查问题问题。首先找到服务A对应的nginx日志，通过命令tail-fxxx.log查看日志数据。发现日志中输出最多的是调用获取配置信息的接口。这个接口是一个很简单的接口，就是把数据库的数据加载到缓存中，然后对外提供接口访问。本身没有业务逻辑。确认接口后，通过nginx日志可以看到，请求都是来自一个核心服务B。至此，基本可以断定是服务B的逻辑有问题，指向的方向问题已经确定。定位到服务B中调用接口的地方，一共有两个地方。每五分钟调用一次用于内存缓存。这一块的逻辑一直都在，不会有问题；另一个地方是自定义的Prometheus指标集合。Prometheus将每15秒收集一次数据。仔细想想，问题一定出在这里。看了一下逻辑，这段代码是一个自定义的指标集合，用来在Grafana上采集相应的数据。恰好Prometheus在生产中每15秒拉取一次数据，生产环境中的数据量比较大。big，这段代码中调用接口的逻辑是写在循环中的，导致每15秒触发一次循环。每次循环数据量大，每次都调用接口，而服务B还是多实例Deployment，导致调用接口的次数激增，才导致了这个“血案”。问题定位了，解决方法也比较简单。接口的调用从循环体迁移到外部。对计划进行了一些更改。修改后合并代码，打tag，升级其中一台服务器观察。发布后，整个接口的调用量减少，观察一段时间后，全网关闭。复习后，我对这个问题做了复习。事故本身并没有导致业务异常，幸好发现的早，否则每天产生的如此大量的日志迟早会占用磁盘空间造成麻烦。深入审查后，发现接入Prometheus的自定义指标没有实际使用价值。这块的逻辑在很多版本中都有改动，但是没有最终版本。我不知道代码会在哪个版本中更改。提交它。这也说明我们的版本规划是有问题的。很多需求频繁的来回改动和插入，没有按照版本严格执行也是造成这个问题的重要原因。这里也提醒大家一定要严格按照版本迭代进行开发和发布。不然哪天踩到这样的坑就尴尬了。工作中难免出错，但有些错误可以犯，有些错误不能犯。每个程序员都会写出错误。写bug问题不大，能不能及时解决就很重要了。对于真正影响在线业务的bug，时间就是金钱，花的每一分钟都是每一分钟的钱。有的时候，一分钟钱花不了多少钱，有的时候，一分钟钱，就足以让一家公司倒闭了。所以我们每个程序员都应该对在线感到敬畏。
