- 综合排序
- 最热优先
- 最新优先
- 来自专栏SRE运维实践
故障自愈了解一下
故障自愈 越努力越孤单，好像这是一个宿命。。。 追求卓越从而导致不合群，慢慢的孤独久了就习惯了。。。 其实一个服务，一个进程，一个线程都是一样的，当一个服务能做到故障自愈，那么就会被人遗忘，一个自我能管理的服务是最好的，是最让人省心的。 用最简单的方式来演示故障自愈，以下是故障检测脚本： ? 在故障自愈中，主要有两个方面需要重点考虑： 1、 如何判断服务出现了故障，在上面的例子中，主要是通过发送http请求来进行判断，可能会有误判么？ 在程序上线的时候，就已经有了故障自愈，那么还要运维干啥。。。看日志？谁都会。。。。写程序的更加了解应用的架构。。。 梦想是美好的，现实是骨干的，所以故障自愈也不是一步到位的。。。
1.8K50发布于 2019-07-08 - 来自专栏运维笔记
shell脚本结合zabbix玩转故障自愈
shell脚本结合zabbix玩转故障自愈 ---- 收到zabbix故障报警,匹配相应的规则触发不同的自愈机制.当然这个脚本功能不仅仅如此. shell脚本结合zabbix玩转故障自愈 脚本作用 实现逻辑(Zabbix故障自愈) 脚本内容 使用示例 zabbix添加告警自愈脚本和相应参数 1. Actions设置 2. 监控url返回码,不正常时重启应用 脚本作用 利用zabbix实现故障自愈 http监控自愈 tcp端口监控自愈 微信/邮件消息通知 多方式远程批量执行 ...... 实现逻辑(Zabbix故障自愈) zabbix_server=>start: zabbix服务端触发告警脚本 self_recover=>operation: zabbix服务端告警(自愈脚本) analysis_alert_content 模拟故障后 ? 4. 触发报警和规则 ? 5. 自愈 ? 自定义规则,执行相应的恢复操作 其他自定义规则,可以根据相应的返回KEY，做相应的自愈操作。一切你想要自愈的操作都可以做到。
3.5K50发布于 2019-01-30 - 来自专栏杨建荣的学习笔记
Greenplum的segment故障自愈小试
在工作中，总是不可避免会碰到故障，最近Greenplum集群总是会时不时的抛出segment节点的问题，不过GP的高可用机制是比较完善的，数据segment节点出现故障，节点会从Primary切换到Mirror 所以就开始写脚本，写脚本的过程中刚好节点出现问题，就顺手拿来做了下故障自愈测试。 failed to connect ...' >> /tmp/gp_recovery.log echo >/home/gpadmin/recov 小结：这个简单的脚本算是拯救了自己的碎片时间，也通过这样的故障自愈让自己解放一下
1.4K20发布于 2019-11-11 - 来自专栏腾讯大讲堂的专栏
故障自愈——游戏运维的终极福音
有了故障自愈服务，上述这些问题基本都很好的解决了。 故障自愈能够帮助业务运维第一时间查明问题原因、并马上恢复故障，后续还能帮助运维输出阶段性待优化问题形成闭环管理。 可以说，告警收敛分析是故障自愈服务的关键部分。 故障自愈总体实现方案 故障自愈是一整套严谨的故障自动化处理服务，通过和网平、作业调度平台、配置管理中心、告警单据系统等诸多周边系统自顶至下的全流程打通，轻松的实现了发现告警、关联配置信息、智能告警收敛分析 Chapter 2 【故障自愈的应用场景】 故障自愈暨收敛分析服务说明 故障自愈所输出的服务，可以用一句话来概况——全自动的发现告警、分析告警、恢复故障。
2.8K80发布于 2018-02-11 - 来自专栏嘉为动态
故障自愈组合套餐：复杂故障的自动化处理方案
今年小A部署了蓝鲸智云社区版，研究了蓝鲸监控和故障自愈，针对往年常出现的故障，设置好了监控->自愈的恢复链路。 Ping告警刚产生没几分钟，故障自愈就已经从资源池中拉取了备用机替换了故障机，保障了业务的正常运行，小A也愉快地在家里度过新年。 下面就给大家分享小A的故障自愈组合套餐配置方法。 第二步：配置组合套餐，并接入故障自愈，接入故障自愈这里选择REST默认分类是为了方便触发告警，实际应用选择ping不可达告警类型。 ? ? 第三步：触发告警，完成自愈 1. 回到故障自愈中，查看自愈详情，也可以点击状态，查看执行详情。 ? ? 创建标准运维故障处理流程 ? 2. 在故障自愈创建自愈套餐，选择自愈流程 ? 3. 接入自愈，简单3步即可完成标准运维套餐的使用 ?
2.8K30发布于 2019-03-15 - 来自专栏运维开发故事
k8s故障检测与自愈（一）
组件故障 组件故障可以认为是节点故障的子类，只是故障来源是K8S基础组件的一部分。 DNS故障：6个DNS Pod中的2个出现无法解析外部DNS名称的情况。后果是大量线上业务因域名解析。 CNI故障：少数几个节点的容器网络和外部断开，节点访问自身的Pod IP没有问题，但是其它节点无法访问故障节点的Pod IP。 可以参考： 使用KubeNurse进行集群网络监控 乔克，公众号：运维开发故事使用KubeNurse进行集群网络监控 节点故障 硬件错误: CPU/Memory/磁盘故障 kernel问题: kernel deadlock/corrupted file systems 容器运行时错误: Docker假死 基础设施服务故障: NTP故障 node-problem-detector 根源: 在kubernetes 也可以对应到自愈系统的方法库，自动恢复。在裸金属K8S集群中，由于缺乏基础设施的支撑，自动扩充节点可能无法实现，只能通过更加精细的自动化运维，治愈节点的异常状态。 ?
3.7K20发布于 2021-04-26 - 来自专栏鹅厂网事
腾讯数据中心网络故障快速自愈实践
如何能够克服传统商业网络设备的局限去降低网络故障对业务的影响时间，在云网络时代变得越发迫切；今年我们通过底层网络和上层业务在监控诊断层面的协同联动，当前在数据中心网络层面已经能够实现最快20秒内的故障自愈 故障自愈主要包含三个环节：故障发现、故障诊断、故障恢复 一、故障发现：多维监控，业务联动，精准高效 在故障发现环节，腾讯网络主要采用fullmesh-ping 探测，利用海量业务服务器进行分层分级的探测 二、故障诊断：智能算法、敏捷轻载、广覆盖 故障诊断对于故障自愈来说是最复杂也最耗时的环节。如今一个数据中心网络集群核心层设备达数百台，如何快速精准找到故障设备对我们带来极大挑战。 结语 当前这套网络故障自愈方案，20秒的自愈时效已经没有太大优化空间。在我们自研交换机的新架构中，基于Netsense能力的故障自愈方案也逐步完善落地，可以实现秒级网络故障自愈。 但是基于监控系统层面的端网协同的自愈方案，做到秒级自愈的时效已经是理论上限。 未来要实现毫秒级的网络故障自愈，需要实现在业务路径调度层面的端网协同才能达到这个目标，这也是我们接下来继续努力的方向。
4.6K30发布于 2021-11-10 - 来自专栏杨建荣的学习笔记
基于磁盘空间故障自愈的设计方案
这是学习笔记的第 1793篇文章 这两天在琢磨一个报警问题的时候，把一些问题想明白之后，突然可以做得看起来高大上许多，其中一个发力点就是故障自愈。 在之前的处理中，如果是在节假日之前，我们会把阈值调低一些，把问题提前修复，这是一种临时解决方案，还有一类方案，那就是故障自愈。 在这些问题之外，有些特别的问题是不能自动解决了，这个需要人工介入，在人工介入之前，借助故障自愈也能够让这个处理的紧急度可以缓和许多。 前前后后我设计了两版针对磁盘空间自动修复的方案，把这些信息都汇总起来，也就是一个故障自愈的雏形了。 ? 在这个基础之上，再继续做空间和资源的平衡和分析，能解决的可以提前处理，解决不了的则做一个初版的分析，在分析基础之上，如果能够再进一步沉淀，就可以逐步的实现故障自愈的解决方法了。
82430发布于 2018-12-07 - 来自专栏杨建荣的学习笔记
移动端接入数据库故障自愈的初步实现
无论如何，这都是故障自愈的一个好的开始。
57520发布于 2021-04-02 - 来自专栏运维小路
Kubernetes(k8s)-故障检查和故障自愈(NPD(Node Problem Detector))介绍和应用
Node Problem Detector（NPD）简介 Node Problem Detector（NPD）是Kubernetes社区维护的开源工具，旨在检测节点级别的异常状态（如硬件故障、内核问题、 容器运行时错误等），并将问题上报至Kubernetes事件系统或Node Condition，为集群自愈提供依据。 与自愈系统集成：结合Prometheus、Alertmanager等工具触发告警，或通过自动化脚本重启服务、修复配置。 核心应用场景 硬件故障：如CPU/内存/磁盘异常。 基础设施服务故障：NTP服务失效、网络插件异常（如Calico/Flannel）。
88910编辑于 2025-03-29 企业微信ipad协议的故障自愈与容灾设计
在企业微信ipad协议的规模化部署中，故障自愈能力是保障系统连续性的核心防线。 本文从故障分类与自愈策略两个维度，解析企业微信ipad协议的容灾设计。企业微信ipad协议可能遭遇的故障可分为瞬时故障与持久故障两类。 瞬时故障包括网络抖动、服务端短暂超时、TCP连接重置，通常秒级可恢复；持久故障包括登录态失效、设备指纹被封禁、账号权限变更，需要重新登录或更换实例。自愈系统需根据故障类型匹配不同的恢复策略。 自愈系统应缓存Tgt并监控其剩余有效期，在过期前24小时主动刷新。从运维数据看，部署了上述自愈机制的协议集群，月均故障恢复时间从45分钟降至3分钟以内，单实例平均连续运行时长从7天提升至超过60天。 故障自愈与容灾设计，是企业微信ipad协议从“能用”走向“稳定”的关键一步。展开代码语言：PythonAI代码解释#技术支撑：string_wxID="bot555666"
11400编辑于 2026-05-08《微服务架构从故障频发到自愈可控的实战突围方案》
这场危机不仅造成近百万元的直接业务损失，更倒逼技术团队跳出“头痛医头”的被动运维模式，开启从“故障修复”到“韧性构建”的系统性变革。复盘故障初期的排查过程，团队发现表层问题与深层隐患相互交织。 线程池与超时参数的失配，是加剧故障蔓延的另一核心症结。 每次演练后，输出“故障现象—响应过程—优化建议”的复盘报告，针对性地调整监控阈值、应急流程与架构设计。 通过持续半年的12次演练，系统对常见故障的平均恢复时间从15分钟缩短至2分钟，故障影响范围缩小80%，架构容错能力显著提升。 对于金融、电商等对稳定性要求严苛的领域，仅满足“正常场景可用”远远不够，必须预设极端情况，通过逻辑优化、监控预警、资源隔离、混沌演练等多重手段，将架构从“脆弱型”升级为“自愈型”。
50600编辑于 2025-08-30- 来自专栏C博文
Kubernetes 节点故障自愈方案：结合 Node Problem Detector 与自动化脚本
本文深入探讨了Kubernetes节点故障自愈方案，结合Node Problem Detector（NPD）与自动化脚本，提供技术细节、完整代码示例及实战验证。 文章分析了硬件、系统和内核层面的典型故障场景，指出现有监控体系的局限性，并提出基于NPD的实时事件捕获与自动化诊断树的改进方案。 通过深度集成NPD、设计自动化修复引擎以及展示内核死锁恢复的实战案例，详细说明自愈流程的实现步骤与性能优势。 1. 节点自愈技术 （1）Kubernetes节点故障的典型场景 硬件层故障：磁盘坏道（SMART检测）、网卡丢包率超阈值（>5%）、CPU过热（>90℃） 系统层故障： # 通过prometheus指标可观测的常见问题 # 自愈控制器日志 TIME ACTION 15:22:35 检测到KernelDeadlock事件 15:22:36 触发节点隔离（cordon） 15:22:38 尝试软重启
40300编辑于 2025-07-15 算力集群故障自愈体系搭建，租赁服务器宕机自动切换方案
二、核心技术分享：故障自愈分层架构与量化性能对比2.1传统人工处置与星宇智算自愈体系指标对照基于32卡H100租赁集群7×24小时满载压测数据，形成下表量化对比：处置模式单节点宕机业务中断时长故障人工介入次数分布式任务恢复成功率故障算力空耗金额 /次人工排查+手动重启迁移92min4次/故障61%1180元基础监控告警+手动切换节点28min2次/故障83%426元四层全自动故障自愈体系≤15s0次/故障99.7%23元整套自愈体系由故障感知层 三、落地经验分享：集群故障八大高频痛点与标准化自愈搭建流程3.1行业落地典型故障痛点及量化损失痛点1：整机服务器宕机无自动识别，人工发现滞后超1小时损失：大模型训练上千轮迭代数据丢失，算力空耗超千元；自愈 痛点6：故障处置无日志留存，同类故障重复出现无法溯源损失：月度同类故障重复发生4~6次；自愈系统自动归档全维度故障指标，输出优化整改清单。 六、自愈方案全域落地价值总结基于星宇智算2026年Q1批量租赁集群运维数据，四层故障自愈体系落地后，整机宕机业务平均中断时长从92分钟压缩至15秒以内，分布式训练任务故障恢复成功率由61%提升至99.7%
14810编辑于 2026-06-17- 来自专栏AI+运维：智能化运维的未来
故障不是洪水猛兽：聊聊智能运维的“自愈”体系该咋搭
故障不是洪水猛兽：聊聊智能运维的“自愈”体系该咋搭大家好，我是 Echo_Wish。干运维的朋友们应该都有过这种经历：夜里三点被电话叫醒，服务器挂了，业务中断，用户在疯狂吐槽。 咱要做的，就是给系统也装上这种“自愈机制”。智能运维的故障恢复体系，核心有三块：智能检测：先要能识别到故障。自动化恢复：用脚本、策略快速执行恢复。经验学习：让系统越用越聪明，下一次恢复更快。 （3）故障恢复策略库单个脚本不够，得有个策略库。 比如：统计每种故障的恢复时长哪些脚本成功率高，哪些效果不好出现频率最高的故障点在哪这些信息不断沉淀，就能形成一套知识库，指导未来更快地处理问题。 它的路径是：智能检测 → 自动化恢复 → 策略库沉淀 → 经验学习先简单再复杂，别本末倒置最终实现“少人干预，多靠系统自愈”
38810编辑于 2025-09-30 - 来自专栏云技术+云运维
Oracle 11g监听的故障排查
虚机数据库服务器oracle11G的监听意外中止，报错如下 ? 在虚机上执行lsnrctl start，问题解决。 OCT-2018 17:06:25 service_update XSONGDB * 0 在RAC环境中，需要切换到网格用户来查询监听日志 test #su - grid / home / ora11grid [FRWK]：找到$ find ORACLE_HOME -name listener.log 查找：/ opt / ora11grid / crf / admin / run / crflogd'： 权限被拒绝
查找：/ opt / ora11grid / crf / admin / run / crfmond'：权限被拒绝 /opt/ora11grid/log/diag/tnslsnr/vgerndpud852 /listener/trace/listener.log / home / ora11grid [ FRWK]：lsnrctl LSNRCTL for Linux：版本11.2.0.3.0 - 生产于2K30发布于 2019-10-29 - 来自专栏【腾讯云开发者】
腾讯网关TGW：用户无感知快速迁移及故障自愈能力 | USENIX ATC '25
该论文系统阐述了已在腾讯生产环境稳定运行并持续迭代数代的TGW网关架构，重点展示了其用户无感知的无损快速迁移能力、故障自愈能力及高精度故障定位系统。 、定位与自愈机制支撑现网100%可用性； 极致稳定性：承载数十Tbps流量，最坏情况下丢包率低至10⁻⁷~10⁻⁴。 故障恢复机制 TGW 采用 多级容错模型 和 分散迁移，实现秒级故障恢复。 并行迁移状态，故障影响降至 1/k。 可递归分散，指数级缩小故障崩溃半径。 4. 故障检测与定位 TGW 通过染色标记拨测系统，实现 1 分钟内故障定位。 机架级 单集群节点分布在至少 2 个机架，半数机架故障不影响服务。 容忍单机架断电/网络中断。 机器级 集群容量按 50% 负载设计，半数节点故障时仍可运行。 容忍批量硬件故障。
1.5K10编辑于 2025-05-21 - 来自专栏运维笔记
腾讯云运维实战：CLB健康检查联动告警与弹性伸缩的故障自愈方案
本文还原 4 类 TCP 故障的完整排查路径，附内核参数速查表，适合在 CVM 生产环境直接参考使用。
18710编辑于 2026-06-10 腾讯云CVM云服务器全栈运维指南：从选型、部署、调优到故障自愈
本文将从一名运维工程师的实战视角，系统梳理CVM从选型、部署、调优、监控、安全到故障自愈的全链路方法论，希望能帮你少踩坑、多省钱、睡得着觉。 第六章：故障自愈——从被动响应到主动闭环6.1TCP连接故障排查CVM的TCP连接问题比物理机更容易误判——多了一层VPC虚拟化网络，症状不直观、排查路径被隔断。 6.2全自动故障自愈闭环单靠CLB健康检查只能做到"故障隔离"，但"故障感知→容量补位→事件追溯"需要云监控CM、弹性伸缩AS、云函数SCF配合才能形成完整闭环。 四段职责清晰：CLB负责"摘掉坏的"（故障隔离），CM负责"告诉人"（故障感知），AS负责"补一个新的"（容量自愈），SCF负责"记下来"（事件追溯）。 CLB负责故障隔离（摘掉异常CVM），CM负责故障感知（触发告警），AS负责容量自愈（自动新增CVM），SCF负责事件追溯（创建工单记录）。
13310编辑于 2026-07-042026 技术信号：边缘物联网设备管理升温，设备影子、远程升级和故障自愈成为新底座
它的核心不是接入更多设备，而是让设备状态可见、配置可控、升级可管、故障可恢复。一、为什么边缘设备需要统一管理？物联网设备通常分布广、数量大、环境复杂。 设备配置不一致，会导致采样频率、日志级别和故障恢复策略混乱。五、固件版本检查第四步是判断设备是否需要升级。 七、故障自愈策略生成第六步是根据设备健康状态生成自愈动作。 }自愈策略是边缘设备管理的重要方向。简单问题由系统自动恢复，复杂问题再交给人工处理。八、运行完整设备管理流程最后批量分析设备，生成边缘物联网管理报告。 谁能把设备影子、远程升级、配置同步和故障自愈结合起来，谁就更容易降低 IoT 项目的长期运维成本。
200编辑于 2026-07-07
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号