阿里云操作系统控制台将 SysOM 巡检 Skill 开源，释放出的信号很明确：系统运维 Agent 不应只在故障发生后分析日志、定位根因，还应该定期检查风险，在资源耗尽、配置漂移或内核异常真正影响业务前发出预警。
按照公布的方向，巡检 Skill 后续将与 SysOM 诊断 Skill 一同进入 SysOM 技能包，串联出“巡检发现问题 → 诊断定位根因 → 给出处置建议”的完整流程。这里的重点不只是增加一个工具，而是让 Agent 拥有从观察、判断到行动建议的连续上下文。
巡检 Skill 补上了哪一环
传统监控擅长回答“某个指标是否超过阈值”，但系统巡检面对的问题往往更复杂。例如，磁盘空间暂时充足，却可能因为 inode 快速消耗而即将无法创建文件；系统负载不高，却可能已经积累大量不可中断睡眠进程；内存还有余量，但持续增长的 slab 或异常换页可能预示风险。
巡检 Skill 可以把这些检查组织为 Agent 可调用、可解释的能力：
- 收集主机负载、内存、磁盘、inode、进程和内核状态。
- 根据规则识别异常项，并保留触发判断所需的证据。
- 将异常交给诊断 Skill，进一步缩小根因范围。
- 输出带风险等级、证据和处置方向的建议，而不只是一个告警标题。
这使运维流程从孤立脚本转向有上下文的技能协作。巡检结果不再是终点，而是诊断阶段的结构化输入。
闭环的关键是结构化交接
“巡检、诊断、建议”要真正形成闭环，各个 Skill 之间需要稳定的数据契约。巡检阶段至少应输出检查项、状态、观测值、阈值、证据和目标主机；诊断阶段则应补充可能根因、置信度和验证步骤。
下面是一个可以改造的示例契约。它不是官方 SysOM 配置格式，而是用于说明如何组织巡检 Skill 的输入与输出：
apiVersion: ops.example.io/v1alpha1
kind: InspectionTask
metadata:
name: linux-daily-inspection
spec:
targets:
- host: 192.0.2.10
checks:
- id: root-filesystem-usage
metric: filesystem.used_percent
mountpoint: /
warning: 80
critical: 90
- id: inode-usage
metric: filesystem.inode_used_percent
mountpoint: /
warning: 80
critical: 90
- id: uninterruptible-processes
metric: process.state_d_count
warning: 3
critical: 10
onFinding:
invokeSkill: sysom-diagnosis
includeEvidence: true
在实际接入时，需要把 apiVersion、字段名称和 Skill 标识替换为目标技能包公开的真实接口。无论采用哪种格式，都应避免只传递一句自然语言描述，否则诊断 Skill 很难稳定复现巡检判断。
可以这样实践：制作一个最小 Linux 巡检器
在正式接入 SysOM 技能包之前，可以先用一个小脚本验证巡检数据契约。下面的脚本只依赖 Linux 常见命令和 Python 3，会检查根分区容量、inode 使用率、内存可用比例以及不可中断睡眠进程数，并输出适合后续 Agent 消费的 JSON。
将脚本保存为 inspect_host.py，直接运行 python3 inspect_host.py：
#!/usr/bin/env python3
import json
import os
import subprocess
def run(*args):
return subprocess.check_output(args, text=True).strip()
def percent(value):
return float(value.rstrip("%"))
def finding(check_id, value, warning, critical, unit):
if value >= critical:
status = "critical"
elif value >= warning:
status = "warning"
else:
status = "ok"
return {
"check_id": check_id,
"status": status,
"observed": value,
"unit": unit,
"thresholds": {
"warning": warning,
"critical": critical
}
}
disk_columns = run("df", "-P", "/").splitlines()[-1].split()
inode_columns = run("df", "-Pi", "/").splitlines()[-1].split()
meminfo = {}
with open("/proc/meminfo", encoding="utf-8") as stream:
for line in stream:
key, value = line.split(":", 1)
meminfo[key] = int(value.strip().split()[0])
memory_unavailable = 100 * (
1 - meminfo["MemAvailable"] / meminfo["MemTotal"]
)
process_states = run("ps", "-eo", "stat=").splitlines()
d_state_count = sum(1 for state in process_states if state.startswith("D"))
checks = [
finding("root-filesystem-usage", percent(disk_columns[4]), 80, 90, "percent"),
finding("root-inode-usage", percent(inode_columns[4]), 80, 90, "percent"),
finding("memory-unavailable", round(memory_unavailable, 2), 85, 95, "percent"),
finding("uninterruptible-processes", d_state_count, 3, 10, "count")
]
result = {
"schema_version": "1.0",
"host": os.uname().nodename,
"overall_status": (
"critical" if any(c["status"] == "critical" for c in checks)
else "warning" if any(c["status"] == "warning" for c in checks)
else "ok"
),
"checks": checks,
"diagnosis_requested": any(c["status"] != "ok" for c in checks)
}
print(json.dumps(result, ensure_ascii=False, indent=2))
这个示例刻意把“采集”和“判断”放在一起，以便快速运行。生产环境中更适合把两者拆开：采集层负责提供可信数据，规则层负责阈值和组合条件，Agent 再基于异常证据调用诊断 Skill。这样可以分别测试每一层，也能避免模型自行猜测系统指标。
从试点到生产需要守住的边界
Agent 给出处置建议，不等于它应该默认执行所有修复操作。涉及重启服务、终止进程、修改内核参数或清理文件的动作，应设置审批、权限和回滚机制。巡检命令本身也要有超时和资源限制，避免一次深度扫描反过来影响业务主机。
落地时可以按以下清单推进：
- 先选取磁盘、内存、进程状态等低风险、高频检查项建立试点。
- 为巡检与诊断定义版本化的结构化数据契约。
- 在结果中保留原始证据、执行时间、目标主机和规则版本。
- 将只读巡检权限与修复权限分离，危险操作必须经过审批。
- 使用已知故障样本评估误报率、漏报率和根因定位准确度。
- 为 Skill 设置超时、并发上限、审计日志和失败降级策略。
SysOM 巡检 Skill 的开源价值，最终取决于它能否被纳入现有告警、工单、变更和审计体系。先把巡检结果做成可靠、可追溯的结构化输入，再逐步扩大 Agent 的诊断与处置权限，通常比一开始追求全自动修复更稳妥。