我需要一个程序员鼓励师

就像生产环境的报警一样，如果滥加报警，就会导致群里全是报警消息，有用的或者说需要人工重点关注的消息几乎没有，那这样的报警会让人麻痹，甚至起到的作用是负面的。一旦某一天出现真正需要关注的报警，可能会因为人已经被麻痹了，而忽略报警的情况。这就是的报警失去了意义。

这里面的道理就是，一件日常会发生的事，可能对我们自己来说平常不过，但可能对别人来说都很关键。
今天我就经历了这么一件事。

业务方A反馈搜索引擎同步服务出现消息堆积，想让我帮忙处理，消息堆积对我来说是个很平常很平常的事情，一般不会主动处理，有人反馈就帮忙看看。业务反馈想要一个快速解决堆积的方案，因为是多个业务方共用一个topic，导致互相影响，起初我查看了他们的应用数据，才8万+，很少，所以认为不是他们的数据流量过大引起的堆积问题，而是别的业务数据量太大影响的他们。因此我给出的方案是，帮他们切换到一个流量小的topic，业务同意了。我正常操作，操作完成后，还很谨慎的要求和业务方一起验证一下，验证通过后才关闭操作窗口。以为一切就这么结束了。
谁想，另一个业务部门B反馈他们的数据延迟了，但他们的数据变更并不多。我一想就知道了，是因为我前面操作的索引导致的。但此时，业务部门B也通知了运维，运维部因为上周刚刚发生了P0事故的原因，都很谨慎，赶紧找到我这边，想我了解情况，经过我们大家一合计，为了避免影响这个无辜的业务部门B，让我这边把索引配置切回去。过了一会，业务方恢B复正常使用了。但业务方A的堆积还在，他不罢休，问原因。我就开始查日志，查日志发现，他们的表有大量的插入和删除操作，截图给业务看，业务不信。。。对我说，我们这边业务都停了，怎么还有会有消息！！！
我有日志啊，你不信！！！幸好运维大哥们都在，查数据库监控，查到了他们插入和删除的sql，导出，发送，业务排查问题。

后来经过排查果然是他们自己的问题，他们一个大部门下的接口调用，出现了环，在一种条件下会有死循环。。。

其实对我来说处理堆积真的是很常见的操作，业务方找我处理，我就无脑操作，谁知道今天怎么就出事了。但如果我多问一句，你们的数据变更多吗，如果我多看一下ES写入监控，你们的数据写入流量有点大啊，可能就会提前判断出业务A有问题了，可能就不会影响到业务B了。以后处理生产的事情，还是谨慎些好，年轻人要成长了!

今天处理这个事，中间还有很多波折，感觉还挺累的，一边要和业务解释，一边要和运维解释，一边要处理事故。我觉得我需要一个人支持一个，一个backup！！！

事后，还有给领导汇报，我的领导还不在，上周的事故复盘就不在，我一个人人孤苦伶仃的，贼难受。这次复盘估计也不会在，弱小的心灵没有安慰啊。

需要鼓励

加油吧!

今天很感谢运维同学，刚哥，还有中间件的大哥们