谈谈业务系统的监控报警

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

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

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

因为，不存在不出问题、没有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，哪怕是用户感觉很卡，都可能造成用户流失。这年头获取一个用户越来越贵，就这么轻而易举的把客户送走，实在是太可惜了。当然不是说，不是面向互联网用户的系统，就可以出问题，不管是给谁用的系统出了问题，做为开发人员你的脸上都不光彩吧。

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

以上的内容希望你们看了之后能够认可。如果你认可了，而且你身边的团队这方面做得不够，如果你的领导很开明，你可以主动提出建议，说不定还能留下好印象。

以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

• 谈谈业务系统的监控报警
• 聊聊 AIOps 落地监控报警的应对之策
• 极简监控报警系统
• kubernetes集群全栈监控报警方案kube-prometheus 荐
• DockOne微信分享（二五六）：哆啦A梦：基于Prometheus的企业监控报警平台
• 【监控系统】配合Graphite使用的报警系统

本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。