起因是2.28晚十一点左右，收到了用户的反馈，产品故障无法使用；然后去客户端瞅了一眼，点什么都没反应，大概率就是后端/网络炸了。

急匆匆的赶回家开始排查故障，打开电脑思考了一下排错流程：

由于这个项目要经过腾讯的服务器，首先怀疑腾讯那边的网络出口down了（上个月腾讯出现过多个网络出口宕机的事故）

对腾讯那边的域名进行请求发现通信顺畅，没有超时现象，排除了腾讯网络出口down的可能性。

那接下来就是排查我这边的网络出口问题了，出口使用的是电信的专线，链路down的可能性也比较低，但是不能说没有，看了一眼出口网关的日志，此时是3.1凌晨0点，并没有发现出接口故障的日志；将网络用策略路由的方式接入其他机器，外网通信正常，排除本地出口链路故障的可能性。

那就到系统层面了，怀疑是策略路由导致的链路紊乱，用指令重启了一下系统的network，故障依旧；

查看一下本机的出口ip，确保出口没问题

但是发现无法输出，想了想，感觉是这个网站挂了，然后试了一下别的域名，发现都无法输出，直接卡在了那里，这个时候就隐隐感觉不太对了。

怀疑是dns的问题，于是测试了一下dns，发现并没有问题，可以正常的解析出ip；然后再尝试向百度发起请求。

居然也无法输出。

难道是系统不通外网？尝试ping一下百度

到这一步，感觉问题好像有点严重，为了进一步验证猜想尝试使用apt安装任意一个包

同样拉取不下来，后面又对内网的ip进行了curl测试，可以正常输出；那么故障原因就找到了，这台机器无法接收外网的http数据包，但是icmp是能通的，使用同一个网络的其他虚拟机则是一切正常。到这里就有点玄学了，检查了一遍系统的防火墙和出口网关的防火墙，都没有做任何的限制；这个项目从部署到故障也没人去动过它，也就是跑着跑着自己爆炸了，这种问题实在是不知道怎么排查，系统日志也没有提供任何有用的信息。

看了一下时间，已经快一点了，距离故障到现在已经快2h了，由于项目的特殊性，凌晨这段时间的用户量会比较多，客服那边承受的压力也会很大，更何况这个项目才开始不久，好不容易攒到一些用户基数，营收上面勉强熬到回本，如果因为这次宕机导致项目黄了，那就亏得更大了。

既然无法在短时间内找出问题那就只能想其他方案把这个项目跑起来了；经过开发的一阵分析，捋了一下收发过程：

客户端向腾讯服务器发起请求，腾讯服务器将请求发送到我们本地服务器并附带一个token包，本地服务器将token加入数据包中然后发送到腾讯服务器，腾讯服务器验证token之后返回到客户端。

测试发现腾讯发送token的服务器和将数据包返回客户端的服务器不是同一个，也就是下发token的是腾讯的A服务器，而验证token并转发至客户端的是腾讯的B服务器。

本地服务器每发一个包之前都要向腾讯的A服务器请求一个token，而请求的地址恰好又是一个域名，好巧不巧部署项目的这个系统的无法接收到http的回包；而B服务器则是一个ip，既然这样的话，在局域网的另一台机器上写一个自动化脚本去请求token，然后将token塞入发出的消息里面是否可行呢？（本人不是开发，不清楚是怎么塞进去的）

经测试，A服务器并没有ip白名单机制，任何一个网络都可以去对他发起请求，并且得到一个token；这样一来的话就方便多了，半个小时左右开发将脚本写好，测试下来发现没问题，然后就投入使用，项目恢复了正常。

从排错到项目恢复用了一个小时的时间，但是又能怎么办呢，事故报告上也只能这样记录，Ubuntu在无人进行多余操作与干扰的情况下，自我产生了故障，无法接收外部的http数据包，导致项目故障无法运行。这段话同行听着估计都懵，更别说用户了，这种解释肯定不可能买账的。

看了一下时间，已经是凌晨一点多了，这一个小时折腾的我和开发也是够累的，看了会项目运行正常就都入睡去了。

第二天开发和我都起了个大早，担心哪天这个系统对外网的icmp也失效，由于数据库比较大，所以准备将项目的前端迁移到另一台机器，然后原机器充当内网数据库；因为内网的通信完全正常，庆幸当初是用docker部署的，迁移比较方便，十分钟左右就迁移完成了。

为什么不做容灾呢，项目起步到现在小半年了，有一定的营收但是并没有收回成本，实在是没有更多的钱去做一个比较完善的容灾了；更没想到的是系统会自己发生故障，甚至听着都觉得离谱的故障。

为什么当时没有尝试重启呢？一个自己能跑着跑着都能故障的系统，谁也说不好重启指令下去之后它还能不能起得来。

至于项目在经历过这次事故之后会怎么样，谁也不知道，我们已经做最大的努力了，项目黄了那也只能宣布解散了......