1、故障处理原则

故障处理的原则只有两个：

以恢复业务优先
及时升级

1.1、恢复业务优先

恢复业务优先是指，不管在任何情况下，也不管任何级别的故障，都要先做到恢复业务，这个和故障定位不同，也有很多人会产生歧义，觉得如果不找到问题的根源，如何能恢复业务，下面我举一个例子说明二者的差别：

如果 A 应用调 B 应用时，调用失败，这时我们要怎么做？

方法一，排查问题，寻找A到B之间会经过哪些环节，找到其中的出问题的环节，比如HA连接异常，进行重启或者扩容恢复。

方法二，从A应用的服务器去ping B应用的网络，如果端口，网络联通，那么直接绑定B服务器的hosts。

一般而言，第二种方法时间会短，如果A和B之间是跨机房访问，那么方法一排查时间会更长，虽然破坏了A到B之间的架构平衡，但是能马上见效，这就是我们所说的以恢复业务优先。

1.2、及时升级

这个比较好理解，任何故障在发生时，对故障的影响任何人只能做一个简单的预测，所以要及时升级到你的领导那里，让他掌握第一手的信息，协调资源，如果有如下情况，那么必须马上上升：

有明确业务影响，例如PV，UV，购物车，订单或者支付等业务指标波动。
非常重要的业务的严重以上的告警故障，比如北斗核心业务，核心的组件等。
处理时效明显超长（时效参考故障处理时效定义）。
有高级别领导，监控中心或者客服已经关注到这个故障。
很明确超出了自己的能力范围。

注意：任何运维故障，运维的领导必须是第一个知道的人，如果他从别的人或者部门中知道这个故障，那么就很被动，而且是故障处理人失职表现。

2、故障处理方法论

故障处理一般会分为三个阶段，故障前，故障中和故障后，故障前是指故障的定位分析，故障中是指故障处理过程，故障后是指故障总结，故障总结很重要，这个会单独放到一章，故障定位很杂，以后会单独去写，这里主要讲一下故障中的一些运维常用的方法。

2.1、故障服务来看运维处理故障方法

如果从故障服务来看，运维恢复业务最重要的三个方法是：重启，隔离和降级。

重启：重启包括服务重启和服务器重启（os重启）两种，在发生故障中，任何中涉及到的环节，都可以重启来完成，重启的一般顺序是，故障对象>故障对象上游>故障对象下游，一般离故障对象越远，重启顺序越靠后。

以今天的 RabbitMQ 故障为例：当已经知道 RabbitMQ 发送消息失败的时候，那么就要对它进行重启，如果还没生效，那么则对他上游（消息生产者）进行重启，还不行就对下游，消息消费方进行重启。

这里需要注意的是，千万千万不要想着去定位，比如发现重启的对象指标都正常，则不进行重启，时刻谨记，是在恢复业务，不是在定位故障。

隔离：隔离是指对故障的对象从集群中抽离的过程，目的是让故障对象不在提供服务，隔离的方法包括以下两种，按照常用频率排序：

调整上游权重为零，如果架构上有自检测机制，那么也可以直接停止故障对象的服务，让上游健康探测时效。
通过绑定hosts或者配置路由的方式，绕开故障对象。比如智能路由管理域关闭某一条线路。

这里需要注意的是，防止雪崩效应。

降级：降级是指为了防止产生更大的故障所采取的一种预案，一般而言，降级一定不是当下生产的给用户的最优状态，即使没有技术影响，也会或多或少带来一些业务的影响，比如唯品花降级等，虽然用户可以通过其他渠道进行支付，但会带来不好的用户体验和一些用户影响。

降级不仅仅是运维的事情，要联合业务研发或者说推动业务研发一起去实施，孙子兵法有云：为将者，未虑胜，先虑败，因此做任何一个项目时，首要考虑的不是这个项目能取得多少业绩，而是要考虑的是，如果出现异常怎么办？

以 CDN 管理为例：

我们要求开发提供的预案有：

任何时候，核心域，都可以更换到备用域名，并且是分钟级生效。
核心域必须有重试机制，当访问一个域名失败时，APP能够直接回源到源站。
前端业务重试提供开关功能，可以一键关闭重试机制（主要担心源站会被重试打垮）

项目如此，核心应用和组件也要如此，作为应用负责人，必须要考虑的是，如果这个对象发生重大故障时，是否有预案可以使用，并且要把这些预案触发条件，执行人等都要明确下来。

上述操作方法，尤其是重启和隔离有一个重要的前提，那就是，对象必须是无状态的，如果需要开发重试，那么要求必须是幂等的。对象无状态除非是非常特殊的业务，可以临时存在外，其余是不可以的，所以生产上对象应该只有三种状态：

无状态，这个要占大多数
临时有状态，需要整改
有状态，少量的

2.2、从故障影响方去看运维故障处理方法

