os-restart-diagnosis

name	os-restart-diagnosis
description	面向 Linux 操作系统异常重启故障的分阶段诊断技能。适用于外部供电中断、人为/计划重启、内核自保复位（OOM/Softlockup）、内核崩溃/Panic、硬件底层异常（MCE/ECC/PCIe）等场景；当用户提到机器突然重启、非预期 reboot、宕机后自动拉起、panic 重启、掉电重启、硬件告警导致重启时应触发。

OS Restart Diagnosis

目标

在最短路径内给出可复现、可验证的重启故障结论，并输出完整的故障时间链与根因链。

总流程（四阶段）

1. 第一阶段：全量信息收集与指纹归类
2. 第二阶段：按场景深度下钻
3. 第三阶段：反思与交叉验证
4. 第四阶段：输出根因分析结论

---

第一阶段：全量信息收集与指纹归类

执行脚本

bash ./scripts/core_diag_full.sh

第一阶段目标

• 一次性采集带外电源事件、重启历史、内核日志、崩溃转储与硬件异常信号
• 基于脚本关键输出生成重启故障指纹，并映射到单一主场景（V1/V2/V3/V4/V5）
• 产出“主场景 + 备选场景 + 下一步下钻脚本”

场景归类表（基于脚本输出字段）

核心判定特征（基于脚本输出字段）	场景名称	诊断结论与建议
Chassis_Power_Event 包含 Lost 或 Cycle；PSU_Status 显示 Failure	V1 外部供电/环境	供电故障倾向。优先核对机房 PDU、电源冗余与机柜掉电记录。
Reboot_History 包含 shutdown 或 runlevel 6；Last_Shutdown_User 非空	V2 人为/计划操作	人为重启倾向。核对审计日志 auditd 确认操作者与触发命令。
OOM_Events_Found > 0 或 Softlockup_Events > 0，且 Panic_Policies 开启	V3 内核自保重启	系统自保触发倾向。排查资源耗尽与调度死锁，评估容量与参数。
Kdump_Dir 状态为 EXISTS；Panic_Signature 包含 Oops/invalid opcode	V4 内核崩溃/Panic	内核或驱动崩溃倾向。需解析 vmcore 定位故障模块与调用链。
Fatal_HW_Events 包含 Critical 或 CATERR；Hardware_Err_Summary 含 Corrected/Uncorrected	V5 硬件底层异常	硬件失效倾向。排查 MCE/ECC/PCIe/SMART 并定位到部件或槽位。

第一阶段产出要求

• 主场景（V1/V2/V3/V4/V5）+ 备选场景（最多 2 个）
• 支撑该判断的关键证据（字段值、日志片段、时间点）
• 第二阶段下钻脚本与预期验证目标

---

第二阶段：按场景深度下钻

原则：先验证“假设是否成立”，再解释“为何成立”，最后给出“影响范围与修复优先级”。

场景 V1：外部供电与基础设施（Power）

• 脚本：bash ./scripts/diag_power.sh
• 分析方法论：侧重“链路稳定性”校验。
  • 对齐带外管理日志（IPMI/BMC）与系统日志断层时刻
  • 校验电源冗余状态、PSU 健康与机箱电源事件
  • 区分外部掉电、PDU 波动、单 PSU 故障与拔插行为
• 判定标准：
  • 断电事件与重启时间高度吻合，且 OS 无先行异常，可判 V1 成立

场景 V2：人为与计划内操作（Human）

• 脚本：bash ./scripts/diag_human.sh
• 分析方法论：侧重“行为轨迹”还原。
  • 关联 auditd、sudo、TTY/IP、登录会话与进程链
  • 排查自动化脚本、Crontab、运维平台任务触发
  • 对齐命令执行时间与关机/重启系统日志
• 判定标准：
  • 存在明确操作者、命令链和时间闭环，可判 V2 成立

场景 V3：内核自保与策略复位（Self-Guard）

• 脚本：bash ./scripts/diag_guard.sh
• 分析方法论：侧重“资源饱和度”与“策略触发”回溯。
  • 识别 OOM Killer、Softlockup、Watchdog 等前兆信号
  • 核验 sysctl 中 panic/reboot 相关策略
  • 结合历史性能数据（如 SAR）复原事故窗口负载
