本方案提出一套 最小可行、可扩展、可审计 的 AI 驱动 OPS Agent 架构,通过 LLM、规则引擎、工具调用三者协同,驱动 MAPE-K 闭环:
Perceive(检查) → Analyze(诊断) → Plan(生成计划) → Gate(策略) → Execute(动作) → Verify(验证) → Learn(沉淀)
目标是将典型运维场景抽象为 可调用的技能包:
典型运维活动中,问题从“信号”到“决策”再到“变更”需要跨越多个步骤:
在这些场景中,我们需要 五类能力:
于是,我们抽象出 Sensor / Analyst / Planner / Gatekeeper / Executor / Librarian / Orchestrator 七类角色,让系统具备“看→想→做→学”的闭环能力。
我们将可观测性数据归约为五大核心维度:
这就是 “五维一图”:
关键路径:Sensor → Analyst → Planner → Gatekeeper → Executor → Librarian → Orchestrator
模块化设计,插件化适配器,统一 CloudEvents 协议。
模块 | 职责 | 输入 | 输出 | 存储 | 接口 | SLO |
---|---|---|---|---|---|---|
Sensor | 接入信号 | OTLP、Prom、logs | OO 明细 | OO、PG | /ingest/* | 写入 p99<2s |
Analyst | 异常检测 | OO 明细、PG | 聚合、analysis.findings | PG | /analyze/run | 10min 完成聚合 |
Planner | 生成计划 | kb_chunk、证据 | plan.proposed | PG | /plan/generate | <30s 首版计划 |
Gatekeeper | 策略评估 | plan.proposed | plan.approved | PG | /gate/eval | 自动评估<1s |
Executor | 执行动作 | plan.approved | exec.step.result | OO、PG | /adapter/exec | 单步 15m 超时 |
Librarian | 知识沉淀 | 日志、diff | kb_doc、kb_chunk | PG | /kb/ingest | 5min 内可检索 |
Orchestrator | 状态机调度 | 各类事件 | case.updates | PG | /case/* | 状态原子迁移 |
NEW → OBSERVE → DIAGNOSE → PLAN → GATE → EXECUTE → VERIFY → CLOSED
↘ ROLLBACK / MITIGATE / PARKED
结构化模板:触发规则 → 证据链(五维一图) → Plan DSL 片段 → 门控策略 → 验证查询 → 审计/KPI → 失败分支
p95>基线×1.2
或 err_rate>1%
。metric_1m(p95, err)
;链路:service_call_5m
;日志:log_pattern_5m
;拓扑:topo_edge_time
;知识:kb_chunk(上线复盘)
apiVersion: aops/v1
kind: Plan
spec:
steps:
- id: canary10
action: k8s.rollout
params: {deployment: checkout, strategy: canary, weight_pct: 10}
verify:
checks:
- type: metrics
query: ref:queries.q_slo
pass_if: p95_ms < 800 and err_rate_pct < 1
rollback:
action: k8s.rollout
params: {deployment: checkout, strategy: rollback, to_revision: prev_stable}
risk<=low
;变更冻结日禁止。p95<800 & err<1%
;关键依赖 Span 超时率 < 2%。steps:
- id: toggle-ff
action: http.call
params: {method: POST, url: https://flag/api/toggle, body: {flag: newAlgo, percent: 25}}
verify:
checks:
- type: metrics
query: ref:queries.q_exp
pass_if: conv_rate_delta >= 0 and err_rate_pct < 1
percent: 0
。k8s.secret
更新 → gateway reload
→ 逐层拨权。rows_examined/rows_sent
比例异常。steps:
- id: idx-create
action: sql.exec
params: {dsn: pg://prod, sql: "CREATE INDEX CONCURRENTLY IF NOT EXISTS ix_o_uid ON orders(user_id);"}
guard:
preconditions:
- type: window
expr: now in [01:00-04:00 JST]
verify:
checks:
- type: metrics
query: ref:queries.q_sql_p95
pass_if: p95_ms < baseline*0.8
rollback:
action: sql.exec
params: {dsn: pg://prod, sql: "DROP INDEX IF EXISTS ix_o_uid;"}
cpu_pct>75%
且 queue_len>阈值
持续 10 分钟。p95 恢复 < 800ms
;扩容成本 < 预算上限。callee=payments
Span 超时率 > 5%。log ingest rps
激增且与错误率弱相关。原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。