运维异常事件处理（发生异常事件的处理）

本篇文章给大家谈谈运维异常事件处理，以及发生异常事件的处理对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享运维异常事件处理的知识，其中也会对发生异常事件的处理进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、微服务异常的三种场景和处理方法
• 2、在服务过程中发现异常如何处理概要？
• 3、异常处理的3原则是
• 4、服务器异常怎么办
• 5、运维工程师的工作内容

微服务异常的三种场景和处理方法

异常的三种场景：

1、服务僵死，微服务发生OOM之类的错误，导致微服务无法继续提供服务

2、服务性能差，微服务内部事务处理慢，导致大量CloseWait连接

3、服务异常，节点事务处理失败比率太高

三种场景的运维监控：

第一种，监控日志OOM错误、监控JVM内存使用情况（jstat）指令

第二种，监控网络连接CloseWait状态连接数，超出一定的比率，该节点评估为问题节点，监控事务处理日志，如果大量超出预期，判定为问题节点

第三种，统计事务处理日志，应用错误类型的事务失败的比率统计，超出容忍则判定为失败节点

三种场景的运维处理：

Step1、隔离微服务，一旦判定为失败节点立即隔离该微服务，SpringCloud直接修改该微服务在Eureka中的状态即可 curl -X PUT http://eurekaserver:port/microservice/xxxxx/status?value=OUT_OF_SERVICE

Step2、保存现场，对于OOM类型的错误尤其重要，使用命令包括：jmap、jstack、kill -3等

Step3、告警和处理（我们还是人工处理的）

在服务过程中发现异常如何处理概要？

