别担心... 现在这互联网时代啊，服务器要是突然宕机了那可真是要命。你想啊，用户正买东西呢，突然网站打不开了不得把人气死啊？老板那边也催得紧，说赶紧恢复，不然要扣工资。所以啊，宕机切换这玩意儿，虽然是没办法的办法，但确实得会搞，不然到时候手忙脚乱的，更完蛋。今天就瞎聊聊这事儿，反正我也不是啥专家，就是把自己知道的、见过的都倒腾出来大家凑合看吧。

宕机是啥？为啥要搞切换？

正宗。 先说说得明白，啥叫“宕机”。说白了就是服务器不干活了要么是挂了要么是卡死了反正用户访问不了。就像你家的电脑突然蓝屏一样，急死个人。为啥要搞切换呢？总不能让它一直宕机吧？用户等不起，老板更等不起。所以就得有个备用的，主服务器不行了就赶紧换到备用服务器上，让业务先跑起来回头再慢慢修那个坏的。这玩意儿就叫“宕机切换”，听着挺高级，其实说白了就是“换服务器”。

比如我们公司以前搞过一个在线商城， 有一次支付系统突然挂了用户付不了钱，订单积了一堆，客服

搞个备机是基础，别把鸡蛋放一个篮子里

要想搞切换，先说说得有备机啊。你都没备机，切啥？所以最简单的办法就是搞个主备架构， 一台主服务器干活，一台备用服务器在那儿等着，主的一挂，备的立马顶上。不过这玩意儿也有缺点，比如备机平时没啥用，浪费资源。 何不... 所以现在有些公司搞“多活架构”， 就是好几台服务器一起干活，平时流量就分摊开，万一有一台挂了剩下的还能顶上，不过这玩意儿搞起来麻烦，得有技术的人弄，我们这种小公司一般搞不起，还是主备实在。

我见过一个公司， 就没搞备机，服务器一挂，整个网站全瘫痪了老板急得团团转，运维人员连夜修，修了半天也没修好，后来还是临时租了个服务器，才把业务恢复过来。后来啊那天损失了好几十万，老板把运维经理骂了个狗血淋头。所以说备机这玩意儿，平时看着没用，真出事了那就是救命稻草，扎心了...。

真出事了咋办？一步步来别慌

服务器突然宕机了别慌，先深呼吸，然后按步骤来。反正慌也没用，问题不会自己解决，越慌越容易出错。我以前第一次遇到宕机的时候， 手都抖了不知道该干啥，还是旁边的老员工拉了我一把，说“别慌，先看看是啥问题”。所以啊，第一步，先确认问题到底是啥，翻车了。。

先看看是啥问题，别瞎切

怎么确认问题呢？最简单的办法就是ping一下服务器地址。ping通了说明服务器能连上，可能是软件问题；ping不通那可能就是硬件问题或者网络断了。不过有时候也靠不住我上次ping是通的，但网站还是打不开， 我可是吃过亏的。 后来才发现是数据库挂了。所以除了ping，还得看看服务器上的进程是不是在跑，端口是不是监听，日志里有没有报错。这些操作吧，一般运维平台都有，或者用命令行敲几下反正就是各种试，直到找到问题根源。

有时候问题也不一定在服务器本身，可能是网络问题，比如机房断电了或者光纤被挖断了。这种时候你就没办法了只能等运营商或者机房的人来修。不过这种事一般很少，大部分时候还是服务器自己的问题。对了 还有可能是被攻击了比如DDoS攻击，服务器被流量冲垮了这种时候就得先防护，再切服务器，不然切过去也还是会被冲垮，CPU你。。

确认是宕机了 赶紧通知人

确认是服务器真不行了那下一步就是通知人。这种事不能自己扛着，得告诉领导，告诉相关部门。比如业务部门得知道网站挂了客服部门得准备应对客户投诉，管理层得知道损失有多大。不然你偷偷摸摸把服务器切好了后来啊领导还不知道， KTV你。 回头问你为啥没及时汇报，那麻烦就大了。通知的时候要说清楚情况，啥时候挂的，影响多大，预计多久能恢复，让大家心里有个数。

我们公司以前有个运维小哥， 服务器宕机了自己偷偷在那儿修，没告诉任何人，修了两个小时也没修好，后来啊业务部门发现订单没了才找过来这时候已经晚了好多客户都流失了。 我倾向于... 后来老板把他骂了个半死，说他没有团队意识。所以说通知这步很重要，别学那个傻小子。

开始切换，点按钮就完事了？没那么简单

通知完人了就该开始切换了。现在一般都有切换脚本，提前写好的，到时候点一下按钮就能运行。不过脚本这玩意儿也不保险， 我上次用脚本切换，后来啊脚本跑了一半卡住了业务没切过去，反而把主服务器搞得更乱了再说说只能手动切，忙了半宿。所以切换的时候，最好旁边有个人盯着，万一出问题能及时停下来。

切换完了不能就这么算了得赶紧验证业务能不能用。比如打开网站看看首页能不能显示，用户能不能登录，订单能不能提交。这些都得试一遍，不能只看服务器起来了就完事。我见过一次 服务器切过去了也能打开，但用户登录不了后来才发现是数据库没同步过去，数据丢失了后来啊又得切回来重新搞，白忙活一场。所以说验证这步千万不能省，不然切了个寂寞，还出更大的问题。

切完了就没事了？没那么简单，后头还有一堆事

我服了。 很多人以为切换完成就万事大吉了业务恢复了就没事了。其实不然后头还有一堆事要做，不然下次可能还会出同样的毛病。这些事不做，等于白切了还浪费了这次机会。

