从 SSH/SCP 到 AI 驱动的 OPS Agent：落地前的思考

关键词：AI Ops Agent、GitOps、OpenTelemetry、TimescaleDB、ArgoCD、SLO、MAPE‑K、向量检索、可观测性、合规模型

摘要

在很多中国企业客户里，运维现状仍停留在“SSH + SCP + 临时脚本”的阶段：没有稳定的 CI/CD，没有灰度与回滚策略，配置与知识分散在个人笔记和群聊中。一旦“AI Ops Agent”成为时代口号，仅靠采购商业支撑并不能直接跃迁。

本文给出一条从 0→1→N 的落地路线：用最小可行平台（MVP）建立数据可见、执行可控、策略可治理、安全可审计的“四性”基础，逐步实现“人机协作”的 MAPE‑K 闭环（Monitor–Analyze–Plan–Execute + Knowledge）。

1. 为何“买支持”≠“具备智能化运维能力”

· 能力不可外包：供应商可以提供工具与 SLA，但“指标体系、SLO 目标、发布策略、回滚判据、知识沉淀”是内生的组织能力。

· 数据不可替代：AI 需要高质量、结构化、可回溯的数据面（metrics/logs/traces/change graph/knowledge）。缺数据治理与标签规范，再强的模型也只能“瞎子摸象”。

· 执行必须可控：真正的 Agent 不是“远程执行脚本”，而是受控、可审计、可回滚的变更系统（GitOps/策略门/金丝雀/流量开关）。

结论：AI 之前，先把“工程地基”打牢；否则 AI 只是更快地产生不可控的操作。

2. 什么是“Agent‑Ready 运维”

定义：在不中断业务与合规可接受的前提下，让智能体能够理解现状 → 制定方案 → 触发受控变更 → 验证结果 → 写回知识。

五个就绪维度（5R）： 1) Reality（可观测现实）：统一 OTLP 入口、标签规范、数据留存与冷热分层；  2) Rules（可治理规则）：策略即代码（OPA/Conftest）、SLO 门槛、冻结窗口； 3) Runway（可控通路）：GitOps/CD/特性开关/流量管理，确保“可试、可退”；  4) Records（可审计记录）：变更、告警、审批、回滚全链路留痕；  5) Refine（知识精炼）：Runbook/Incident/PR Diff → 结构化 + 向量化，支持检索与复用。

3. 最小可行平台（MVP）参考架构

flowchart LR   subgraph InApp[应用与基础设施] A1[应用/服务]     A2[Node/Process Exporter]     A3[DeepFlow/eBPF 可选]   end   A1 -- OTLP(M/L/T) --> C[OpenTelemetry Collector]   A2 -- metrics --> C   A3 -- flows/traces --> C   C -- routes --> OO[(OpenObserve/Loki/Tempo/VM/CH)]   C -- selected metrics --> PG[(PostgreSQL + TimescaleDB)]   PG -- graph --> AGE[Apache AGE(Graph)]   KB[Runbook/Incident/Wiki/PR] --> ETL[[向量化 ETL]] --> PV[(pgvector)]   OO -- Alerts/Webhook --> AG[OPS Agent]   PG & PV & AGE --> AG   AG -- Plan/PR --> GIT[GitHub/GitLab]   GIT --> CD[ArgoCD/Flux]   CD --> K8s[(集群/Env)]   AG -- Verify via SLO --> OO & PG & PV   AG -- Writeback --> KB

MVP 仅需： - OpenTelemetry Collector + 一个开放后端（OpenObserve 全家桶或 Loki/Tempo/VM）； - PostgreSQL 14+ + TimescaleDB（连续聚合）+（可选）AGE 图扩展； - Alertmanager/OpenObserve Alerts → Agent Webhook； - GitOps（ArgoCD/Flux）作为唯一变更通路； - 最少一套 SLO/验证门（p95 延迟/错误率, 5–10 分钟窗口）。

4. 分阶段成熟度模型（从 SSH 到 Agent）

强烈建议S2→S3作为分水岭：没有“验证门”，Agent 将不可控。

5. Ready‑Checklist（可直接作为项目立项验收）

· 平台

☐ K8s/Docker 与 Ingress/证书 OK

☐ OpenTelemetry Collector 部署，应用/节点/进程可上报

☐ OpenObserve（或 Loki/Tempo/VM/CH）可写入、多租户与保留策略

☐ PostgreSQL 14+、TimescaleDB 安装，扩展权限就绪

☐ （可选）Apache AGE；pgvector 建表可用

· 账号/RBAC

☐ GitHub/GitLab Token（repo:contents, pull_request）

☐ ArgoCD/Flux Token（读/写分权），K8s SA（只读 + 受控直连）

☐ Vault/SOPS 管理密钥与轮转机制

· 数据/告警

☐ OTLP 路由与脱敏策略（PII 屏蔽） ☐ Alertmanager/OpenObserve Alerts → Agent Webhook

☐ Timescale 连续聚合 + TopK 视图就绪

· 仓库/策略

☐ GitOps 仓库 apps//charts|overlays 结构统一 ☐ CODEOWNERS、保护分支、合并规则

☐ OPA/Conftest 最少一条策略（副本/资源/镜像 tag）

· SLO/验证

☐ SLI 指标定义（可用性/延迟/错误率）

☐ 验证门：变更前后 5–10 分钟对比与阈值

☐ 回滚路径（rollout undo / revert PR / FF 关闭）

· 知识/沉淀

☐ Runbook/Incident/Wiki/PR 接入 ETL ☐ 文档切片+Embedding，向量检索可用

☐ 复盘自动写回知识库与标签