在专栏前面我讲过，单体应用改造成微服务的一个好处是可以减少故障影响范围，故障被局限在一个微服务系统本身，而不是整个单体应用都崩溃。那么具体到一个微服务系统，如果出现了故障，应该如何处理呢？
首先，我先来带你回顾一下微服务系统可能出现故障的种类，主要有三种故障。
集群故障。根据我的经验，微服务系统一般都是集群部署的，根据业务量大小而定，集群规模从几台到甚至上万台都有可能。一旦某些代码出现 bug，可能整个集群都会发生故障，不能提供对外提供服务。
单 IDC 故障。现在大多数互联网公司为了保证业务的高可用性，往往业务部署在不止一个 IDC。然而现实中时常会发生某个 IDC 的光缆因为道路施工被挖断，导致整个 IDC 脱网。
单机故障。顾名思义就是集群中的个别机器出现故障，这种情况往往对全局没有太大影响，但会导致调用到故障机器上的请求都失败，影响整个系统的成功率。
在我的实践过程中，这三种故障都经常遇到，因此相应的处理手段也可谓驾轻就熟，下面就把我应对故障的实战经验分享给你，希望对你有所帮助。
集群故障
一般而言，集群故障的产生原因不外乎有两种：一种是代码 bug 所导致，比如说某一段 Java 代码不断地分配大对象，但没有及时回收导致 JVM OOM 退出；另一种是突发的流量冲击，超出了系统的最大承载能力，比如“双 11”这种购物活动，电商系统会在零点一瞬间涌入大量流量，超出系统的最大承载能力，一下子就把整个系统给压垮了。
应付集群故障的思路，主要有两种：限流和降级。
1. 限流
顾名思义，限流就是限制流量，通常情况下，系统能够承载的流量根据集群规模的大小是固定的，可以称之为系统的最大容量。当真实流量超过了系统的最大容量后，就会导致系统响应变慢，服务调用出现大量超时，反映给用户的感觉就是卡顿、无响应。所以，应该根据系统的最大容量，给系统设置一个阈值，超过这个阈值的请求会被自动抛弃，这样的话可以最大限度地保证系统提供的服务正常。
除此之外，通常一个微服务系统会同时提供多个服务，每个服务在同一时刻的请求量也是不同的，很可能出现的一种情况就是，系统中某个服务的请求量突增，占用了系统中大部分资源，导致其他服务没有资源可用。因此，还要针对系统中每个服务的请求量也设置一个阈值，超过这个阈值的请求也要被自动抛弃，这样的话不至于因为一个服务影响了其他所有服务。
在实际项目中，可以用两个指标来衡量服务的请求量，一个是 QPS 即每秒请求量，一个是工作线程数。不过 QPS 因为不同服务的响应快慢不同，所以系统能够承载的 QPS 相差很大，因此一般选择工作线程数来作为限流的指标，给系统设置一个总的最大工作线程数以及单个服务的最大工作线程数，这样的话无论是系统的总请求量过大导致整体工作线程数量达到最大工作线程数，还是某个服务的请求量超过单个服务的最大工作线程数，都会被限流，以起到保护整个系统的作用。
2. 降级
什么是降级呢？在我看来，降级就是通过停止系统中的某些功能，来保证系统整体的可用性。降级可以说是一种被动防御的措施，为什么这么说呢？因为它一般是系统已经出现故障后所采取的一种止损措施。
那么降级一般是如何实现的呢？根据我的实践来看， 一种可行的方案是通过开关来实现。
具体来讲，就是在系统运行的内存中开辟一块区域，专门用于存储开关的状态，也就是开启还是关闭。并且需要监听某个端口，通过这个端口可以向系统下发命令，来改变内存中开关的状态。当开关开启时，业务的某一段逻辑就不再执行，而正常情况下，开关是关闭的状态。
开关一般用在两种地方，一种是新增的业务逻辑，因为新增的业务逻辑相对来说不成熟，往往具备一定的风险，所以需要加开关来控制新业务逻辑是否执行；另一种是依赖的服务或资源，因为依赖的服务或者资源不总是可靠的，所以最好是有开关能够控制是否对依赖服务或资源发起调用，来保证即使依赖出现问题，也能通过降级来避免影响。
在实际业务应用的时候，降级要按照对业务的影响程度进行分级，一般分为三级：一级降级是对业务影响最小的降级，在故障的情况下，首先执行一级降级，所以一级降级也可以设置成自动降级，不需要人为干预；二级降级是对业务有一定影响的降级，在故障的情况下，如果一级降级起不到多大作用的时候，可以人为采取措施，执行二级降级；三级降级是对业务有较大影响的降级，这种降级要么是对商业收入有重大影响，要么是对用户体验有重大影响，所以操作起来要非常谨慎，不在最后时刻一般不予采用。
单 IDC 故障
在现实情况下，整个 IDC 脱网的事情时有发生，多半是因为不可抗力比如机房着火、光缆被挖断等，如果业务全部部署在这个 IDC，那就完全不可访问了，所以国内大部分的互联网业务多采用多 IDC 部署。具体来说，有的采用同城双活，也就是在一个城市的两个 IDC 内部署；有的采用异地多活，一般是在两个城市的两个 IDC 内部署；当然也有支付宝这种金融级别的应用采用了“三地五中心”部署，这种部署成本显然高比两个 IDC 要高得多，但可用性的保障要更高。
采用多 IDC 部署的最大好处就是当有一个 IDC 发生故障时，可以把原来访问故障 IDC 的流量切换到正常的 IDC，来保证业务的正常访问。
流量切换的方式一般有两种，一种是基于 DNS 解析的流量切换，一种是基于 RPC 分组的流量切换。
1. 基于 DNS 解析的流量切换
基于 DNS 解析流量的切换，一般是通过把请求访问域名解析的 VIP 从一个 IDC 切换到另外一个 IDC。比如访问“www.weibo.com”，正常情况下北方用户会解析到联通机房的 VIP，南方用户会解析到电信机房的 VIP，如果联通机房发生故障的话，会把北方用户访问也解析到电信机房的 VIP，只不过此时网络延迟可能会变长。
2. 基于 RPC 分组的流量切换
对于一个服务来说，如果是部署在多个 IDC 的话，一般每个 IDC 就是一个分组。假如一个 IDC 出现故障，那么原先路由到这个分组的流量，就可以通过向配置中心下发命令，把原先路由到这个分组的流量全部切换到别的分组，这样的话就可以切换故障 IDC 的流量了。
单机故障
单机故障是发生概率最高的一种故障了，尤其对于业务量大的互联网应用来说，上万台机器的规模也是很常见的。这种情况下，发生单机故障的概率就很高了，这个时候只靠运维人肉处理显然不可行，所以就要求有某种手段来自动处理单机故障。
根据我的经验，处理单机故障一个有效的办法就是自动重启。具体来讲，你可以设置一个阈值，比如以某个接口的平均耗时为准，当监控单机上某个接口的平均耗时超过一定阈值时，就认为这台机器有问题，这个时候就需要把有问题的机器从线上集群中摘除掉，然后在重启服务后，重新加入到集群中。
不过这里要注意的是，需要防止网络抖动造成的接口超时从而触发自动重启。一种方法是在收集单机接口耗时数据时，多采集几个点，比如每 10s 采集一个点，采集 5 个点，当 5 个点中有超过 3 个点的数据都超过设定的阈值范围，才认为是真正的单机问题，这时会触发自动重启策略。
除此之外，为了防止某些特殊情况下，短时间内被重启的单机过多，造成整个服务池可用节点数太少，最好是设置一个可重启的单机数量占整个集群的最大比例，一般这个比例不要超过 10%，因为正常情况下，不大可能有超过 10% 的单机都出现故障。
总结
今天我们探讨了微服务系统可能出现的三种故障：集群故障、单 IDC 故障、单机故障，并且针对这三种故障我给出了分别的解决方案，包括降级、限流、流量切换以及自动重启。
在遇到实际的故障时，往往多个手段是并用的，比如在出现单 IDC 故障，首先要快速切换流量到正常的 IDC，但此时可能正常 IDC 并不足以支撑两个 IDC 的流量，所以这个时候首先要降级部分功能，保证正常的 IDC 顺利支撑切换过来的流量。
而且要尽量让故障处理自动化，这样可以大大减少故障影响的时间。因为一旦需要引入人为干预，往往故障处理的时间都得是 10 分钟以上，这对大部分用户敏感型业务的影响是巨大的，如果能做到自动化故障处理的话，可以将故障处理的时间降低到 1 分钟以内甚至秒级别，这样的话对于用户的影响最小。
思考题
上面我提到为了避免单 IDC 故障导致服务不可用情况的发生，服务需要采用多 IDC 部署，这个时候就要求服务依赖的数据也需要存储在多个 IDC 内，这样势必会带来数据一致性的问题，你有什么解决方案吗？

