一个生产问题引发的思考

前言

最近碰到一个生产问题，整个处理过程让我不禁想起几年前碰到的一个类似情景，但是结果却完全不一样。两次问题说大不大，说小不小。这次由于我们处理及时，大事化小小事化了而已，然而几年前的那次事件，却由于多方原因，闹得挺大，惊动了某会。由此引发的一些思考和总结吧。

问题回顾

客服人员反馈有客户在app上做交易时，获取短信验证码比以往收到的慢，以往倒计时60秒开始后4到5秒就可以收到，现在要到40秒左右甚至60秒之后才能收到短信。

排查思路

生产出现这种性能问题要求运维人员首先就要有个可能的原因分析，由于以前正常，近期突然出现的故障，原因可以从以下方面着手

1.是否存在网络延迟

2.是否近期有变更

3.发送端延迟还是接收端延迟

4.查看发送记录数据是否未建立索引

前三点如果查找问题原因，耗时一般比较长，因为网络问题一般比较难追踪，而且如果近期有变更的还涉及开发人员的排查代码逻辑，延迟源头和网络问题差不多，而生产问题的第一要务是要快速止血。当然也要相关团队引起足够重视，否则会耽误救命的时间。

问题分析

所以我们团队首先从数据入手，既然是发短信验证码慢，那么就找到验证码的记录表，找到这个客户的数据，直接通过PLSQL查询都很慢，而且是有索引的，一看表的数据量快上亿了，所以很明显是量变引起了质变，再仔细分析里面数据发现有大量的异常数据，此块后期找开发人员去排查和优化此处不提。

问题解决

找到问题原因，并经评估此表仅记录发送结果数据，重要性不是很高，所以在备份完数据后，直接删除表数据，就解决了客诉问题。清数据有个小细节这里用的是truncate而不是delete，注意要降低表的水位。

整个过程从得知问题到生产问题解决不到5分钟。然而几年前的那次问题止血用了30分钟，并且惊动了监管，现在看来主要原因还是处理问题的环节太多导致。

当年的问题是app首页访问慢，原因是某个数据关联查询性能低引起页面加载不出来，也是量变引起质变的一个案例，最后也是通过清空一个表数据来止血。从运维发现问题到生产止血，花了大量的时间去找开发确认问题原因，然而这块的代码逻辑是老早就上生产的程序，而且当年的开发人员都已经不在团队里了，进一步增加了排查原因的耗时。而这次我们把分析问题的根本原因退后，而不是止血的时候去分析排查，减少了排查环节，从而为生产止血的节省了时间。

就像生活中有的时候小朋友出血了第一步就是要想办法去止血，事后家长再去问医生或者小朋友为什么出血或者病因，才是最好的求医问道的方法。

作为金融系统的稳定是每一个金融企业的重中之重，否则不是被银监会约谈就是被证监会发函。咱们抛开流程管理和技术不谈，遇到生产问题，一定要先止血，而且一定要快！而问题原因应该都是事后去分析了，所以生产问题运维人员应该首当其冲，因为他们掌握生产运行程序的一手资源，日志、数据还有awr报告等，并且应该具备分析和处理的能力，而不是作为开发人员的取数工具。而开发人员在事后问题分析要考虑优化策略，无外乎数据的增删改查，怎么才能做到更优？

总而言之，一个团队要有向心力，不能开发碰到问题就是让运维取日志，要对自己代码逻辑做到心中有数，运维人员碰到问题就是让开发查代码也不行，要了解系统架构和表结构，这样碰到问题才能做的有的放矢，心中不慌！