- 综合排序
- 最热优先
- 最新优先
- 来自专栏FunTester
线上故障与故障测试
无论是在线购物、移动支付，还是社交媒体和云端办公，都依赖于稳定的线上系统。然而，随着系统规模的不断扩大和复杂度的提升，线上故障的发生频率也随之增加。 线上故障 线上故障是指线上系统在运行过程中出现的异常情况，导致系统无法正常提供服务或服务质量下降。这种异常可能由多种因素引起，包括硬件故障、软件缺陷、人为失误以及外部攻击等。 故障测试好处 故障测试是预防线上故障的关键手段。线上故障的不可预测性：线上系统在运行过程中可能面临各种不可预见的故障，例如硬件故障、软件缺陷、网络波动或外部攻击。 实际故障的反馈作用：每一次线上故障的发生都为故障测试提供了真实的案例和反馈。通过分析故障原因，可以进一步完善故障测试的场景和方法。持续改进测试策略：线上故障的多样性和复杂性要求故障测试不断演进。 线上故障与故障测试之间的关系可以概括为“预防与反馈”的循环。故障测试通过模拟故障场景，帮助预防和减少线上故障的发生；而线上故障则为故障测试提供了真实的案例和改进方向。
59610编辑于 2025-02-19 - 来自专栏从入门到出门
线上故障排查方案
Java常见线上问题总结绝⼤多数Java线上问题从表象来看通常可以归纳为4个方面：CPU、内存、磁盘、网络。 遇到问题⽆法在线上 debug，难道只能通过加⽇志再重新发布吗？线上遇到某个⽤户的数据处理有问题，但线上同样⽆法 debug，线下⽆法重现！是否有⼀个全局视⻆来查看系统的运⾏状况？
1.1K20编辑于 2022-08-01 - 来自专栏方丈的寺院
线上故障处理手册
摘要 通常处理线上问题的三板斧是 重启-回滚-扩容，能够快速有效的解决问题，但是根据我多年的线上经验，这三个操作略微有些简单粗暴，解决问题的概率也非常随机，并不总是有效。 处理手段 处理手段无非是重启、扩容、回滚、限流、降级、hotfix 以下是我一般处理线上问题的流程 ? 主要分为四大块 step1: 是否有变化 和造成大部分车祸的原因是由于变化导致一样，线上故障通常也是由于变化导致的。外部的变化很难感知到，但是服务自身的变化很容易感知，当有服务发布、配置变更等变化时。 以下是常用的一些监控项 类型 监控项 主机状态 磁盘使用率>85 主机状态 5分钟load > 核数*1.5 主机状态 5分钟内存使用率 > 80 主机状态 5分钟CPU > 50 API 5分钟API 错误率>0.1 SQL 慢查询 耗时>100ms 日志 1分钟错误数>10 日志 5分钟错误数>50
1.4K20发布于 2020-06-03 - 来自专栏程序员升级之路
线上故障处理实践
一、背景 最近公司一个系统发生线上故障，系统架构为C/S的，客户端是APP；系统的功能有：联系人、短信、通话记录等，每个业务都有备份、恢复的功能，即用户可以在APP内备份自己的联系人、短信、通话记录至服务端 和Hbase，Mysql存一些元数据，真正的业务数据存放在Hbase中； 该系统经过几次接手，没有人能对系统逻辑理解很清楚； 该系统从去年下半年开始一直偶尔有500的报错，但每次重启就好了，本次发生故障后 因为Hbase扩容后需要Rebalance，这个过程需要一段时间，为了尽量减少对线上影响，开始在nginx上限流，具体是通过access_by_lua_file指令进行限流，代码如下： local
78830发布于 2020-09-11 - 来自专栏Ken的杂谈
线上故障处理指南
一、最重要的三件事 1、止损 2、止损 3、止损 故障损失≈单位时间内的损失*故障时长 尽快恢复，是止损的最佳办法，至于查找根本原因，或者从根本上解决问题，那是服务恢复可用后的事情 二、故障处理三板斧 ，使用「作战室」会议室现场沟通，或者在主要影响团队附近开站立会 「故障信息同步群」是为了帮助我们第一时间同步故障信息，信息传递的及时&准确能为故障处理提供好的舆论基础 「作战室」可以帮助故障处理负责人协调各方协同处理故障 bug，XXX正在操作服务回滚，预计5分钟内恢复 五、故障处理流程参考 1、变更问题 配置/代码变更后产生的问题，首选回滚，恢复比排查Bug更重要 但一定要确认是否可以回滚，在某些情况下，如果因为问题 限流等手段能上就上，如果是触发了某个历史Bug，那就服务降级或者关闭入口，尽快的执行Bug修复工作了 4、下游依赖问题 如果是依赖的下游出现了问题，那么做的就是熔断、降级，然后等待下游恢复 六、总结 线上故障 ，无论大小都值得我们去总结，总结的内容可以包含且不仅限于：问题现象、影响范围、根本原因、时间线、改进措施等，其中尤其要关注的就是改进措施，一定要可落地执行，能够追踪进展，这样才能真正的帮助我们进步 线上稳定性保障是一个体系
1.7K10编辑于 2023-04-07 - 来自专栏洁癖是一只狗
面试-线上故障如何排查
面试经常会被问到java应用出现了问题,如何排查,主要使用下面几个命令基本都能解决
73420编辑于 2022-12-01 - 来自专栏嘉为动态
如何快速处理线上故障
1 概述 线上故障通常是指大规模的影响线上服务可用性的问题或者事件，通俗点讲就是：掉“坑”里了，这个“坑”就是线上故障！线上故障的处理过程可以形象地表达为：“踩坑”、“跳坑”、“填坑”、“避坑”。 线上故障处理的过程也一样，优先级从高到低，线上故障处理的目标如下： 跳坑 “跳坑”——快速恢复线上服务，或者将对线上服务的影响降到最低。 线上服务的可用性决定着服务者的客户利益，影响着公司的收益。 上述途径传递过来的信息仅仅只是线上故障苗头，并非一定就发生了大规模的线上故障，所以首先需要确认的是这是不是一次线上故障？还是只是个例生产问题？是否和本系统有关系？ 5 故障定位 一旦确定是线上故障后，我们需要快速定位故障点，找到问题原因，以便对症下药，快速排除故障。 8 线上故障处理的“后勤保障” 前面谈了线上故障处理的目标、思路和步骤，回过头来看下，要快速准确地定位和排除线上故障，需要很多基础设施支撑，它们是线上故障处理的“后勤保障”。
2.1K60发布于 2018-12-21 - 来自专栏不止思考
如何应对线上故障
线上故障是我们技术同学经常遇到，也是技术成长中经常要经历的事。从故障中我们可以吸取到很多教训，变得越来越有经验。 但是并不是每一个团队/技术同学在应对故障的处理方式上，都能做到合理和科学。 下面就从工作中遇到的实际情况，结合最近读陈皓文章心得，来聊一聊我对线上故障处理的看法。 即一旦发现线上故障，当前系统以及相关系统所对应的开发、运维、测试等方向，各抽调对口人，全都叫到线上去处理问题，各自排查各自模块/服务，如果排查自己负责的范围没有问题就可以在旁边待命，以备在需要的时候进行配合 我们平时大多数情况下是怎么做的呢，收到一个线上功能的错误报告，然后对应功能的前端同学开始排查，排查了半天，发现是后端接口不正常，将问题转到后端同学继续排查，后端同学经过一段时间排查后，发现是运维问题或者是依赖的其他模块的问题 这其实是另一个主题了，不过这里，我简单的提一下我的建议：对于线上事故，理应追究责任，但无需惩罚（特别严重的问题或特别不能容忍的错误以外），最重要的其实是做好善后工作，避免下次再犯，从根本上反思，刨根问底
1.3K20发布于 2018-08-31 - 来自专栏运维入门时间
如何快速应对线上故障
严重的线上故障一定是要协调各方资源一起排查，因为只有掌握了足够多的信息，才能做出解决问题的正确决策。 重启回滚 能重启解决的先重启，重启能更快的释放资源，快速恢复线上运行是首要任务，当然有条件的话最好能保留现场，把某台应用从负载中摘除，以便后续分析。重启不限于应用、虚拟机，还可能是数据库。 研发人员必看之神书5星级强烈推荐 《SRE Google 运维解密》 JAVA性能排查工具 推荐大家使用https://github.com/alibaba/arthas 3. 见过太多的故障相互推诿，不妨从故障角度出发借鉴蘑菇街赵成的复盘黄金三问： 故障原因有哪些？ 我们做什么、怎么做才能确保下次不会再出类似故障？ 以上就是今天的内容，应对线上故障的第一要素就是： 在现有可利用资源的基础上怎么做才能快速恢复 “简单粗暴”远胜于“严谨优雅”
94120编辑于 2022-05-25 - 来自专栏码农沉思录
JVM 线上故障排查基本操作
作者：莫那一鲁道 转载链接：https://www.jianshu.com/p/bca5a49db4b7 前言 对于后端程序员，特别是 Java 程序员来讲，排查线上问题是不可避免的。 今天的文章，就如我们的题目一样，讲的是基本操作，也就是一些排查线上问题的基本方法。为什么这么说呢？ 根据楼主的经验，YGC 5秒一次左右，每次不超过50毫秒，FGC 最好没有，CMS GC 一天一次左右。 而 GC 的优化有2个维度，一是频率，二是时长。 还有很重要的一点就是，线上环境一定要带上 GC 日志！！！ 总结 基于文章的标题，我们这个是基本操作，故障排查是说不完的话题，每个故障涉及的知识也都很多，因此，我们在学习了基本的排查之后，还需要学习更多事故排查技术，比如排查 IO，网络，TCP 连接等等。
1.1K40发布于 2019-11-12 - 来自专栏芋道源码1024
JVM 线上故障排查基本操作
原文地址：jianshu.com/p/bca5a49db4b7 前言 CPU 飚高 内存问题排查 总结 前言 对于后端程序员，特别是 Java 程序员来讲，排查线上问题是不可避免的。 今天的文章，就如我们的题目一样，讲的是基本操作，也就是一些排查线上问题的基本方法。为什么这么说呢？ 根据楼主的经验，YGC 5秒一次左右，每次不超过50毫秒，FGC 最好没有，CMS GC 一天一次左右。 而 GC 的优化有2个维度，一是频率，二是时长。 还有很重要的一点就是，线上环境一定要带上 GC 日志！！！ 总结 基于文章的标题，我们这个是基本操作，故障排查是说不完的话题，每个故障涉及的知识也都很多，因此，我们在学习了基本的排查之后，还需要学习更多事故排查技术，比如排查 IO，网络，TCP 连接等等。
60320发布于 2019-10-29 - 来自专栏IT运维技术圈
JAVA 应用线上故障排查手册
线上故障主要会包括 CPU、磁盘、内存（含JVM）以及网络问题，而大多数故障可能会包含不止一个层面的问题，所以进行排查时候尽量四个方面依次排查一遍。 184M 0% /run/user/0 overlay 50G 11G 37G 22% /var/lib/docker/overlay2/6d3ac4731796a1e5eb0408384051439ef0e04fc1b0da8352f962ac0de5f79961 11G 37G 22% /var/lib/docker/overlay2/356fa3e9b02cdb6249d63ee71f310083145f4e46b755b48f4c6b9e3312f5ed5b 1877103ed43f6dea45b98ad3f763d2d562b80e06125fa7b10350f7e42a16f408/mounts/shm overlay 50G 11G 37G 22% /var/lib/docker/overlay2/3dd57c5b2119b45901d6b022e7b38d9f45c3fb6472c983a5d9cb598943eb7a99 [root@VM_0_7_centos mblog]# pstree -p 26550 |wc -l 52 5）堆外内存 如果碰到堆外内存溢出，那可真是惨。
94820编辑于 2022-10-24 - 来自专栏一猿小讲
抓包神器 Wireshark，帮你快速定位线上网络故障（5）
Wireshark 就像网络世界的显微镜，我们可以在它的帮助下了解网络中发生的一切。
1.3K20发布于 2020-12-31 - 来自专栏架构之家
JAVA线上故障排查全套解决方案
线上故障主要会包括cpu、磁盘、内存以及网络问题，而大多数故障可能会包含不止一个层面的问题，所以进行排查时候尽量四个方面依次排查一遍。 使用率比较高的一些线程 然后将占用最高的pid转换为16进制printf '%x\n' pid得到nid 接着直接在jstack中找到相应的堆栈信息jstack pid |grep 'nid' -C5 ss命令，执行ss -lnt 上面看到Send-Q 表示第三列的listen端口上的全连接队列最大为5，第一列Recv-Q为全连接队列当前使用了多少。 我们在排查故障时候怎么确定有RST包的存在呢？当然是使用tcpdump命令进行抓包，并使用wireshark进行简单分析了。 在线上时，我们可以直接用命令netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'来查看time-wait和close_wait
80210编辑于 2022-07-12 - 来自专栏技术随笔心得
【线上故障】通过系统日志分析和定位
主要是不符合产品的需求逻辑，可能会影响用户体验 线上故障：这个阶段是最严重的，对公司的收益、用户体验都会造成影响，主要为服务不可用等 在本文的示例中，我们针对的第三个阶段，即线上故障进行定位和分析的一种方式 ，希望借助本文，能够对你的故障定位能力有一定的帮助。 当时第一反应是有人手动重启了，于是在组内群里问了下，没人动线上，看来问题比较麻烦。 3 == 1: use of reserved bit detected * bit 4 == 1: fault was an instruction fetch * bit 5 1 << 1, X86_PF_USER = 1 << 2, X86_PF_RSVD = 1 << 3, X86_PF_INSTR = 1 << 4, X86_PF_PK = 1 << 5,
1.7K20编辑于 2022-08-25 - 来自专栏捉虫大师
案例分享 | dubbo 2.7.12 bug导致线上故障
背景 最近某天的深夜，刚洗完澡就接到业务方打来电话，说他们的 dubbo 服务出故障了，要我协助排查一下。 电话里，询问了他们几点 是线上有损故障吗？——是 止损了吗？——止损了 有保留现场吗？ 发生故障时 B 服务有几台机器完全夯死，处理不了请求，剩余正常机器请求量激增，耗时增加，如下图（图一请求量、图二耗时） [img2.png] [img3.png] 问题排查 由于现场已被破坏，只能先看监控和日志 监控 除了上述监控外，翻看了 B 服务 CPU 和内存等基础监控，发现故障的几台机器内存上涨比较多，都达到了 80% 的水平线，且 CPU 消耗也变多 [img4.png] 这时比较怀疑内存问题，于是看了下 JVM 的 fullGC 监控 [img5.png] 果然 fullGC 时间上涨很多，基本可以断定是内存泄漏导致服务不可用了。 org.apache.dubbo.remoting.exchange.support.DefaultFuture$TimeoutCheckTask$$Lambda$674/1067077932@13762d5a
1.4K72发布于 2021-09-27 - 来自专栏Linyb极客之路
运维管理之线上故障处理原则
那么，我们需要对线上服务产生任何现象，哪怕是小问题，都要刨根问底，对任何现象都要遵循下面问题 为什么会发生 ？ 发生了该怎么应对 ？ 怎么恢复 ？ 怎么避免 ？ 应急目标 在生成环境发生故障时快速恢复服务，避免或减少故障带来的损失，避免或减少故障对客户的影响 应急原则 应第一时间恢复系统，而不是彻底解决呢问题，快速止损 明显资金损失时，要第时间升级，快速止损 指标要围绕目标 ，快速启动应急过程与止损方案 当前负责人不能短时间内解决问题，则必须进行升级处理 处理过程在不影响用户体验的前提下，保留现场 应急方法与流程 线上应急一般分为 6 个阶段 发现问题 定位问题 解决问题 对数据库的负载、慢查询、连接数等监控 对缓存的连接数、占用内存、吞吐量、响应时间等监控 消息队列的响应时间、吞吐量、负载、堆积情况等监控 定位问题 分析定位过程中先考虑系统最近发生的变化，需要考虑如下几方面 故障系统最近是否上过线 做了哪些事情，及时发生故障，也不会产生影响？ 改进措施 根据回顾问题提出的改进措施，以正式的项目管理方式进行统一管理，采用 SMART 原则来跟进 参考 分布式服务架构原理、设计与实战
2.3K30发布于 2018-07-26 - 来自专栏老张的求知思考世界
线上故障的正确打开方式
对技术同学来说，线上故障是一个绕不开的话题。 一方面，线上故障会极大的影响个人的绩效和心态；另一方面，处理线上故障也是很好的提升解决问题能力的机会。 处理线上故障的过程，是一个复杂的判断和筛选过程，而解决故障后沉淀的经验，对技术同学来说，是很宝贵的职场收获。 这篇文章，来聊聊应对线上故障比较通用的一些方法。 事前：发现故障 首先要明白的一点是：线上故障是无法避免的。 线上故障随时可能发生，且可能出现在任何环节，想要降低线上故障带来的影响，第一步就要尽可能快的发现故障，在出现故障苗头的时候就发现并解决。 同时，制定合理的流程、故障应急机制、线上稳定性预案，这样才能更好的保证线上服务的稳定性，将故障带来的影响控制在合理区间。
45330编辑于 2023-08-09 - 来自专栏微观技术
搞了个线上故障，被老板骂了....
这个标识可以没有什么特殊业务含义，client 端随机生成即可 3、服务端系统将唯一标识先尝试写入 Redis 缓存中，可以认为是加锁操作 4、加锁失败，说明请求还在处理，此次是重复请求，可以丢弃 5、 5、上层业务接口 @RestController @RequestMapping("/user") public class UserController { /** * 创建一个新的用户
42230编辑于 2022-12-29 - 来自专栏Java编程指南
「干货」Linux-Java线上故障全套路排查
Java常见线上问题 所有的Java线上问题从系统表现来看无非归咎于这几种：CPU，内存，磁盘，网络。比如CPU突然飙升赞满，内存溢出，网络异常，磁盘爆满等问题。 二. 之后我们需要使用 jstack pid |grep 'nid' -C5 –color 来查看上述进程中线程的堆栈信息。 找到对应线程的堆栈信息后看看具体是业务线程还是其他线程，比如gc线程。 总结 遇到线上问题千万不要慌乱，先将程序恢复正常后再慢慢排查问题。
1.1K21编辑于 2022-04-12
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号