记录一下刚刚发生的内部业务系统故障

公司有一内部业务应用，运行在公司机房里的一台服务器上，同机房里还有宽带接入、核心交换等设备。
公司有两处办公地点，A 处为老办公室，设备有些老旧，服务器也放在这边； B 处为新办公室，我们技术部在这边办公。两办公室各自有独立的局域网以及公网 IP，使用 IPSEC VPN 连通。

上午 9:40 左右，有同事反映业务系统打不开或加载超时。毕竟系统跨着公网，这种故障偶有发生，我们像往常一样检查 VPN 是否通畅、两个路由器负载是否过高、是否有某 IP 流量异常。
检查一圈下来没有发现异常，我们这边打开正常，A 处路由器负载有点高，但不像是故障原因。于是跟同事们说可能 A 处网络有卡顿，大家稍后再试一下。
这个事就暂时这样了。

上午 11:00 左右，越来越多的同事反映系统无法使用，我们尝试打开系统，发现故障升级了，报 502 错误，此时肯定大家都无法使用了。
通过 SSH 登录业务服务器，ps 查看发现业务应用没有运行，查看日志发现数据库表有错误。
我们部门领导已打车奔赴前线调查故障原因以及安抚用户情绪。
尝试使用 SQL 命令修复表，失败，提示无法创建临时文件，没有权限。担心硬盘故障，df 查看剩余空间足够，dmesg 没有报告硬盘写入错误，SMART 报告健康，松了口气。
中间看了下 uptime，服务器刚刚被重启过。
继续尝试修复表，通过万能的 StackOverflow 得知可以使用 myisamchk 修复表，于是停掉数据库，进入数据目录，尝试修复表文件。
修复进行顺利，在修复了若干表后，11:30 左右通知同事们业务系统可用了。

与此同时，前线的领导说故障原因找到了。
系某领导所在楼层的交换机故障引发。
某品牌某些比较老的交换机在长时间使用后会出现一种故障，以前见到过，交换机会在工作中突然进入一种异常状态，表现为超高的丢包率。
该领导发现自己上网卡顿，系统打不开，于是他拿起了机房的钥匙，把整个机柜断电，再重新上电来重启设备。服务器意外掉电又导致数据表损坏。

整个故障过程先是网络卡顿导致几个同事偶尔出现加载失败的情况，然后交换机故障使得该领导以为故障迟迟未得到解决，于是他试图重启机房里的设备解决故障。可能他之前也这样做过，幸运的是没有造成服务器上的文件损坏，而且解决了故障。

总结：
网线千万条，稳定第一条。
重启不规范，运维两行泪。

openbsd

2019-02-14 15:22:24 +08:00

领导这一波操作很骚气啊! 照顾领导情绪运维可以把非核心易故障的交换机单独接一个插座，甚至可以配置一个智能插座(提供 APP 远程)，方便领导没事就断一波电，反正非智能交换机启动也就几秒的事 [手动滑稽...]

@TomatoYuyuko #2
这个真心是遗产，小时候家里有台 NEC 的黑白洋垃圾？就这样拍了 10 多年，偶尔里面还冒点烟，淘汰后拆开看了下，供电部分？三个 MOS ？管烧焦两个且 PCB 严重碳化，竟然一直都能正常？观看