这是一个创建于 2525 天前的主题，其中的信息可能已经有所发展或是发生改变。
公司有一内部业务应用，运行在公司机房里的一台服务器上，同机房里还有宽带接入、核心交换等设备。
公司有两处办公地点，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 左右通知同事们业务系统可用了。
与此同时，前线的领导说故障原因找到了。
系某领导所在楼层的交换机故障引发。
某品牌某些比较老的交换机在长时间使用后会出现一种故障，以前见到过，交换机会在工作中突然进入一种异常状态，表现为超高的丢包率。
该领导发现自己上网卡顿，系统打不开，于是他拿起了机房的钥匙，把整个机柜断电，再重新上电来重启设备。服务器意外掉电又导致数据表损坏。
整个故障过程先是网络卡顿导致几个同事偶尔出现加载失败的情况，然后交换机故障使得该领导以为故障迟迟未得到解决，于是他试图重启机房里的设备解决故障。可能他之前也这样做过，幸运的是没有造成服务器上的文件损坏，而且解决了故障。
总结：
网线千万条，稳定第一条。
重启不规范，运维两行泪。
公司有两处办公地点，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 左右通知同事们业务系统可用了。
与此同时，前线的领导说故障原因找到了。
系某领导所在楼层的交换机故障引发。
某品牌某些比较老的交换机在长时间使用后会出现一种故障，以前见到过，交换机会在工作中突然进入一种异常状态，表现为超高的丢包率。
该领导发现自己上网卡顿，系统打不开，于是他拿起了机房的钥匙，把整个机柜断电，再重新上电来重启设备。服务器意外掉电又导致数据表损坏。
整个故障过程先是网络卡顿导致几个同事偶尔出现加载失败的情况，然后交换机故障使得该领导以为故障迟迟未得到解决，于是他试图重启机房里的设备解决故障。可能他之前也这样做过，幸运的是没有造成服务器上的文件损坏，而且解决了故障。
总结：
网线千万条，稳定第一条。
重启不规范，运维两行泪。
 |
1
hellovx 2019 年 2 月 14 日  7
重启这领导太硬核了……
|
 |
2
TomatoYuyuko 2019 年 2 月 14 日
非物质文化遗产：电视机雪花拍两下就好了（滑稽
|
 |
3
padapen 2019 年 2 月 14 日 10
于是他拿起了机房的钥匙，把整个机柜断电，再重新上电来重启设备.....看见这种，真想一板砖拍过去
|
 |
4
Hancock 2019 年 2 月 14 日
领导给力
|
 |
5
mscststs 2019 年 2 月 14 日
要么换个机房，要么换个领导吧
|
 |
6
yulgang 2019 年 2 月 14 日
本以为重启治百病
|
 |
7
moonsola 2019 年 2 月 14 日
"与此同时，前线的领导说故障原因找到了。系某领导所在楼层的交换机故障引发"
交换机：这锅我一个人背不动。 |
 |
8
logicr 2019 年 2 月 14 日 via Android
@TomatoYuyuko 肯能本来领导拿着钥匙进去拍了机柜的，没用然后再用了断电重启打法。
|
 |
9
misaka19000 2019 年 2 月 14 日
你们领导牛逼
|
 |
10
seven777 2019 年 2 月 14 日 via Android
让孩子拿玻璃碗，就准备好被摔！运维的责任，谁都不要怪！
另外，只要是生产项目，不论项目大小，稳定第一！！！ |
 |
11
jjianwen68 2019 年 2 月 14 日
这么朴实刚健的领导
|
 |
12
donyee 2019 年 2 月 14 日
领导：这点小问题，我重启下试试；欧耶，解决了...
|
 |
13
hasbug 2019 年 2 月 14 日
哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈
|
 |
14
Eytoyes 2019 年 2 月 14 日
北京市第三运维中心提醒您，算了。。。直接两行泪吧
|
 |
15
ziding 2019 年 2 月 14 日
MySQL 太不靠谱，这种情况下居然表会坏~
|
 |
16
fange01 2019 年 2 月 14 日
哎呀这个 ID 很熟悉、、领导操作方式也很熟悉。
|
 |
17
4357 2019 年 2 月 14 日
牛逼
|
 |
18
dko 2019 年 2 月 14 日
重启也就算了。。。直接断电，这谁扛得住啊
|
 |
19
guan123 2019 年 2 月 14 日 1
最后的总结是亮点 ，不过话说回来，整体都被重启了，也都没感知到，监控做的有点那啥啊
|
 |
20
zarte 2019 年 2 月 14 日
领导可以不背锅
|
 |