异常处理的3原则是

异常处理的3原则是：

1、能处理就早处理，抛出不去还不能处理的就想法消化掉或者转换为RuntimeException处理。因为对于一个应用系统来说，抛出大量异常是有问题的，应该从程序开发角度尽可能的控制异常发生的可能。

2、对于检查异常，如果不能行之有效的处理，还不如转换为RuntimeException抛出。这样也让上层的代码有选择的余地――可处理也可不处理。

3、对于一个应用系统来说，应该有自己的一套异常处理框架，这样当异常发生时，也能得到统一的处理风格，将优雅的异常信息反馈给用户。

扩展资料：

各种编程语言在处理异常方面具有非常显著的不同点（错误检测与异常处理区别在于：错误检测是在正常的程序流中，处理不可预见问题的代码，例如一个调用操作未能成功结束）。某些编程语言有这样的函数：当输入存在非法数据时不能被安全地调用，或者返回值不能与异常进行有效的区别。

例如，C语言中的atoi函数（ASCII串到整数的转换）在输入非法时可以返回0。在这种情况下编程者需要另外进行错误检测（可能通过某些辅助全局变量如C的errno），或进行输入检验（如通过正则表达式），或者共同使用这两种方法。

通过异常处理，我们可以对用户在程序中的非法输入进行控制和提示，以防程序崩溃。

从进程的视角，硬件中断相当于可恢复异常，虽然中断一般与程序流本身无关。

从子程序编程者的视角，异常是很有用的一种机制，用于通知外界该子程序不能正常执行。如输入的数据无效（例如除数是0），或所需资源不可用（例如文件丢失）。如果系统没有异常机制，则编程者需要用返回值来标示发生了哪些错误。

参考资料来源：百度百科——异常处理

服务器异常怎么办

