服务器宕机怎么办?服务器故障应急预案

昨日携程旅行网站打不开服务器故障，相信大家也看到携程科技大楼彻夜明灯加紧整修的壮观场景，那么对于服务器宕机怎么办本文小编就来教一下大家服务器故障应急预案。
首先分清导致服务器出故障的因素：

1、外部攻击

2、内部攻击

3、运维误 *** 作

服务器宕机怎么办服务器故障应急预案

不管是外部攻击还是内部故障，备份好以及冗余措施，可以使宕机时间缩短到最低。

备份问题尽管听起来不可思议，但在实践中，不少企业并未建立起一套检验过的备份系统。备份的意义在于危急时刻可以快速恢复或重建生产系统。在企业网络中，经常出现的问题实际上是：

备份步骤的瑕疵导致并未完成正确的备份过程

由于有限的存储空间导致一定时间后因存储空间耗尽导致的随后备份失败

备份介质受损导致无法成功恢复

传统上，磁带因其低造价以及高存储密度使其成为了理想的备份介质。然而，这种传统备份介质的几个致命缺点经常使其内含的数据变得不可存取：

丢失的磁带索引卡片

磁带介质在存储过程中容易受到外界磁场影响

介质本身损坏

介质读取过程中被读取设备损坏

此外，磁带备份介质本身存储在磁带仓库中，从仓库检索所需的备份磁带、转移至数据中心并重新加载数据的时间消耗通常也是客观的。

即使有一套备份系统仍然是不能抵挡所有的意外事故的。2014 年， Samsung 数据中心的一场大火使其云服务暂停服务。如果没有异地备份，这场大火将使其本地备份的恢复变得极为困难。

冗余对于突发性事件来说，尽快恢复，或者是持续的提供服务是非常重要的。本月，某知名支付公司因数据中心网络连接性故障导致了一段时间的服务中断。如果有更好的冗余方案，此种事故的影响面将会得以降低，甚至会化解为用户不可感知的内部事故。

大部分服务器都有两部独立的 PSU，任意一部 PSU失效并不会影响其正常服务;一般来说，服务器的两部 PSU 将连接到两路不同的电路或不间断电源上以避免市电失效;数据中心电源多数同时配备 UPS 和柴油发电机来避免发电公司未通知的停止供电服务导致的服务中断。网络亦然;同时接入多路 ISP 线路，并对其进行独立布线，同时在多条线路上宣告地址，便可使得网络服务的鲁棒性更高。

在系统的视角上，只有同时配置好的备份以及冗余方案，才能提高可用性，避免非可控因素导致的长时间服务中断。

服务器宕机怎么办服务器故障应急预案就为大家介绍到这里

服务器死机的原因如下：

1、软硬件不兼容。三维软件和一些特殊软件，在有的微机上不能正常启动甚至安装，可能就有软硬件兼容方面的问题。

2、某些软件程序不是标准化的，不能先加载并运行，而是先运行，会导致系统管理混乱。 Beta软件在某些方面不够稳定，使用后，可能会导致系统无法启动。

3、在小内存的情况下，运行占用大内存的应用程序很容易崩溃。因此，需要在运行这些程序时保存当前正在使用的文件。

4、该软件存在冲突或不兼容。在安装某些软件之前，系统可以正常工作。安装后系统异常时，问题可能是由软件引起的。当运行不同的软件时，有时会发生冲突和不兼容，或者防病毒软件中存在一些小错误。只需关闭或卸载该软件即可。

这说明这次事故，是真的b站自己搞出来的事故。跟什么外星人，外国网安入侵啥的毫无关系

1、这次事故其实有很多点可以挖掘的比如断电后，为什么备用电源没有让机房的设备继续运作，b站机房管理有多弱可见一斑，再深挖比如，为什么b站登不上去后，会影响到a站，豆瓣甚至是晋江。从这几点深度挖掘可以发现。

2、b站的核心用户已从普遍的二次元男性观众，潜移默化的转变成了女性用户并且随着b站的崛起，分食了豆瓣和晋江的用户所以未来针对广告投放方面，可以针对女性用户投放，可能回报会更高。

3、再其次是b站这次崩了，微博，知乎的头条全是b站可见几个平台交叉用户非常的多，但微博和知乎并没有被b站的用户给冲击的网站进不去多少说明了这俩平台自身硬件实力方面，是足以承载b站用户的。

B站为服务器崩溃致歉：将赠送所有用户1天大会员

