openEuler 上的 AIOps：让机器先试着把问题修了，再叫人

作者：Echo_Wish

一、引子：运维不应该是被动救火，而是主动免疫

有一句话说得好：运维的艺术就是把“突发事件”变成“可预测的日常”。在 openEuler 这样的企业级系统里，单纯靠人工值守已经不现实：服务复杂、告警泛滥、根因诊断耗时，关键时候往往是“谁先动作，谁赢”。AIOps 的目的不是要替代运维，而是把重复、可模式化的故障处理自动化，让人去做更高价值的判断和优化。

本文带你从原理到实战，讲清楚如何在 openEuler 上用 AIOps 打造自动化故障恢复闭环：观测 → 检测 → 诊断 → 修复 → 验证 → 学习。

二、体系与设计理念（通俗版）

把 AIOps 看成六个环节：

1. 采集（Observability）：指标、日志、追踪，尽量结构化和统一采集（Prometheus + Fluent Bit/Fluentd + OpenTelemetry）。
2. 检测（Anomaly Detection）：基于规则（PromQL）+ 基于模型（统计/ML）混合检测。
3. 诊断（Root Cause Analysis）：基于因果图谱、拓扑依赖、日志相似性快速定位。
4. 修复（Remediation）：标准化 Playbook（可以是 systemd restart、清理磁盘、扩容 Pod、切换流量），并提供回滚。
5. 验证（Verification）：修复后自动验证关键指标恢复，若失败进入人工介入。
6. 学习（Feedback）：将本次故障流程、命中率、成功率、误判率做入库，训练下次模型与规则。

核心原则很简单：安全优先、优雅降级、可观测可回溯。任何自动修复必须有审计、幂等、最小权限与回退路径。

三、openEuler 上常见自动化修复场景举例

下面是几个常见场景，配合实现思路：

• 服务挂死/进程崩溃：检测到 process_up == 0 → 执行 systemctl restart → 验证 process_up == 1。
• 磁盘满：node_filesystem_avail_bytes 低于阈值 → 清理 /var/log/old、触发日志归档到对象存储 → 验证磁盘释放。
• 高 CPU 长时间持续：热点命中，自动采样火焰图 → 如果是单进程占用，隔离重启；如果是整体负载，触发横向扩缩容。
• 网络丢包/链路抖动：自动切换流量到备链路，通知网络工程师后再降级恢复。

四、实战代码（精简可跑的示例）

下面给出几个能够串起来的代码片段：一个简单的检测器（Prometheus 查询 + IsolationForest 异常判定），一个修复器（通过 SSH 执行 systemd 重启），以及简单的验证逻辑。注意真实生产要加鉴权、审计与限速。

1) 用 Prometheus 拉取指标并做异常检测（Python）

# prom_detect.py
import requests, time, json
from sklearn.ensemble import IsolationForest
import numpy as np

PROM_URL = "http://prometheus.example:9090/api/v1/query_range"
QUERY = 'node_cpu_seconds_total{mode="idle"}'
def fetch(metric, start, end, step="15s"):
    resp = requests.get(PROM_URL, params={"query": metric, "start": start, "end": end, "step": step})
    data = resp.json()
    values = []
    for v in data["data"]["result"][0]["values"]:
        values.append(float(v[1]))
    return np.array(values).reshape(-1,1)

# 获取最近 30 分钟数据
end = int(time.time())
start = end - 1800
arr = fetch(QUERY, start, end)
clf = IsolationForest(contamination=0.01).fit(arr)
pred = clf.predict(arr)  # -1 异常
if sum(pred==-1) > 3:
    print("异常检测触发")

2) 简单修复器：SSH 执行 systemctl restart（慎用）

# remediate.py
import paramiko, sys
host = "10.0.0.5"
user = "root"
svc = "myservice"
ssh = paramiko.SSHClient()
ssh.set_missing_host_key_policy(paramiko.AutoAddPolicy())
ssh.connect(host, username=user)
cmd = f"systemctl restart {svc} && systemctl is-active {svc}"
stdin, stdout, stderr = ssh.exec_command(cmd, timeout=30)
out = stdout.read().decode().strip()
print("服务状态:", out)
ssh.close()

3) 验证与回滚（伪代码）

# agent_controller.py (伪)
if detect_anomaly():
    record_event()
    backup_checkpoint()
    success = attempt_remediation()
    if not success:
        rollback_to_checkpoint()
        alert_oncall()
    else:
        verify_metric_recovery()
        if not recovered:
            rollback_to_checkpoint()
            alert_oncall()

这些片段只是示意；生产环境里你会把它们纳入到统一的 AIOps 平台（比如在 openEuler 上以 systemd unit 或 Kubernetes CronJob 运行），并加入权限控制、审计日志、限流与白名单。

五、集成建议（工具选型与落地）

• 观测层：Prometheus（指标）+ node_exporter + cAdvisor；Fluent Bit/Fluentd（日志）；OpenTelemetry（Tracing）。
• 检测层：PromQL 规则优先，结合 ML（IsolationForest、LOF、ARIMA）做二次确认，避免误报。
• 执行层：Ansible / SaltStack / 自研小型执行器，统一管理 Playbook；对于容器化服务，优先使用 k8s API 执行滚动重启或扩缩容。
• 中台：事件总线（Kafka / NATS），统一事件流、审计与回溯。
• 学习层：将每次事件的特征上报到时序 DB 与数据湖，用作模型训练与规则调整（MLOps/Feature Store）。

六、落地难点与风险控制（经验与观点）

1. 误杀风险：自动化修复要从低危动作开始（如重启单实例）→ 再到高危动作（扩缩容、切流）。每一步都要有幂等、回滚与 人工确认阈值。
2. 告警风暴：用“规则+模型”并行，模型检测要作为二次确认或用于降噪，避免模型单边触发大规模自动化。
3. 权限最小化：修复器应该运行在受控执行环境，使用临时凭证、签名请求来执行敏感动作。
4. 审计与合规：每次自动动作必须留痕（who/what/when/why），以便追责与回溯。
5. 持续改进：把失败样本与误判样本收集进训练集，不断提升识别与决策能力。

七、Echo_Wish 的一点话（温度 + 观点）

我常跟工程师说两句话：“让机器先试着把问题修了，但别把它当成替罪羊。” AIOps 最宝贵的不是减少人工，而是把人的时间从“救火”解放出来，去做系统设计、架构演进与用户体验。openEuler 作为面向企业的 Linux 平台，具备稳定、可定制和安全可控的特点，是做 AIOps 的理想落地平台。我们要把自动化做得像“会心的助理”——在你需要时帮你把常见问题处理掉，让你在关键时刻有余力做正确的决策。

八、结语：先小步快跑，再系统化推广

建议从一个最常见、最容易复现的场景入手（例如“服务进程重启”），把检测、修复、验证、审计做成闭环，跑稳定后再逐步拓展到磁盘、网络、流量切换等更复杂场景。长期看，AIOps 能把运维从“被动救火”变为“主动免疫”，这对任何追求高可靠的大型系统都至关重要。