造成服务器异常的原因
有好多种
1、服务器所在的机房设备出现故障
2、用户操作不当
3、病毒侵害
4、服务器故障
5、网络故障
二、服务器常见的异常问题及解决办法
1、机房设备故障引发的服务器不能正常运行
在机房配备专业人员做好日常管理和维护，及时检查和购买新的设备或者服务器。
2、用户操作不当引发的异常
公司要雇用专业人员管理和维护好服务器，降低出现故障的几率，以便第一时间能够及时处理问题，降低风险，减少损失。
3、网站打不开、被跳转、网站显示错误等
这时候可以下载专业的正版查毒软件，对电脑进行定期的全面病毒查杀，以绝后患。
4、用户无法打开网页
出现这种问题，可以耐心等候一段时间再进行再次访问，也可以多刷新几遍网页试试，并赶紧对服务器进行修复。
5、被DNS劫持出现的网络故障
这种情况是电脑上的其他应用都可以正常运行，但是网站却打不开，很有可能就是网站被DNS劫持了，需要重新设置或修改DNS地址。
6、系统蓝屏、频繁死机、重启、反映速度迟钝
服务器的结构与普通电脑的构成是十分相似的，出现这种情况是感染了病毒引起的，也有可能是系统漏洞、软件冲突、硬件故障等原因造成的。遇到这种问题就要及时杀毒，修复系统漏洞和硬件故障，清理缓存垃圾。
7、远程桌面连接超出最大连接数
如果登录后忘记注销服务器默认允许的2个连接，而是直接关闭远程桌面，这种时候可能就要重启服务器，并且是在高峰期的话，就很容易造成损失。这种异常问题，就要利用“mstsc/console”指令进行强行登陆，具体操作就是打开“运行”框，输入“mstsc/v:xxx.xxx.xxx.xxx(服务器IP)/console”，即可强行登陆到远程桌面。
8、出现无法删除的文件
如果这些无法删除的文件还在运行中，可以重启电脑，然后删除。另一种办法是，运行CMD，输入“arrtib-a-s-h-r”和想要删除的文件夹名，最后输入“del”，这样想要删除的文件夹即可删除，但是运行该命令后无法恢复，要谨慎使用。
9、系统端口隐患
对于服务器来说，首先要保证的就是它的稳定性和安全性。因此，我们只要保留的是服务器最基本的功能就可以了，声卡一般都是默认禁止的。我们不会用到很多功能，也不需要很多的端口支持。这时候，我们就关掉一些不必要的、风险大的端口，例如3389、80等端口，用修改注册表的方式将其设置成不特殊的秘密端口，这样可以消除服务器端口的安全隐患。

运维工程师的工作内容

在软件产品的整个生命周期中运维工程师都需要适时地参与并发挥不同的作用运维异常事件处理，因此运维工程师的工作内容和方向非常多运维异常事件处理：

1、事件管理：目标是在服务出现异常时尽可能快速的恢复服务运维异常事件处理，从而保障服务的可用性运维异常事件处理；同时深入分析故障产生的原因运维异常事件处理，推动并修复服务存在的问题，同时设计并开发相关的预案以确保服务出现故障时可以高效的止损。在这方面主要工作内容有：

2、问题发现：设计并开发高效的监控平台和告警平台，使用机器学习、大数据分析等方法对系统中的大量监控数据进行汇总分析，以及在系统出现异常的时候可以快速的发现问题和判断故障的影响。

3、问题处理：设计并开发高效的问题处理平台和工具，在系统出现异常的时候可以快速/自动决策并触发相关止损预案，快速恢复服务。

扩展资料：

前景

运维所涉及的知识面、专业点非常广，对从业人员素质也要求非常高，运维工作在大型互联网公司也越来越重要。随着互联网的高速发展、网站规模越来越大、架构越来越复杂，对网站运维工程师的需求也会越来越急迫，特别是对有经验的运维人才需求量大，而且是越老越值钱。

关于运维异常事件处理和发生异常事件的处理的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 运维异常事件处理的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于发生异常事件的处理、运维异常事件处理的信息别忘了在本站进行查找喔。