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