自动化 | 如何快速排查生产客诉问题

日志，日记的一种，有工作日志，教学日志，班组日志等等，而我们系统和软件也会记录操作过程并写入文档生成很多日志文件，今天要分享的内容就与日志有关。

故事从前两天领导的一封邮件谈起，由一个客诉事件单展开。一个客户某天下午18点赎回一款基金产品，第二天16点看到产品赎回未成功，就继续赎回，我们的直销app就提示份额不足不能赎回，客户疑问，这啥情况还不能赎回?那就撤单！到在途交易记录里去看昨天的申请还居然也无法撤单!投诉吧，于是就找到了我们客服，客服登记后到业务和我们科技部门来排查了。（一般的生产问题事件单的处理流程也就如此了）

针对这个问题单，查了直销后台该客户的交易记录后，确实如其所述，在正式分析问题之前科普一个基金交易的概念，有投资过基金产品的朋友应该都知道有个T日的概念，从上一工作日的15点到当天工作日的15点为一个T，也就是说15点相当于我们自然日的凌晨24点，过了就是下一天喽，其中工作日的概念也要注意，比如从周五的15点到下周一的15点虽然间隔了两个假日但也为一个T日。

回到前面的事件单，由于客户是前一天15点后赎回发起的，所以相当于T日申请的赎回，对应的赎回份额会成为冻结状态而不能重复赎回，而撤单在也是T日内交易可操作，该客户是T日15点后操作的故也不能撤单，所以可以判断以上两个问题属于正常交易控制范围。

从业务逻辑分析很简单，到这该客诉问题也算是解决了，然而此时正在深交所开技术大会（主题：科技引领，迈向数字化新时代）的某领导(分管客服、电商和科技)可能受那里浓重科技氛围影响，给我们发了一个总结型句子: 真正找问题还是先从log分析入手啊。顺便捎带了下面一张PPT。

虽然这次问题是比较明显的业务逻辑问题，跟客户讲清楚也就可以了，但是大部分情况下的问题确实还是需要开发同事配合查日志来分析定位的，在上一篇文章（大数据 | 打鱼，你是用鱼网还是鱼竿呢？）中就有提到如何快速检索关键日志，但是如果将常规性问题或者常见的系统异常提取出来并做到自动监控，一旦触发就告警会就可以及时补救或者提前预防，所以还是基于ELK，我们引入了elastalert，这是一个开源的告警模块，官网简介如下:

照旧安装配置网上资料满天飞这里就不介绍了，简单讲就是一个用python开发的专门给elasticsearch用的告警工具，部署好后，配置某个重点客户，如果登录了就邮件通知我们关注，效果如下

当然还可以做很多事，比如恶意攻击事件的监控，系统异常错误码的监控，营销数据的监控等等，由于行业数据敏感性质就不补充相关截图了，不过工具永远是辅助和提高处理问题的效率，而工具之外的问题分析和应急处理的响应能力才是最核心的，不能陷入工具而被绑架了 ，不然各种监控报警系统做得再好也是徒增邮箱的收件量罢了。

综上，日志如果在团队中好好利用起来不仅可以方便技术人员的问题分析，还可以作为提供安全监管的数据素材，更可以作为大数据背景下业务人员针对客户画像分析参考依据，当可重复的事情规范流程化后，工具的价值也会得到更大的彰显!

附：

货币基金：T+2日至T+3日到账

股票基金：T+4日到账

债券基金：T+4日到账

QDII基金：T+9日到账

参考：

• 百度百科:日志

• elk告警模块

• elastalert官网