📚 课程目录第1章后台任务终止的常见现象与初步判断

1. 后台任务终止的常见现象与初步判断

后台任务被系统终止后，最直接的表现是任务“消失”或进入非预期状态。运维人员需要在监控告警、日志核查、用户反馈三个维度判断是真终止还是假死。下表列出了四种典型终止现象及其初步判断依据：

现象名	典型表现	初步判断方向
Crash（进程崩溃）	进程状态从 RUN 变为消失，`ps` 或 `systemctl status` 显示 exited/crashed	代码异常、信号（SIGSEGV/SIGABRT）、配置错误
OOM Kill（内存超限）	进程突然消失，`dmesg` 或系统日志出现 `Out of memory: Kill process` 行	内存使用超限、cgroup 限制、系统可用内存不足
Timeout（超时终止）	任务日志停留在最后一条记录，未见正常退出信息，调度系统显示超时	任务处理时间 > 超时阈值，或依赖的外部服务无响应
Dependency Fail（依赖丢失）	任务启动后迅速退出，日志提示连接失败或文件未找到	数据库/缓存断开、配置挂载点失效、共享库缺失

区分“任务消失”与“任务报错退出”： 任务消失通常只留下系统日志（如 oom-killer 或 exit code 137），应用程序自身日志可能被截断；任务报错退出则会在应用日志或 stderr 中包含明确的错误堆栈。两种场景的恢复步骤差异很大，第一步判断错误。

收到告警后，不要立即登录重启。先做范围判断：

单机单任务： 可能是进程自身问题或节点资源抖动，紧急程度低，记录现场后再恢复。
单机多任务批量终止： 大概率是节点级别的资源（内存/磁盘/ulimit）或系统策略（systemd KillMode、cgroup oom）触发，紧急程度中。
集群/多机同任务终止： 可能是上游依赖（数据库、配置中心）整体故障，或者新发布的配置模板导致所有任务异常。紧急程度高，需要优先止血。
周期性/批处理任务全部异常： 检查调度器（Cron、Airflow、K8s CronJob）本身是否异常或权限变动。

以下故障树展示了从“任务终止”现象到四种主要直接原因的推理路径。该图用于指导现场工程师按分支收集数据，避免在错误分支上浪费诊断时间。

在定位之前，必须一次性采集以下七类数据，避免因后续操作（如重启、重启覆盖日志）丢失现场信息：

系统日志（journalctl / dmesg）： 定位 OOM Kill、信号终止、硬件告警。
任务日志（stdout/stderr）： 捕获进程退出前的最后输出。
进程快照（/proc/{pid}/status, smaps）： 记录任务退出前的内存、文件描述符、线程数。
资源使用历史（监控系统/ Sar 数据）： CPU、内存、磁盘 I/O、网络流量在终止前后 2 小时的曲线。
cgroup 状态（/sys/fs/cgroup/{memory,pids}/…）： 如果任务运行在容器或 systemd scope 下，采集 cgroup 限额和当前用量。
系统参数（ulimit -a, sysctl vm.overcommit_ratio）： 确认用户级别和系统级别的资源限制是否有硬上限。
依赖服务健康检查： 数据库池、消息队列、共享存储的存活状态。

⚠ 关键动作：不要不采集“进程快照”就重启
重启会清空 /proc/{pid}/ 下的内存映射和文件描述符信息，使得后续无法判断是否因句柄泄漏或内存碎片崩溃。在重启之前至少执行一次：

cat /proc/{pid}/status
ls -l /proc/{pid}/fd | wc -l

建议将输出复制到持久日志文件中。

根据 1.2 节的影响范围判断，设定以下实操规则：

紧急程度	影响说明	建议动作	上报对象
P0	核心业务后台批量终止 > 30% 节点	立即拉起备集群/切换流量；保留现场后重启；上报部门负责人	技术总监 + 值班经理
P1	单机全任务终止，或关键依赖故障	隔离节点；采集数据后重启；通知周边服务	团队技术主管
P2	单任务偶发终止，业务影响小	采集日志；排入排查队列，24h 内分析	值班工程师

到此，第 1 章完成了从现象识别、影响评估到初始数据采集的全流程。下一环节（第 2 章）将基于采集到的系统日志和进程快照，深入分析 OOM 和信号终止的具体根因。