一个故障发生后，影响方会分为两类：外部用户和内部用户

2.2.1.外部用户

外部用户的处理会比较麻烦，处理的思路是，如何把外部用户转变成内部用户，比如，一个供应商打不开公司的网站，这时要做的是有两个方面：

自己在本地模拟是否可以重现，如果可以重现，那么就不是用户到IDC之间公网问题，是内部系统问题，那么变成内部用户处理。
如果自己在本地模拟不能重现，那么多找几个内部用户模拟，防止自己环境问题，同时，让用户进行hosts绑定到其他入口，排除DNS，一些外网链路问题，如果这时用户在绑定hosts后，访问正常，那么恢复业务，同时可以确认大概率是外部问题。

如果上述两个方面都不行，那么就比较麻烦了，这时要收集一些必要的外部用户信息才能进行处理，比如出口IP，所用客户端版本等等，这里建议收集信息有个模版，一次性完成，因为外部用户处理时效往往会花在沟通成本上。

2.2.2 内部用户

内部用户包括内部应用自身调用问题和内部使用人员发现问题，这时的操作方法参考2.1来处理。

2.3、故障处理过程中的组织架构

故障处理一般需要有三拨人同时行动

故障处理者，他们的职责就是尽快恢复业务。
故障定位者，他们的职责是当故障处理者方法失效或者需要查找问题根因时，解决故障。
信息传递者，他们的职责是对故障处理，故障定位传递有效信息，同时对外部传递故障进展信息。

往往运维这三类人不会同时存在，比如在凌晨值班时，只需要故障处理者处理即可，恢复业务后，第二天由故障定位者去找根因及优化措施。

当然，三拨人可以复用。

3、故障总结

故障总结是个大活，每一次故障发生，都要尽量从根源去解决，同时避免发生重复故障和类似故障，PDCA，一次次改进。由于故障总结会涉及到故障的定责，所以这里需要写一些注意事项，尤其是对待故障中蛮不讲理的人。降级，从某种角度来说，是运维的最后保命手段，必须要注意。

Linux学习总结（58）——生产环境运维故障处理指南相关推荐

Linux学习总结（41）——运维不仅仅是Linux
运维不仅仅是懂Linux就行,因为还有一大部分的Windows运维,最近看一个报道说,windows的服务器占了47.71%.嗯,向windows运维人员致敬.当然我们这篇文章不是说运维除了懂Linu ...
S2D 真实机房生产环境运维排错（2）
前文讲到需要对机房进行S2D的排查,那么我们应该首先了解一下什么是S2D. 简单来讲,S2D是Server 2016中出现的SDS软件定义存储名词,全称叫storage spaces direct , ...
mysql生产环境运维方案_[MySQL生产环境] Innodb存储引擎内存报警问题处理过程
1 不停的收到email报警,内存值超过阀值80%了. 2 top下,mysqld进程确实占据了77.5%,再加上一些其他的辅助进程,内存usage到了81%也可以理解. [xxx@00903 5.5 ...
S2D 真实机房生产环境运维排错
近日响应群友所托,协助他们云主机机房的S2D环境排错,修复存储方面IOPS写入不正常的问题. 存储方面主要问题体现于: IOPS随机写入测试不正常,只有1-2M/S速度. 节点硬件: DELL 730 ...
阿里测试环境运维及研发效率提升之道
摘要: 生产环境最关注的就是稳定,测试环境更关注的是研发效率,如何从一行代码最快的保证质量发到线上去,这个是我们测试环境最关注的.在全球运维大会上,阿里巴巴研发效能事业部运维中台技术专家--刘湘疆(青 ...
Linux操作系统——Linux可视化管理-webmin 和 bt 运维工具
文章目录 25 Linux 可视化管理-webmin 和 bt 运维工具 25.1 webmin 25.1.1 基本介绍 25.1.2 安装webmin&配置 25.1.3 简单使用演示 25 ...
Linux 可视化管理-webmin 和 bt 运维工具
Linux 可视化管理-webmin 和 bt 运维工具 webmin Webmin 是功能强大的基于 Web 的 Unix/linux 系统管理工具.管理员通过浏览器访问 Webmin 的各种管理功 ...
生产可运维的云原生本地存储系统 HwameiStor 入选 CNCF 全景图
近日,CNCF(云原生计算基金会)[1] 发布了最新版的云原生全景图[2].「DaoCloud 道客」自主开源的云原生本地存储系统 HwameiStor,被收录在 CNCF 云原生全景图中的 RunT ...
《PowerShell V3——SQL Server 2012数据库自动化运维权威指南》——1.2　在你开始之前：使用SQL Server和PowerShell工作...
本节书摘来自异步社区出版社<PowerShell V3-SQL Server 2012数据库自动化运维权威指南>一书中的第1章,第1.2节,作者:[加拿大]Donabel Santos,更 ...

Linux学习总结（58）——生产环境运维故障处理指南