变更无小事——EZSonar微监控
大家好,我是华青融天吴伟平。在去年华青融天的用户会上,曾给大家分享过EZSonar的最佳实践,主要聚焦在实践场景的三个方面: 场景一:告警的持续优化,具体分为:可用性告警、高危事件告警、异常特征告警。 场景二:监控场景化,将经验场景固化在可视化仪表盘中、场景告警中。 场景三:良好的闭环迭代,发现异常事件,持续跟进直至解决;将异常事件总结为经验场景,推进监控场景的迭代更新。 在过去的几年,我和我的团队一直在用户现场帮助用户搭建EZSonar这套业务监控产品,我们也发现,我们的产品除了在日常监控中发挥重要作用之外,还有很多的应用场景。今天,我跟大家分享的就是——变更。1案例:某理财业务变更
上图是某行理财业务架构,这个业务大家应该都非常熟悉。它的交易流程是:客户首先从网银/手机银行购买理财产品,网银/手机银行将交易送给前置,前置作为交易路由将交易透传至理财应用,理财应用受理交易请求,记录交易流水。接着再到核心,核心记账,记录交易流水。
这是一个非常典型的应用架构有时,行方为了优化整体业务流程及服务质量,需要对系统业务进行变更。我们以某行服务器储存变更为例,由于规模相对较小,又是在凌晨进行,一般十多分钟即可完成。运维团队很快走完审批流程,并没有通知业务部门,也就是说变更期间办理渠道仍正常开放。
0:00,理财应用停机,准备变更。0:30,更换存储,开始执行后原本计划最多30分钟就能完成的任务,直到凌晨1点遇到了意外事件,显示变更失败。运维团队也很头疼,有时候为投产做了非常多准备,但实际上还是会发生一些奇葩的问题,弄得鸡飞狗跳。运维团队尝试解决变更中遇到的问题,整个恢复过程到早上8点才解决。到9点,业务部门接到投诉,很多用户埋怨没办法购买理财产品。2如何评估业务变更失败的影响?遭到客户投诉后,业务部门想了解变更失败对业务产生哪些影响,比如:业务部门关心的问题:
- 有多少笔交易受到了影响?
- 用户在办理什么业务时交易失败了?
- 具体影响了哪些用户?
查核心但交易未上送核心,核心无日志记录;查理财应用日志,但理财应用停机,交易未抵达应用,应用无日志记录;查前置透传交易,不记录日志;查网银/手机银行,同样不记录日志。运维团队想通过以上几种方式查询变更失败带来的业务影响,发现这些常规的手段均无法评估。 这时,运维团队有点方... 还好有EZSonar业务性能交易监控保障。
首先,可以在EZSonar中把这个理财业务系统调出来,由于EZSonar具有强大的微监控功能,可对理财业务这个细分渠道进行定向的细颗粒度监控。运维团队可以了解到当天实时有多少笔业务请求,当然也能看到从0:30到8:00这段时间内的业务请求总量,可精准评估业务损失,并且还可准确查看影响严重的理财产品排名。 此外,通过EZSonar微监控功能,还可调出这些失败业务的用户卡号,交给业务部门,以此制定应急预案,减少损失。
让我们假设一下,如果在业务变更时就引入EZSonar,我们重新看待这条时间线,这个故事可能就大不一样。
当凌晨1:00变更意外失败时,通过EZSonar业务监控,可以实时看到仍然有很多业务请求发生,可能运维团队就会立刻做出应急决策,回滚、恢复业务,最小化变更失败带来的影响。3EZSonar Anywhere发挥事中事前事后价值经过这个事情,行方运维团队也在积极审视他们的变更流程,同时,把EZSonar引入到了变更流程内。 上面讲的是EZSonar在变更过程中可发挥的价值,实际上,我们能做得更多,在变更事前、事中、事后都能发挥对应价值。发挥价值☑ 事前对于一些关键的变更,事前都会做变更演练。如何利用好每次演练,为真正的投产做保驾护航,EZSonar可提前建立专项监控,分析每一次演练结果,为最终变更提供支撑。☑ 事中在变更过程中,如果遇到异常问题,EZSonar可用于分析异常原因。变更结束后,立刻反向确认变更结果,可基于流量数据提供客观的指标。☑事后变更全部结束后,可持续运营,对比变更前后数据,评估变更成果。