6. 反模式与护栏

反模式：SSH 直连、无审计；告警=重启/扩容；无 CODEOWNERS；“拍脑袋”上线；事故不复盘。 护栏：冻结窗口、变更节流、审批人兜底；金丝雀/影子流量；失败自动回滚；Kill‑Switch 一键熔断。

7. 组织与流程：从“人盯人”到“人机协作”

· RACI：业务 Owner 对 SLO 负责；平台团队对变更系统负责；安全对密钥与审计负责；Agent 团队对规则库与知识质量负责。

· 演练：每月金丝雀与回滚演练；每季度灾备切换演练；混沌注入与真实指标验证。

· 激励：以“失败可回滚时长、自动化建议采纳率、无人值守时长”作为 KPI，而非“发布次数”。

8. 预算与 ROI：三笔账

1) 事故账：MTTR × 事故频次 × 影响营收/成本；

2) 效率账：人均发布吞吐 × 质量门槛后上线率；

3) 复用账：知识复用率 × 训练/适配成本递减。

常见经验：仅引入 GitOps + 验证门，回滚时间从小时降到分钟；构建统一数据面后，定位时间可降一个数量级。

9. 90/180/365 天路线图

· 90 天（PoC → 可用）

o 搭建 OTel + OO/Loki/Tempo + PG/Timescale；引入 GitOps；完成 1–2 条关键链路的金丝雀与回滚；建立最小 SLO 与验证门；首个 Agent“提案→PR”。

· 180 天（试点 → 好用）

o 引入策略即代码；统一标签与资产；TopK 聚合服务化；复盘自动写回向量库；半自动审批在低风险窗口放开。

· 365 天（规模化 → 自治）

o 风险分级 + 自动变更；跨域指标与成本联动；组织层面将“知识‑变更‑验证”纳入目标管理。

10. 附录：可复用样例

10.1 readiness.yaml（项目就绪度样例）

platform:

kubernetes: true

ingress_tls: true

otel_collector: true

observability_backend: ["openobserve"]

postgres:

version: ">=14"

extensions: ["timescaledb", "pgvector"]

age: false

accounts:

git_token: true

argo_readonly: true

k8s_service_account_readonly: true

secrets_management: "sops"

telemetry:

pii_redaction: true

alert_webhook_to_agent: true

timescale_cagg_ready: true

repo_policy:

codeowners: true

protected_branches: ["main", "release/*"]

conftest_policies:

- name: resources-limits

status: enforced

slo:

latency_p95_ms: 300

error_rate_pct: 1

verification_window_min: 10

rollback:

methods: ["rollout-undo", "revert-pr", "feature-flag"]

knowledge:

etl_sources: ["runbook", "incident", "wiki", "pr"]

embedding_model: "bge-m3"

10.2 OPA/Conftest 策略（禁止 latest、强制资源上限）

package k8s.enforce

violation[msg] {

input.kind == "Deployment"

img := input.spec.template.spec.containers[_].image

endswith(img, ":latest")

msg := sprintf("image tag 'latest' forbidden: %s", [img])

}

violation[msg] {

c := input.spec.template.spec.containers[_]

not c.resources.limits.cpu

msg := sprintf("container %s must set cpu/memory limits", [c.name])

}

10.3 Timescale 连续聚合与验证门示例

-- 1) 每分钟聚合 p95 延迟

CREATE MATERIALIZED VIEW svc_latency_1m

WITH (timescaledb.continuous) AS

SELECT

time_bucket('1 minute', ts) AS tb,

service,

approx_percentile(0.95, latency_ms) AS p95

FROM http_latency

GROUP BY 1,2;

-- 2) 变更验证：最近 5 分钟 vs 前 5 分钟

WITH cur AS (

SELECT avg(p95) p FROM svc_latency_1m

WHERE service=$1 AND tb >= now() - interval '5 min'

), prev AS (

SELECT avg(p95) p FROM svc_latency_1m

WHERE service=$1 AND tb BETWEEN now() - interval '10 min' AND now() - interval '5 min'

)

SELECT (prev.p - cur.p) / NULLIF(prev.p,0) AS improvement

FROM cur, prev;

10.4 Agent Webhook 事件规范（最小）

{

"alert_id": "am-01F...",

"service": "checkout",

"severity": "high",

"labels": {"env":"prod","region":"ap-northeast-1"},

"observations": [

{"type":"metric","name":"latency_p95","value": 520},

{"type":"trace","id":"abcd-..."}

]

}

10.5 GitOps 仓库骨架 & CODEOWNERS

repo/

apps/

checkout/

charts/app/values.yaml

overlays/prod/kustomization.yaml

policies/

conftest/*.rego

environments/

prod/kustomization.yaml

.github/CODEOWNERS

# .github/CODEOWNERS

/apps/checkout/* @team-checkout

/policies/* @platform-sre

10.6 pgvector 知识库表结构（最小）

CREATE TABLE kb_docs (

id BIGSERIAL PRIMARY KEY,

service TEXT, env TEXT, owner TEXT,

ts TIMESTAMPTZ DEFAULT now(),

object_type TEXT, -- runbook/incident/pr/wiki

title TEXT,

url TEXT,

content TEXT,

embedding VECTOR(1024)

);

CREATE INDEX ON kb_docs USING ivfflat (embedding vector_l2_ops) WITH (lists=200);

结语

AI 不是银弹，体系才是。 当你把“可见、可控、可证、可追”的地基打好，AI Agent 自然从“概念”变成“生产力”。把本文的 Ready‑Checklist 与样例落进仓库，从一个最小服务试点开始——先让一次回滚更快、更可证，再谈自治。