- 综合排序
- 最热优先
- 最新优先
- 来自专栏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篇文章 这两天在琢磨一个报警问题的时候，把一些问题想明白之后，突然可以做得看起来高大上许多，其中一个发力点就是故障自愈。 在之前的处理中，如果是在节假日之前，我们会把阈值调低一些，把问题提前修复，这是一种临时解决方案，还有一类方案，那就是故障自愈。 在这些问题之外，有些特别的问题是不能自动解决了，这个需要人工介入，在人工介入之前，借助故障自愈也能够让这个处理的紧急度可以缓和许多。 前前后后我设计了两版针对磁盘空间自动修复的方案，把这些信息都汇总起来，也就是一个故障自愈的雏形了。 ? 在这个基础之上，再继续做空间和资源的平衡和分析，能解决的可以提前处理，解决不了的则做一个初版的分析，在分析基础之上，如果能够再进一步沉淀，就可以逐步的实现故障自愈的解决方法了。
81630发布于 2018-12-07 - 来自专栏杨建荣的学习笔记
移动端接入数据库故障自愈的初步实现
无论如何，这都是故障自愈的一个好的开始。
56420发布于 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）。
86310编辑于 2025-03-29 企业微信ipad协议的故障自愈与容灾设计
在企业微信ipad协议的规模化部署中，故障自愈能力是保障系统连续性的核心防线。 本文从故障分类与自愈策略两个维度，解析企业微信ipad协议的容灾设计。企业微信ipad协议可能遭遇的故障可分为瞬时故障与持久故障两类。 瞬时故障包括网络抖动、服务端短暂超时、TCP连接重置，通常秒级可恢复；持久故障包括登录态失效、设备指纹被封禁、账号权限变更，需要重新登录或更换实例。自愈系统需根据故障类型匹配不同的恢复策略。 自愈系统应缓存Tgt并监控其剩余有效期，在过期前24小时主动刷新。从运维数据看，部署了上述自愈机制的协议集群，月均故障恢复时间从45分钟降至3分钟以内，单实例平均连续运行时长从7天提升至超过60天。 故障自愈与容灾设计，是企业微信ipad协议从“能用”走向“稳定”的关键一步。展开代码语言：PythonAI代码解释#技术支撑：string_wxID="bot555666"
9900编辑于 2026-05-08《微服务架构从故障频发到自愈可控的实战突围方案》
这场危机不仅造成近百万元的直接业务损失，更倒逼技术团队跳出“头痛医头”的被动运维模式，开启从“故障修复”到“韧性构建”的系统性变革。复盘故障初期的排查过程，团队发现表层问题与深层隐患相互交织。 线程池与超时参数的失配，是加剧故障蔓延的另一核心症结。 每次演练后，输出“故障现象—响应过程—优化建议”的复盘报告，针对性地调整监控阈值、应急流程与架构设计。 通过持续半年的12次演练，系统对常见故障的平均恢复时间从15分钟缩短至2分钟，故障影响范围缩小80%，架构容错能力显著提升。 对于金融、电商等对稳定性要求严苛的领域，仅满足“正常场景可用”远远不够，必须预设极端情况，通过逻辑优化、监控预警、资源隔离、混沌演练等多重手段，将架构从“脆弱型”升级为“自愈型”。
48700编辑于 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 尝试软重启
39600编辑于 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%
11510编辑于 2026-06-17- 来自专栏AI+运维：智能化运维的未来
故障不是洪水猛兽：聊聊智能运维的“自愈”体系该咋搭
故障不是洪水猛兽：聊聊智能运维的“自愈”体系该咋搭大家好，我是 Echo_Wish。干运维的朋友们应该都有过这种经历：夜里三点被电话叫醒，服务器挂了，业务中断，用户在疯狂吐槽。 咱要做的，就是给系统也装上这种“自愈机制”。智能运维的故障恢复体系，核心有三块：智能检测：先要能识别到故障。自动化恢复：用脚本、策略快速执行恢复。经验学习：让系统越用越聪明，下一次恢复更快。 （3）故障恢复策略库单个脚本不够，得有个策略库。 比如：统计每种故障的恢复时长哪些脚本成功率高，哪些效果不好出现频率最高的故障点在哪这些信息不断沉淀，就能形成一套知识库，指导未来更快地处理问题。 它的路径是：智能检测 → 自动化恢复 → 策略库沉淀 → 经验学习先简单再复杂，别本末倒置最终实现“少人干预，多靠系统自愈”
37410编辑于 2025-09-30 - 来自专栏【腾讯云开发者】
腾讯网关TGW：用户无感知快速迁移及故障自愈能力 | USENIX ATC '25
该论文系统阐述了已在腾讯生产环境稳定运行并持续迭代数代的TGW网关架构，重点展示了其用户无感知的无损快速迁移能力、故障自愈能力及高精度故障定位系统。 、定位与自愈机制支撑现网100%可用性； 极致稳定性：承载数十Tbps流量，最坏情况下丢包率低至10⁻⁷~10⁻⁴。 故障恢复机制 TGW 采用 多级容错模型 和 分散迁移，实现秒级故障恢复。 并行迁移状态，故障影响降至 1/k。 可递归分散，指数级缩小故障崩溃半径。 4. 故障检测与定位 TGW 通过染色标记拨测系统，实现 1 分钟内故障定位。 机架级 单集群节点分布在至少 2 个机架，半数机架故障不影响服务。 容忍单机架断电/网络中断。 机器级 集群容量按 50% 负载设计，半数节点故障时仍可运行。 容忍批量硬件故障。
1.4K10编辑于 2025-05-21 - 来自专栏运维笔记
腾讯云运维实战：CLB健康检查联动告警与弹性伸缩的故障自愈方案
本文还原 4 类 TCP 故障的完整排查路径，附内核参数速查表，适合在 CVM 生产环境直接参考使用。
16010编辑于 2026-06-10 - 来自专栏啄木鸟软件测试
性能优化：自愈测试脚本实战
如何让测试脚本具备基础‘自愈能力’，在异常发生时主动适配而非直接崩溃？本文结合啄木鸟软件测试团队在某银行核心交易系统性能回归项目中的真实实践，详解自愈测试脚本的设计逻辑、关键技术与落地效果。 二、自愈不是AI，而是可验证的工程化策略需明确：自愈测试 ≠ 大模型生成脚本，而是基于确定性规则的容错增强。我们定义‘三级自愈能力’： - L1 定位器弹性：不依赖单一属性，采用多维度权重匹配。 四、警惕自愈陷阱：可控性比‘聪明’更重要 自愈能力必须满足三个硬约束：可审计、可关闭、可回滚。 我们强制要求： - 所有自愈行为必须记录原始异常堆栈+决策依据+执行结果，供质量门禁扫描； - 支持按测试套件/用例/环境粒度开关自愈开关（如prod环境默认关闭，仅允许L1级定位器弹性）； - 每次自愈触发后 当测试脚本能像运维系统一样具备故障自检、策略切换、日志溯源能力，我们才真正把‘质量左移’从口号变为可度量的生产力。
20810编辑于 2026-03-31 - 来自专栏WeOps
嘉为蓝鲸 × 中大k8s智能体凭对话触发实现集群故障高效自愈
官网原文（免费申请演示）：【嘉为蓝鲸×中大】首篇实战：对话触发k8s智能体，高效自愈集群故障随着云原生技术的普及，Kubernetes（k8s）已成为企业容器编排的核心引擎。 与嘉为蓝鲸OpsPilot智能运维平台强强联合，基于中大在分布式系统、智能运维等领域的学术积累，深度集成大模型和K8s工具链，以联合研发的对话式智能体重构集群管理流程 ，推动运维模式从“人工救火”迈向“AI自愈 他立刻打开电脑，却陷入一连串麻烦：传统k8s运维的核心痛点清晰可见：操作步骤繁琐——平均每次故障需执行10+命令多工具切换耗时——需在kubectl、监控平台、日志系统间反复跳转故障定位滞后——依赖人工经验排查资源调度被动 2）三种使用形态，让k8s故障自愈发挥最大价值k8s智能体主要有三种使用形态：对话式触发，定时触发，API触发。所有形态均收敛至K8s Virtual SRE，由它协调工具执行和决策。 陈鹏飞 | 中山大学计算机学院中山大学的云原生故障诊断算法 、零侵入追踪专利与智能调度模型注入OpsPilot，k8s运维正式迈入“技术自治”时代——学术精研与工程实践的共振，正让“AI自愈运维”从实验室走向产业核心场景
53900编辑于 2025-08-12 自愈测试来了：Bug还能藏多久？
：如何在两种路径之间做出清醒的选择 一、自愈的本质：它在修复什么，又在掩盖什么 自愈测试的技术实现并不神秘。 依赖自愈测试的团队，工程师的注意力会逐渐集中在：如何配置自愈平台、如何处理自愈率不足的例外、如何解读自愈日志。这些都是有价值的技能，但它们是工具运维技能，而非测试工程的核心素养。 但它也可能孕育出一种微妙的认知偏差——“测试通过”与“质量可靠”之间的等号，在自愈机制介入后，其可信度是动态变化的。 自愈率是一个经常被展示却很少被追问的指标。“上周自愈率92%”听起来是好消息。 核心差异：把自愈测试当银弹的管理者在转移风险，把它当工具的管理者在精准释放效率。 结尾：自愈不是终点，清醒才是 读到这里，你可能会问：所以自愈测试到底值不值得引入？ 建立自愈质量的评估机制：不要只看自愈率，要定期抽样审查被自愈掉的案例——它们究竟是噪声，是合理的产品变更，还是被静默掉的潜在风险信号。
18510编辑于 2026-04-14
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号