开会吵架， 哦不是分析原因

地道。 业务恢复了接下来就得开个复盘会，分析这次宕机到底是主要原因是啥。一般这种会都会吵起来运维说是硬件问题，开发说是软件bug，老板说是运维没维护好。反正就是互相甩锅，再说说也吵不出个所以然来。不过不管吵不吵，总得记录下来这次是主要原因是啥，下次怎么避免。比如是服务器老了那就赶紧换新的；是软件bug，那就赶紧修复版本；是运维操作失误，那就赶紧加强培训。

我明白了。 我上次参加复盘会， 吵了三个小时再说说也没确定具体原因，反正就是“可能多种因素导致的”。老板不满意，说“下次别吵了直接说解决办法”。后来没办法， 只能先把服务器硬件全检查了一遍，换了几个风扇，又把软件版本升级了一下反正能做的都做了至于到底有没有用，也不知道，反正老板满意了就行。

把流程改改，别再犯同样的错

在理。 分析完原因，就得把切换流程优化一下。以前可能流程太复杂，审批半天等批下来业务都黄了。所以可以简化审批，比如紧急情况下运维人员可以先切，再补报告。还有， 以前可能没考虑到某些故障场景，比如数据库突然挂了怎么办，网络断了怎么办，这些都得加到流程里免得到时候又不知道该干啥。

架构也得调整一下。比如这次是主要原因是主服务器硬盘坏了那就可以考虑加个RAID，或者把数据多备份几份。如果是网络问题，那就多搞几个线路，别只依赖一个运营商。反正就是针对这次暴露出来的问题，把薄弱环节加强一下别下次还在同一个地方栽跟头。

培训演练，装样子也得做

光改流程改架构还不够，还得培训员工。不过培训这玩意儿吧，很多时候都是走形式。领导让培训，就做个PPT，念一念，大家坐在下面玩手机，反正也记不住。真出事了还是手忙脚乱。所以培训不能光靠PPT， 最好搞点实际的演练，比如模拟服务器宕机，让大家实际操作一遍切换流程，熟悉一下步骤，翻车了。。

我们公司上个月搞了次演练，后来啊搞砸了。脚本运行到一半，忘了下一步该干啥了大家在那儿干瞪眼，再说说还是老员工上去手动操作的。演练完领导也没说啥，反正就是“下次注意”。不过话说回来虽然演练很烂，但至少让大家知道有这么回事，真出事了不会完全不知所措，也算有点用吧，功力不足。。

平时得多注意， 别等出事了才后悔

我傻了。 宕机切换这玩意儿，说到底还是“养兵千日用兵一时”。平时不注意，真出事了再搞，肯定来不及。所以平时得多做点准备工作，把监控搞好，把备份做好，把预案定好，这样真出事了才能从容应对。

监控要搞起来但别搞太复杂

监控这玩意儿很重要，能提前发现问题。比如服务器温度高了或者数据库连接数异常了监控报警了就可以赶紧处理，避免宕机。不过监控也别搞太复杂，搞一大堆指标，看都看不过来反而有用的信息被淹没了。一般就监控几个关键的，比如CPU使用率、内存占用、磁盘空间、网络流量这些，够用就行。

我跪了。 我们公司以前搞了个特别复杂的监控平台， 能监控几百个指标，后来啊运维人员天天看报警，看得眼花缭乱，真正重要的报警反而没注意到。后来简化了一下只监控核心指标，反而效果好多了。所以说监控不是越多越好，关键是有效。

备份备份备份，重要的事说三遍

备份这玩意儿，说再多都不为过。不管你监控搞得再好，架构搞得再牛逼，万一硬盘坏了数据没了那一切都白搭。所以数据一定要定期备份，最好是异地备份，免得机房出问题了备份也没了。备份完了还得定期测试，确保备份的数据能恢复过来不然备份了个寂寞，有啥用？

我见过一个公司， 天天喊着备份，后来啊真出事了想恢复数据，发现备份文件是坏的，根本恢复不了。再说说只能硬着头皮重新搞数据，损失了好几百万。所以说备份不是形式主义，得真做，而且要做好，嗐...。

预案要写清楚， 别到时候翻书都来不及

应急预案这玩意儿，就是出事了该干啥的指南。得写得简单明了步骤清晰，让没经验的人也能看懂。别搞那么多专业术语，什么“冗余机制”、“数据同步策略”，反正一般人看不懂，写了也白写。最好是图文并茂， 一步一步教你怎么操作，比如步验证业务，这样一看就明白，说到底。。

害... 我们公司的预案就是从网上抄的， 改了改公司名字，后来啊真出事了发现预案里写的步骤根本不对，我们公司架构跟人家不一样，照着做反而把事情搞得更糟。后来没办法，只能自己重新写了一份，简单点，但实用。所以说预案不能抄，得根据自己的实际情况来写。

一下 反正就是别偷懒，多做准备

宕机切换这玩意儿，说难不难，说简单也不简单。关键就是平时多做准备，有备无患。别想着“我这服务器肯定不会坏”，这种事谁也说不准。搞个备机，做好监控，备份数据，写好预案，定期演练，这些事虽然麻烦，但真出事了能救命。反正我们做运维的，就是干这种“平时不显眼，一出事就背锅”的活，只能多注意点，别让自己太被动。行了就说这么多了反正我也说得乱七八糟的，大家凑合看吧，有啥不对的地方，也别喷我，我就一打酱油的，可不是吗！。