阅读 318

谈谈业务系统的监控报警

几年前,我半途接手负责了一个开发团队,当时这个团队做的业务系统属于金融行业。系统的开发、测试都快结束了,这个系统的功能还是挺复杂的,子系统三、四个,定时任务也不少,依赖的第三方系统也好几个。

和这个团队熟悉之后,我和大家说,我们需要对这个系统做监控报警(监控报警的名字叫法很多),监控报警是业务系统的金钟罩,对业务系统非常重要。当时有些人对监控报警没有概念,更感觉不到重要性,估计可能还有一些人认为我是新官上任三把火,一时说说而已。大部分人还是认为,产品的需求我都实现了,而且也有测试人员把关,开发何必给自己找额外的活儿。

的确,在我们做一个软件系统的时候,经常会遇到上面类似的现象:从接到需求开始,开发人员普遍会认为设计的功能都做完了,各种测试也通过了,最后也部署上线了,就算交差了,就万事大吉了。包括我自己,在我参加工作的头几年也是这么认为,而且是觉得这是理所当然的。其实呢,这种认识是很片面的,上线之后仍然要对系统负责任。为什么这么说呢?

因为,不存在不出问题、没有Bug 的系统。系统上线之后,就免不了出现故障,出故障是或早或晚的事,是或多或少的事。

我们能做的是,出现故障之后,第一时间知道,赶紧处理,防止影响扩大。再理想点,如果故障出现之前,刚有苗头的时候,我们就能发现,提前解决就更好了。业务系统的监控报警,就是干这个用的。

继续说接手的那个金融业务系统,系统上线之后,果然各种问题没少出,开发人员忙的焦头烂额,非常被动。我一边给大家继续灌输监控报警的重要性,一边开始搭建监控报警。一点点的把大家从被动变主动,问题越来越少。给你们说几个印象深刻的经历、体会。

1. 最常见的就是用户碰到Bug

无论你测试的多么充分,都不敢保证系统没有Bug,只是 Bug 还没出现。虽然 Bug 避免不了,但是作为开发人员,需要从运营或者客服人员那里知道出现 Bug,这就有问题了。用户碰到 Bug,用户找客服,客服再找开发,你想想这个过程有多慢,效率有多低。如果用户都懒得找客服反映,开发也不知道,那这个 Bug 会影响多少用户?

后来通过代码埋点、响应码、异常处理等等,基本做到了:开发人员能第一时间知道Bug。知道之后快速解决,该上线就上线。

2. 有些问题可以在出现之前就发现

当时出过这么一个问题,我们一个功能需要调用一个第三方的接口,当时第三方说 1、2 秒之内能返回结果,联调的时候也确实是很快能返回结果,于是我们把超时时间设置成了5 秒,也就是说超过 5 秒还没有返回,就认为调用第三方接口失败。这已经在 2 秒的基础上,又多留了 3 秒余地。上线之初一直没有问题,但是过了几个月之后,经常出现调用第三方接口失败的问题。经过查原因,发现都是因为接口超时引起的,原来是第三方的响应比以前变慢了很多,经常会超过 5 秒。

知道原因之后就很好解决了。解决问题之后,我们查历史,发现响应时间也不是突然变慢的,从 1 秒、2 秒、3 秒……慢慢涨上去的。如果当初,我们对响应时间进行监控,在接近 5 秒的时候就主动预警,主动联系第三方进行调整,那么这个问题就不会出现了。

3. 要依赖第三方,但是不要过分信赖第三方

除了上面那段提到的之外,我们这个业务系统依赖的第三方系统还好几个。第三方系统也是人做的,也会出问题,它们出问题,我们也跟着受影响,影响到我们的用户,用户就认为是我们系统的问题,解释也没啥用。

怎么让第三方对我们的影响最小呢?一是,同一个服务,尽量多接几家第三方,然后我们自己做个路由。就算是其中一家掉链子了,我们能快速切换到另外一家。另外,我们自己主动检测第三方的服务,在用户使用高峰到来之前,自己主动发起几笔业务,测测第三方的服务是否正常。对我们系统来说,越是重要的第三方服务(例如支付),越应该做好预防工作。

4. 我们开发的系统,用户用着卡不卡

系统出现Bug、故障,还有一个因素也容易让用户崩溃:“系统太卡”,例如点一个按钮半天没反应,刷新一个页面需要很长时间。造成系统卡的原因有很多,有的可以通过提高服务器配置解决,有的可以通过优化数据库和SQL 解决,有的可以通过优化代码来解决。只要能发现系统慢,能大概定位到原因,基本就有办法进行优化。

我们系统上线后没多久就把这块纳入了监控范围。先是搞清楚了系统高峰时段,再就是,从用户角度出发,记录每个功能服务的响应时间,发现慢的及时优化。注意,一定是按照用户角度去观测,不要只看单个服务的响应时间,或者单条SQL 的执行时间,因为有的功能包含了多个服务,或者多个 SQL 执行。单独看服务或者SQL 都不慢,但是合在一起,总时间可能就很长。

5. 报警的方式灵活多样

监控到问题之后,怎么报警给开发人员呢?我们做监控报警的时候,很多人说做个系统,可以在系统上看,解决之后做好记录。我说我们的目的是要让开发人员及时看到,如果没登录系统不就看不到了吗。做事情一定要牢记做事的目的,不要只关注做事的方式。邮件、短信、微信、QQ 都可以通知开发人员出问题了,而且短信、微信、QQ 的实时性比做的系统更好。

后来我们的做法是,重要的问题使用短信、微信进行通知,不太重要的问题用邮件通知。为了防止有人看不到,一般同时多通知几个人,可以互相提醒。到最后,我们也没有做个系统,就靠着邮件、短信、微信这些,运转的也还可以。

除了上面说的,监控报警还包括很多内容,比如监控服务器的存储、内存、CPU这些最最最基础,最最最重要的,这些一般都有专业的人来做这块(我不专业就没多写);还比如监控定时任务有没有执行;还比如有没有人故意搞系统的下发短信,等等。监控报警的叫法、实现方式也有很多种,不用太纠结,“黑猫白猫,抓到老鼠就是好猫”。

工作年头越长,我越感觉到监控报警的重要(也可能是越老越怂),因为业务系统出现故障的代价太大了。如果这个系统是给互联网用户用的,那么出现Bug,哪怕是用户感觉很卡,都可能造成用户流失。这年头获取一个用户越来越贵,就这么轻而易举的把客户送走,实在是太可惜了。当然不是说,不是面向互联网用户的系统,就可以出问题,不管是给谁用的系统出了问题,做为开发人员你的脸上都不光彩吧。

业务系统的监控报警不出彩,是幕后英雄。监控报警不仅仅是个系统,更重要的是,能体现我们做事的态度和责任心。

关于我:15年以上老程序猿、百人技术团队管理者、游戏创业没赚到钱、写作恐惧症患者的真·四猿外。以前极其不擅长写作,最近决定对着弱点迎难而上,通过写作分享经验、干货。关注我的微信公众号(四猿外),看到更多文章。