21
jasonyang9 2019 年 2 月 14 日
事务机制应该能保证这种情况下的数据库完整性啊，物理存储坏了？
|
 |
22
jandan 2019 年 2 月 14 日
 也就是领导啊 |
 |
23
openbsd 2019 年 2 月 14 日
领导这一波操作很骚气啊! 照顾领导情绪 运维可以把非核心 易故障的交换机单独接一个插座，甚至可以配置一个智能插座(提供 APP 远程)，方便领导没事就断一波电，反正非智能交换机启动也就几秒的事 [手动滑稽...]
@TomatoYuyuko #2 这个真心是遗产，小时候家里有台 NEC 的黑白 洋垃圾？就这样拍了 10 多年，偶尔里面还冒点烟，淘汰后拆开看了下，供电部分 ？三个 MOS ？管 烧焦两个 且 PCB 严重碳化，竟然一直都能正常？观看 |
 |
24
dr1q65MfKFKHnJr6 2019 年 2 月 14 日
怎么有股 央视解密节目 的味道？？？？最后发现被断电了，监控哪儿去了？
|
|
25
F281M6Dh8DXpD1g2 2019 年 2 月 14 日
2019 年还在用 myisam,不是等着倒霉么
|
 |
26
bbsanimal 2019 年 2 月 14 日 5
某医院的加护病房的病人总是在星期天十一点左右死掉，这让医生们困惑不解， 甚至认为是灵异事件，于是成立专家组调查事情的原因。到了星期天，时钟刚刚敲响十一点，通过监视器发现， 在星期天打扫的清洁工走进加护病房，拔掉重病号的生命维持系统电线插头，然后插上了吸尘器插头，开始打扫卫生。。。
|
 |
27
jaryur 2019 年 2 月 14 日
某领导修炼重启大法误入歧途
|
 |
28
AsunaQAQ 2019 年 2 月 14 日
NB
|
 |
29
dany813 2019 年 2 月 14 日
领导牛逼
|
 |
30
freezex 2019 年 2 月 14 日 via Android
是不是应该配个 ups，电源故障时自动关机
|
 |
31
banmuyutian 2019 年 2 月 14 日
领导问：我怎么上不了网了？
答：重启试试。 领导：好。 |
 |
32
pexcn 2019 年 2 月 14 日 via iPhone
黑客攻击 (物理)
|
 |
33
9hills 2019 年 2 月 14 日 via iPhone
难道不是赶快做数据库主从么？
|
 |
34
johnnie502 2019 年 2 月 14 日
@freezex 领导会直接拔 ups 上的插头的
|
 |
35
JerryCha 2019 年 2 月 15 日
过于硬核
还好没使用另一招：出故障时踢两脚 |
 |
36
Alpha486 2019 年 2 月 15 日 via iPhone
领导：先断机房电源，重启问题就好，我有经验！！接着就是一点操作！！
|
 |
37
julyclyde 2019 年 2 月 15 日
尽早逃离 myisam 吧
一旦故障，可修复率较低 |
 |
38
nbin2008 2019 年 2 月 15 日
领导一出手，就知有木有
|
 |
39
Biexl 2019 年 2 月 15 日
万能重启 ！
|
 |
40
lcatt 2019 年 2 月 15 日
服务器和网络设备共用一个机柜？另外交换机重启要断整个机柜的电是什么鬼。非标机柜才能这么做吧，听你的描述我觉得你们机房设计很很乱啊，需要参考 GB50174 好好梳理下，不然以后还会发生。
@openbsd 机柜专用插排不带开关的，就是防止误操作。 |
 |
42
ttgo 2019 年 2 月 15 日
咳咳，我干过类似的事儿，捅了特别特别大的娄子。
但万幸，当时没人发现。。 过了好多年，我才告诉别人当年是我干的。。 |
|
43
openbsd 2019 年 2 月 15 日
|
 |
44
notreami 2019 年 2 月 15 日
为啥这么多人跪舔呢？
|
 |
46
xi2008wang 2019 年 2 月 15 日 1
自己检讨一下吧，因为出了问题，折腾的是自己。
自己负责的服务器，自己要监控起来： 连通性监控、重启监控、磁盘用量监控、进程监控、业务数据（用户数、注册数）监控； 还有硬件部署隔离及整改： 机柜隔离、电源隔离、UPS 保护、硬件标签及警告标示 |
 |
47
winglight2016 2019 年 2 月 15 日
断电重启的骚操作。。。
|
 |
48
xi_lin 2019 年 2 月 15 日
领导牛逼
|
 |
49
BUPTGuo 2019 年 2 月 15 日
于是他拿起了机房的钥匙，把整个机柜断电，再重新上电来重启设备……牛逼大法了
|
Select Language