背景

由于公司组织架构调整，我接手了一个原来由别的团队负责的业务系统。该系统主要业务职责是把公司的资源分销给各个渠道售卖，叫做分销系统。
系统要交接，但HC还没到位；只能自己在有空的时候理逻辑。断断续续已经两周了，这天早上醒来，突然收到接口响应变慢的报警。
其中一个分销商，获取价格接口，响应超慢。抓紧时间赶到公司，组内一起在熟悉这块业务的同学，今年帮他提命了晋升，下午要晋升答辨，也没安排TA排查。

自己查日志发现以下线索

• 集群中只有2台机器，响应变慢。进一步查看应用NG配置，原来该分销商只会路由到这两台机器
• 机器上日志中有Redis中查不到信息的报错
• 也有数据库链接被关闭的报错

没有更多线索，报警电话，一个接一个的打过来。还要安排今天入职的两个同学。
差不多过去了2个小时，问题没有缓解，午饭时间也到了。也顾不上传统，没时间带新同学欢迎餐。开始相原来的团队成员求助，希望可以参与排查，但赶上了饭点，人家去吃饭了。
陆续的排查，依然没有头绪。时间来到了13点多。
陆续有商务，产品找过来，发现订单报表中该渠道的订单占比跌了2个点。
意识到，遗漏了这么一个重要的点，我竟然没去关注订单。
得不到帮助，并意识到了问题的严重性，于是马上当做故障处理。

申报故障

拉了NOC，QA，原团队成员及其Leader的企业微信群，并申报故障。

• 14：27原团队研发主力，很快定位到，慢sql+mq变更量大了，导致拿不到数据库连接，并拉了DBA进行处理
• 14：30 DBA定位到Insert阻塞,并Kill了请求
• 14：31 监控显示接口响应恢复

后续

• DBA协助排查到了慢sql，并推荐缩小查询范围
• 查询范围涉及到另外一个分销渠道，对方也是人员流失，换了一批新人，又是一轮解释沟通
• 系统接口没有做限流，需求做整体的限流方案
• 没有流量监控，添加流量监控

总结

有问题，不要慌，理清核心指标是否受影响。
接手了别人的系统，坑就得填。
请求协助很重要。
人多力量大。