告警停在 91.90%：16 个故障对照巡检 Skill

告警停在 91.90%：16 个故障对照巡检 Skill

阿里云操作系统控制台在 2026-08-04 开源了 SysOM Inspection Skill。SysOM 是这套控制台里的运维组件。它将和已经放出的 SysOM Diagnostic Skill 一起收进 SysOM Skill Bundle。闭环写成三步：巡检发现异常，诊断定位根因，再给出处置建议。文章认为，诊断只解决故障已经发生之后怎么找原因；更好的做法是在演变成停机之前把隐患找出来。

值班工程师凌晨被叫醒时，最难的往往不是系统坏了，而是对着一堆数据不知道下一步看什么。操作系统控制台此前已经把告警之后登录主机、手工追根因的工作交给智能体。巡检 Skill 补的是前半段。

一次凌晨内存告警

文章用一个周四凌晨的故事说明只看告警会停在哪。值班群里的通知是：生产环境某实例内存使用率在 91.90% 停留了 30 分钟。接下来是熟悉的手工路径：登录跳板机，top 刷过一屏进程，看不出是谁；free -h 只剩一百多 MB 可用内存；/proc/meminfo 里 Anonymous page 异常高。群里有人猜缓存没释放，有人猜应用泄漏，有人建议直接重启。从告警到认定一个 python 进程吃掉 12.95 GB，团队用了将近四十分钟。服务在下一波流量前稳住了，但文章把这次成功写成运气。

同一台机器，换一条路径

同一台机器、同一次内存尖峰，如果巡检 Skill 已经在跑例行检查，37.4 秒后会给出报告。19 个检查项里 18 个正常，1 个报错：内存使用率 91.90%，剩余可用内存 161 MB，再来一波流量就可能 OOM。

报告没有停在「内存高」。报错触发后自动做 memgraph 诊断：某个用户的 python 进程独占 12.95 GB 匿名内存，大约是整机内存的 83%，这就是尖峰的直接原因。其余前 10 个进程合计不到 600 MB，可以排除零散占用叠出来的假象。人要做的只剩确认这个 python 进程是不是预期行为。不是的话，杀掉就能收回大约 12 GB。文章把这一次从被叫醒到处置完成，写成从约四十分钟压到五分钟以内。

四十分钟本身还不是全部成本。文章列了第二天下午的疲劳、被拉进应急群的其他人、业务侧对稳定性的信任，以及高峰期每一秒的焦虑。这些没有量化。它把 Skill 的作用写成：把依赖个人经验和谁还醒着的被动排障，换成可重复执行的组织能力。

巡检要先回答三件事

很多团队已经能回答「有没有异常」。告警真正打过来时，一线还要三件事：严重到什么程度，最可能的根因是什么，下一步具体做什么。

巡检 Skill 把这三件事前移到检查过程里。文章写目前有 40 多项检查，覆盖系统负载、内存、磁盘读写延迟、调度延迟、文件句柄、线程、根分区和 inode、socket 泄漏、TCP/UDP 内存，以及多种内存泄漏风险。高风险场景不停留在告警，会自动接上 SysOM Diagnostic Skill，沿负载、内存、网络、磁盘和调度追到根因。

内部评估写的是：异常检测总体准确率超过 80%，高风险项误报率是 0%。也就是高风险警告不应是空报。文章没有给出这组评估的样本量和判分规则。

16 个真实故障上的对照

巡检路径来自 Linux 内核专家的排障经验。智能体不再靠模型临场猜命令，而是走已经核对过的路径。为证明这一点，文章做了对照：16 个真实操作系统故障。一组智能体带上 SysOM Inspection Skill，对照一组只用通用能力硬查。

效率上，面对同一问题，带 Skill 的一组对话轮次、工具调用和总耗时都明显下降。文章没有写出下降后的具体轮次、调用次数或秒数。它的解释是：故障现场通常要把多名工程师拉进群、在多个工具之间对数据；自动走专家路径省下的不只是推理时间。

准确率上，带 Skill 的一组在内核问题上明显高于基线。差距最大的是需要专家判断的场景：socket buffer 泄漏、vmalloc 内存异常、memcg 配置错误。文章同样没有给出每一类的前后分数，只说问题越依赖专门经验，Skill 的差距越大。

同一套能力写成两种用法：给人是开箱即用的巡检产品，给智能体是可调用的 Skill。无论自建运维智能体，还是接入现成巡检，都不必重新攒一套验证过的 Linux 排障经验。

接到智能体上

Skill 放在阿里云 Agent Skills 平台，带排障路径、诊断提示和执行脚本，可装进 Qoder、Claude Code 这类环境。和已开源的诊断 Skill 合在一起，就是「巡检发现、诊断定位、给出处置」。文章给出的安装示例是一条命令：

npx skills add aliyun/alibabacloud-aiops-skills --skill alibabacloud-alinux-sysom-inspection --agent qoder -y --full-depth

装完后直接说要检查哪台实例、哪个地域。高风险项会自动进入深度诊断，报告里包含异常、关键发现和根因。不同宿主的装法以 Skills 页面为准。页面地址是 https://skills.aliyun.com/skills/alibabacloud-alinux-sysom-inspection 。

限制

16 个故障是对照的全部样本量，文中没有两组的准确率、轮次、工具次数和耗时。超过 80% 写的是异常检测准确率，不是这 16 题的诊断准确率；0% 误报只限于高风险项，没有写低风险项。91.90%、12.95 GB、37.4 秒、19 项检查和「四十分钟到五分钟内」来自同一个叙事案例，不是 16 题的平均。第二天下午的疲劳和信任损失没有数字。页面没有禁止复制的声明。

阿里云，OpenAnolis，No More Panic Over 3 AM Alerts! Pinpoint the Root Cause in One Click with SysOM Inspection Skill，2026-08-04，https://www.alibabacloud.com/blog/no-more-panic-over-3-am-alerts-pinpoint-the-root-cause-in-one-click-with-sysom-inspection-skill_603424