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