我报名参加金石计划1期挑战——瓜分10万奖池,这是我的第 5 篇文章,点击查看活动详情”
一个告警而已,还这么小题大做,有本事你说出个花来!
-- 来自张三的鄙视
引子
对于互联网技术人员,凡对线上业务可靠性负责的人,都收到过异常告警通知,笔者作为运维岗,更是整天跟异常告警打交道,对这些通知信息那真是既爱又恨。No news is good news
,可若是哪天没收到告警,心里总是觉得哪里不对劲,若是连续收到告警,又将会是鸡飞狗跳。
服务异常,告警产生,告警收敛,告警通知,异常处理,告警恢复,这是典型的某个告警的一生。如今主流的监控软件,都提供各种消息通知,甚至是 Webhook,但从消息发出,到相关人员收到告警之间,还有很多事情可做。今天我们先抛开其他,只谈关于 “通知” 的那些事儿,也就是如何有效得让消息可达
。所以有如下几个问题:
- 用什么通道发送消息?
- 把消息发送给谁?
- 发送完成后还需要注意什么?
用什么通道发送消息?
消息通道很多,国内常用的有:短信,电话,企微,钉钉,飞书等等。具体选用哪个,根据公司情况斟酌即可。由于经常被拦截,短信也逐渐淡出告警通知的备选范围了。值得一提的是,除上述通道以外,还应该在告警平台上,个人消息中心也推送一份,以备反查。比如某用户企微收到 50 条消息,要想反查某条信息十分不便,此时在告警平台的页面上,可以非常容易定位。
所有的告警都用一个通道发吗?答案显然是否定的,不同的告警用不同的通道发。
工作日白天同事都在岗,在浏览器的通知栏告知即可,因为告警平台就是值日人员的工作台。非工作时间,可以用企微这些方式通知,对于紧急情况直接电话呼叫。但无论怎样通知,都应该在告警中心留一份。
把消息发送给谁?
假如某个微服务死掉了,这条告警消息应该发给谁呢?
首先,要发给服务的开发者和运维,其次开发负责人和运维负责人要不要发呢,最后再想想,产品经理要不要发呢;如果发送给张三,他没响应告警,要不要再发一次,又应该发送给谁呢?
想要搞清楚上述问题,就要对告警分级,而告警分级还会涉及应用分级。危险系数低的告警,企微通知即可,危险系统高的消息,直接就电话呼叫了。同时,危险等级越高,通知覆盖的人员也应该越广
。
回到我们的场景,如果张三未对告警做出响应,首先应该通知给他的备份人员;这个备份人员可以配置多级,进而实现告警的升级。所以收到告警,立刻响应十分重要。
我们再设想一步,如果张三请假了呢?那就不应该再发给张三了,而是发给他的交接人。还有什么场景吗?诸位可以打开脑洞。
发送完成后还需要注意什么?
场景一
在很多公司,扯皮是一种常态。设计系统时,应该从人性本恶的角度出发,用规则来避免对人性的考验。在事故复盘会议上,常常听到有人一脸无辜:啊,我没收到消息呀!
通知完成后,还应该记录下日志,什么时间发送了什么消息给哪个人,以什么通道告知的。这种记录可以有效降低上面这种尴尬,我们称其为:防扯皮
场景二
作为单一的个体,想要推动群体改善,往往是一件很难的事情,有时哪怕是自上而下的行政命令,也可能收效甚微。解决这个问题,可以引入群众监督制度
。
针对防扯皮记录的数据,根据人员,部门进行排名评比。找出异常响应积极和滞后的人员或部门进行奖惩。当然也可以根据告警的项目进行评估,看看谁年度处理告警最多。评比可以按月公示,让全员知晓,甚至可以推广到业务部门。此时驱动人们改善的,不再是某个人,而是某个机制。
总结
我不晓得有没有把 “通知” 这件事儿讲出个花来,但我知道至少说服了张三。针对告警通知的这套逻辑,目前还没有成熟的开源产品,我想这足够形成一个复杂的项目。有望社区开源搞起!