雨来了，问题也来了。早晨一起床，看到几十个告警，其中一条是说办公区的网络中断了。好吧，吃了早饭，骑个电驴子去公司。

到了公司，打开弱电间，发现运营商设备的指示灯是LOS状态。

联系移动运营商，对方收的挺快，然后说开完会过来。反正是快10点的时候，第一波维修师傅到场。到了之后开始打光，然后去楼上看状态。但是，楼上已经人去楼空，而且弱电间还打不开。打了物业3次电话，保安大爷拿来了备用钥匙也是打不开。与此同时，维修师傅去楼外移动弱电柜查看。问了一圈人，最后找到了那根光纤。经检测，这根光纤向上是正常的，但是向下探测到200多米的地方有问题。后来才知道，200多米就是移动在整座楼的12楼拉的光纤。而在12楼的弱电间放置了一个1分4的分线盒。

既然11楼的弱电间进不去，那就在12楼查看吧。到了12楼的现场，可以看到10楼打上来的光，但是从12楼到10楼打光，在10楼却看不到。经过分析，是10楼到12楼的皮纤与分线盒之间的尾纤之间的熔接出了问题。然后就是打电话摇人。

1 hour later。

身穿移动通信战袍的兄弟到场，手里提着黄色的熔纤装备。三下五除二，第一次没融上，第二次融好了。10楼守着的兄弟说光衰“22”，然后插到运营商设备商。我这边就开始啪啪收恢复告警了。

送走了运营商的兄弟，监控显示有openvpn状态不正常，重启后恢复。

事后，查看出口路由器状态，发现了一个有意思的地方，虽然上不去网，但是连接数是很高的呦。想想也是，一般通信采用TCP协议，处理完后就关闭了。但是由于光纤异常，但是路由器的以太口是正常的，所以路由器并不会认为自己掉线了，还在不断尝试进行数据传输。这种数据传输卡在了路由器WAN口寻找网关的MAC地址，也就是ARP协议的交互过程了。

当网络恢复后，在线连接数立马下来了。

本次故障发生在午夜1点。我在想，处理过程从早上7点到中午11:30，对于办公来说确实浪费了半天。半条时间，大家多半在摸鱼，而修好后，大家开始刷剧吃饭了。

是不是要开一个电话告警呢？

试试吧。当前监控办公区互联网通断的是uptime-kuma，部署在阿里云。

首先，在spug里面新增一个模版，包括短信和电话，

映射变量到${msg}，短信那里设置也是。

添加告警对象。保存后拷贝刚刚新建的模版链接。

然后，配置uptime-kuma的电话告警，如下图。然后点击测试。

再次，找到在uptime-kuma中配置监控办公网的告警条目，开启刚刚新建的告警方式。

这个时候因为监控正常，可以打开反向监控，即如果在线则判定不正常，触发告警。

告警的内容如下：


对了，看了该告警记录，我才突然发现，为啥路由器显示凌晨1点多没有网络流量，但是告警显示是凌晨3点。因为之前发现，阿里云每天凌晨过后经常升级，导致配置敏感的监控系统频繁发送告警，于是手动将uptime-kuma在凌晨3点前都是“maintance”状态。

好了。如此一来，下次办公网再出现问题，就是接收到电话告警了。