• 判定标准：
  • 资源异常与自保策略触发形成闭环，可判 V3 成立

场景 V4：内核崩溃与 Panic（Crash）

• 脚本：bash ./scripts/diag_crash.sh
• 分析方法论：侧重“代码级陷阱”定位。
  • 解析 vmcore/backtrace，定位触发函数与异常指令
  • 标识故障模块属于内核子系统还是第三方驱动
  • 对比已知问题与版本变更，判断兼容性风险
• 判定标准：
  • 存在稳定的 panic 签名与调用链证据，可判 V4 成立

场景 V5：硬件底层异常（Fault）

• 脚本：bash ./scripts/diag_fault.sh
• 分析方法论：侧重“物理部件映射”定位。
  • 解析 MCE/ECC 错误码与 CPU/内存错误寄存器信息
  • 关联磁盘 SMART 与 PCIe AER/总线异常
  • 将逻辑错误映射到具体硬件部件与槽位
• 判定标准：
  • 多源硬件错误在时间与部件上收敛一致，可判 V5 成立

第二阶段产出要求

• 每条假设状态：成立 / 不成立 / 待证实
• 每条假设至少提供 1 条支持证据和 1 条反证或排除证据
• 主场景置信度更新（高/中/低）与下一步验证建议

---

第三阶段：反思与交叉验证

目标：降低单路径误判风险，确保结论经得起反事实挑战。

3.1 反思方法论

• 严格区分“症状、触发机制、根因”三层，不将日志现象直接当根因
• 主动挑战当前主假设，优先寻找最强反证
• 对证据缺口显式标注“待补证据”，避免过度推断

3.2 交叉验证方法论

• 至少从三类独立证据源交叉验证：系统日志、带外管理日志、硬件/监控指标
• 对互斥场景执行最小代价复验（如短窗观测、单项配置回滚、替换电源路径）
• 若结论依赖单一证据，必须下调置信度并给出补充验证动作
• 关键时间点需跨来源对时（NTP 偏差、日志时区、BMC 与 OS 时钟）

第三阶段产出要求

• 被推翻的候选根因及其排除理由
• 保留候选根因的证据完备度评分（高/中/低）
• 最终主根因候选（可含并发次因）与剩余不确定项

---

第四阶段：输出根因分析结论

按以下模板输出最终结论，缺失项必须显式标注“待补证据”。

## 操作系统重启故障根因分析结论

### 1) 基本信息
- 故障时间：<YYYY-MM-DD HH:MM:SS 时区>
- 发现时间：<YYYY-MM-DD HH:MM:SS 时区>
- 影响对象：<主机/集群/业务>
- 影响表现：<异常重启/业务中断/性能抖动等>

### 2) 故障事件时间链（Time Chain，按故障演进）
- T0 <时间>：<先导事件，如变更发布、负载突增、机房供电波动>
- T1 <时间>：<首次异常信号，如 OOM、MCE、电源事件、panic 预警>
- T2 <时间>：<重启触发事件，如 watchdog 触发、panic、掉电>
- T3 <时间>：<重启后状态，如服务未自愈、再次重启、告警扩大>
- T4 <时间>：<处置动作与恢复信号>

### 3) 故障根因链（Causal Chain）
- 直接原因：<导致本次重启的直接触发点>
- 中间机制：<从异常到重启的系统机制链路>
- 深层原因：<流程缺陷/配置缺陷/容量缺陷/硬件老化等>
- 触发条件：<时间、负载、环境或变更条件>

### 4) 证据清单（支持 / 反证）
- 支持证据：
  - <日志/命令输出/监控指标 1>
  - <日志/命令输出/监控指标 2>
- 反证与排除：
  - <被排除候选根因 1 + 排除理由>
  - <被排除候选根因 2 + 排除理由>

### 5) 结论置信度
- 置信等级：<高/中/低>
- 置信依据：<跨证据源一致性说明>
- 剩余不确定性：<待补证据项>

### 6) 修复与预防
- 即时修复：<已执行动作>
- 长期治理：<基线、巡检、监控、变更门禁>
- 验证结果：<恢复指标与观察窗口>

---