1、TechWeb7月15日消息，7月13日晚间，B站的部分服务器机房发生故障，造成网站、APP，小程序等全部无法访问，时间长达一个小时，在网上引发热议。

2、为了补偿广大用户，B站在官微宣布，将会赠送所有用户1天大会员，然后，很多用户忘记了B站曾经崩了的烦恼，开始寻思“这一天看什么最值”。

3、但是很快有用户发现，B站赠送的大会员被开启了自动续费，而且还是默认花呗续费，必须手动解约才行，这下网友又炸了，纷纷吐槽B站套路深。

4、对此，B站回应称，因赠送的会员活动触发原有的代扣续费功能导致自动续费扣款的情况，会在3个工作日内全额退款且不会再次发生。

一个项目上线了两个月，除了一些反馈的优化和小Bug之外，项目一切顺利；前期是属于推广阶段，可能使用人员没那么多，当然对于项目部署肯定提前想到并发量了，所以早就把集群安排上，而且还在测试环境搞了一下压测，绝对是没得问题的；但是，就在两个月后的一天，系统突然跑的比乌龟还慢，投诉开始就陆续反馈过来了。

经过排查，原来是频繁执行一条耗时100ms的SQL导致，100ms感觉不长，但就是把系统搞崩了，具体细节如下。

项目采用ABP进行开发，集成统一的认证中心(IDS4)，部分数据对接第三方系统，拆分后的这个项目架构相对简单。

考虑并发量不高，就算是高峰期也不会超过1000，于是就搞了个单台的数据库服务器(MySQL)，测试环境中经过压测，完全能抗住。

上线时，由于线上资源的关系，DB服务器的配置没有按测试环境的标准来分配，相关人员想着后续看情况进行补配。上线推的比较紧，简单评估了配置风险，初步判断没啥大问题，于是就推上线了。

相关技术栈：ABP、IdentityServer4、Autofac、AutoMapper、QuartzNET、EF Core、Redis、MySQL等，这都不重要，重要的是100ms的SQL把系统搞崩了。

由于系统相对不大，并没有把分布式日志、调度监控，性能监控集成上去。

上线期间，前期处于使用推广阶段，一切正常。两个月后的一天，系统处于使用高峰时段，突然陆续收到反馈：系统有点卡！！！于是赶紧进行排查。

由于系统已经是集群部署的，慢这个问题首先怀疑是数据库服务器，于是让DBA的同事排查了一下，没有锁，只是有大量事务等待提交(waiting for handler commit)，通过如下命令可查的：

看到都是插入审计日志记录导致，一看日志记录频率，差不多一秒500条记录。DBA同事说可能是记录插入频繁导致，此时CPU已经爆到100%了，为了快速解决问题，于是就赶紧关掉了一些不必要的日志记录。

这么一改，稍微降了一点，没有事务提交的记录，系统勉强可以撑着用，但是CPU还是在85%~97%波动；

看到这种情况，当然还是不放心，继续排查。 中间有对服务器的配置产生过怀疑，但非常肯定的是这不是主要原因，于是和DBA的同事继续排查。

系统虽然可以正常使用，但时不时的也看看监控屏，CPU一直处于高水位状态，还是有点慌的，因为一有问题，信息和电话都要爆。

突然DBA同事发现有一个单表查询的SQL执行比较频繁，于是单独拿出来试了一下，查询时间150ms左右，这个表的数据量不大，8万左右，但没有加任何索引，因为想着数据量不大，查询时长还可接受，所以当时就没有加相关索引。

定位到这条SQL后，想到的第一步就是增加索引，在测试环境上试了一把，执行效率直接飞速提高到1ms；效果如下：

所以和DBA同事达成一致意见，在生成环境上增加复合索引( 创建索引一定要注意字段顺序 )，在中午时候，系统使用频率不太高，于是就在生成上快速加了索引，我去，CPU一下降到了20%以内，意不意外；就算在使用高峰期，也没超过20%，通过zabbix工具监控看到CPU的效果：

问题算是解决了，总算松了一口气。

这里有个问题： CPU都爆了为什么没有报警提醒，这块DBA同事正在排查相关配置。这里发现CPU爆了，还是无意的远程到服务器，发现很卡，一看CPU才知道爆了。

系统虽小，问题不大，但其实暴露的问题还是挺多。

这次线上小事故暂时分享到这，因为项目不大，所以没有做那么多监控，但以下建议，小伙伴可以参考一下：

文章来自>