企业内网运维场景:用 n8n 落地端到端 AI Workflow

0. 我把你的请求改写成了什么

你的原始请求是:把这篇文章提炼为一篇用于企业内网运维场景可落地的端到端 AI workflow,必要时自行搜索网络教程和官方文档。

我将它改写为更可执行的交付目标:

> 基于 n8n 端到端 AI workflow 文章,结合 n8n 官方文档,写一份企业内网运维团队可试点落地的教程。教程必须包含:最小架构、部署方式、安全边界、完整工作流节点设计、结构化 AI 输出、人工审批、异常处理、3 个可复制场景、样例输入/输出、验收标准、失败处理和 4 周试点计划。

改写点:

1. 核心结论

企业内网落地 AI workflow,不应该从“自动修复生产故障”开始,而应该从“自动收集上下文、生成结构化诊断、给出低风险建议、等待人类审批、留下审计记录”开始。

最小可落地版本是:

监控/工单/人工表单
  -> n8n Webhook/Form Trigger
  -> 参数校验与资产信息补全
  -> 只读日志/指标/CMDB 查询
  -> 内网 LLM / AI Agent 结构化诊断
  -> JSON Schema 校验
  -> IF/Switch 风险分级
  -> 企业微信/Slack/Teams 人工审批
  -> 只读报告归档或低风险通知
  -> Error Workflow 统一告警

第一阶段的目标不是替代运维人员,而是把 20 分钟的信息收集和初步判断压缩到 1–3 分钟,并且输出可审计、可复核、可拒绝的建议。

2. 适用边界

适合先做:

暂时不要做:

3. 最小架构

[告警源/工单系统/人工入口]
  - Prometheus Alertmanager
  - Zabbix / Grafana Alerting
  - 企业微信机器人回调
  - 运维门户表单
  - n8n Form Trigger / Webhook

        |
        v

[n8n 内网编排层]
  - Webhook 或 Form Trigger
  - IF / Switch / Set / Code 节点
  - HTTP Request 查询内部只读 API
  - AI Agent 节点
  - Structured Output Parser
  - Human-in-the-loop / Send and Wait
  - Error Workflow

        |
        v

[只读上下文源]
  - CMDB 只读 API
  - Loki / Elasticsearch 日志查询 API
  - Prometheus 查询 API
  - Kubernetes 只读诊断 API
  - Runbook Markdown 仓库或知识库

        |
        v

[内网模型服务]
  - Ollama / vLLM / LM Studio / 兼容 OpenAI API 的内部网关
  - 第一阶段优先本地或内网模型
  - 禁止把生产日志、客户信息、密钥发送到公网模型

        |
        v

[人工审批与归档]
  - 企业微信 / Slack / Teams
  - 工单系统
  - n8n execution log
  - JSONL 审计文件或内部审计 API

4. 部署 n8n:内网试点版

4.1 Docker 单机试点

n8n 官方推荐 Docker 作为多数自托管场景的安装方式。第一阶段可先用单机 Docker,绑定内网地址,不暴露公网。

mkdir -p /opt/n8n/local-files
cd /opt/n8n

docker volume create n8n_data

# 生成一个 32 位随机十六进制字符串作为 n8n 凭据加密密钥,并在内网密钥库中安全备份。
# openssl rand -hex 16

# 完全离线内网环境请先将镜像导入企业私有仓库,例如:registry.ops.intra/n8nio/n8n:stable
docker run -d \
  --name n8n \
  --restart unless-stopped \
  -p 127.0.0.1:5678:5678 \
  -e GENERIC_TIMEZONE="Asia/Shanghai" \
  -e TZ="Asia/Shanghai" \
  -e N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true \
  -e N8N_RUNNERS_ENABLED=true \
  -e N8N_ENCRYPTION_KEY="此处替换为生成的32位安全密钥" \
  -e WEBHOOK_URL="http://n8n.ops.intra.example.com/" \
  -v n8n_data:/home/node/.n8n \
  -v /opt/n8n/local-files:/files \
  docker.n8n.io/n8nio/n8n:stable

说明:

4.2 反向代理建议

用 Caddy、Nginx 或 Traefik 放在 n8n 前面,做:

示例 Caddyfile:

n8n.ops.intra.example.com {
    reverse_proxy 127.0.0.1:5678
    encode gzip

    @not_allowed not remote_ip 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16
    respond @not_allowed "forbidden" 403
}

4.3 生产化前再考虑队列模式

n8n 队列模式需要 PostgreSQL + Redis + main/worker 分离。第一阶段不要过早上队列模式,除非已经出现并发执行瓶颈。

进入队列模式前至少确认:

5. 模型服务:内网优先,兼容 OpenAI API

第一阶段推荐部署一个内网 OpenAI-compatible 网关,让 n8n 只看到统一的 Chat Model 接口。

可选方案:

Ollama 示例:

# 在内网测试机安装 Ollama 后拉取模型
ollama pull qwen2.5:14b
ollama serve

如果使用 OpenAI-compatible 网关,n8n 侧配置:

Base URL: http://llm-gateway.ops.intra.example.com/v1
API Key: 使用 n8n Credentials 保存,不写入节点文本
Model: qwen2.5-14b-instruct 或企业内部批准模型

安全要求:

6. 主工作流:运维告警 AI 初诊断

这是从原文“文章提交与审批流程”迁移而来的运维版本。

6.1 节点总览

Webhook: Alert Intake
  -> Set: Normalize Alert
  -> IF: Required Fields Valid?
      false -> Respond: Invalid Alert + Notify Submitter
      true  -> HTTP Request: Query CMDB
           -> HTTP Request: Query Metrics
           -> HTTP Request: Query Logs
           -> Set: Build AI Context
           -> AI Agent: Diagnose Incident
           -> Structured Output Parser: IncidentDiagnosisSchema
           -> IF: risk_level == critical OR action_requires_approval == true
                true  -> Human Approval: On-call Lead
                      -> IF: approved?
                           true  -> Create/Update Ticket + Notify Channel
                           false -> Mark Rejected + Notify Channel
                false -> Create Ticket + Notify Channel
           -> Respond: Diagnosis Accepted

6.2 Webhook 输入样例

Webhook 只接收监控系统或运维门户发来的结构化 JSON。

{
  "alert_id": "ALERT-20260522-001",
  "source": "prometheus",
  "severity": "warning",
  "service": "payment-api",
  "namespace": "prod-payment",
  "cluster": "k8s-prod-a",
  "summary": "Pod restart count increased",
  "description": "payment-api restarted 5 times in 10 minutes",
  "started_at": "2026-05-22T10:20:00+08:00",
  "runbook_url": "https://wiki.intra/runbooks/payment-api-restart"
}

必填字段:

6.3 Normalize Alert 节点

用 Set 节点或 Code 节点统一字段名,避免不同监控源字段不一致。

Code 节点示例:

const input = $json;

return [{
  json: {
    alert_id: input.alert_id || input.labels?.alertname || `manual-${Date.now()}`,
    source: input.source || 'unknown',
    severity: input.severity || input.labels?.severity || 'unknown',
    service: input.service || input.labels?.service || input.app || 'unknown',
    namespace: input.namespace || input.labels?.namespace || 'default',
    cluster: input.cluster || input.labels?.cluster || 'unknown',
    summary: input.summary || input.annotations?.summary || '',
    description: input.description || input.annotations?.description || '',
    started_at: input.started_at || new Date().toISOString(),
    runbook_url: input.runbook_url || input.annotations?.runbook_url || ''
  }
}];

验收标准:

6.4 参数校验 IF 节点

条件:

{{ $json.alert_id }} is not empty
AND {{ $json.service }} is not empty
AND {{ $json.summary }} is not empty
AND {{ $json.cluster }} is not empty

失败分支响应:

{
  "accepted": false,
  "reason": "missing required alert fields",
  "required_fields": ["alert_id", "service", "summary", "cluster"]
}

6.5 查询 CMDB / 指标 / 日志

不要让 AI 自己随意查生产系统。由 workflow 通过固定 API 获取有限上下文,再交给模型。

CMDB 查询

HTTP Request:

GET http://cmdb.ops.intra.example.com/api/v1/services/{{ $json.service }}

返回样例:

{
  "service": "payment-api",
  "owner": "payment-sre",
  "tier": "tier1",
  "runtime": "kubernetes",
  "repo": "git.intra/payment/payment-api",
  "dashboard": "https://grafana.intra/d/payment-api",
  "normal_replicas": 6,
  "critical_dependencies": ["postgres-payment", "redis-payment"]
}

Prometheus 查询

HTTP Request:

GET http://prometheus.ops.intra.example.com/api/v1/query
query=sum(rate(container_cpu_usage_seconds_total{namespace="{{ $json.namespace }}",pod=~"{{ $json.service }}.*"}[5m]))

再查重启次数:

query=sum(increase(kube_pod_container_status_restarts_total{namespace="{{ $json.namespace }}",pod=~"{{ $json.service }}.*"}[15m]))

日志查询

HTTP Request 到 Loki 或 Elasticsearch,只取有限窗口和有限条数。

GET http://loki.ops.intra.example.com/loki/api/v1/query_range
query={namespace="{{ $json.namespace }}", app="{{ $json.service }}"} |= "ERROR"
limit=50

日志脱敏规则:

function maskSecrets(text) {
  return text
    .replace(/Bearer\s+[A-Za-z0-9._\-]+/g, 'Bearer ***')
    .replace(/password=[^\s&]+/gi, 'password=***')
    .replace(/token=[^\s&]+/gi, 'token=***')
    .replace(/[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}/g, '***@***');
}

return items.map(item => ({
  json: {
    ...item.json,
    sanitized_logs: maskSecrets(JSON.stringify(item.json.logs || []))
  }
}));

7. AI Agent:只做诊断,不直接执行

7.1 系统提示词模板

你是企业内网运维 AI 助手。你的任务是基于已提供的告警、CMDB、指标、日志和 Runbook 摘要,输出结构化初步诊断。

硬性规则:
1. 不要编造未提供的指标、日志、命令执行结果或生产事实。
2. 不要建议直接执行破坏性操作,例如 delete、drop、truncate、force、批量 kill、生产发布、数据库 DDL。
3. 所有生产变更类动作必须标记 action_requires_approval=true。
4. 如果证据不足,必须输出 confidence<=0.5,并列出 missing_context。
5. 输出必须符合 JSON Schema,不要输出 Markdown。
6. 建议优先级:先止血、再定位、再修复、最后复盘。
7. 如果涉及客户数据、密钥或隐私,必须标记 data_sensitivity="high"。

7.2 用户输入模板

告警:
{{ JSON.stringify($json.alert, null, 2) }}

CMDB:
{{ JSON.stringify($json.cmdb, null, 2) }}

指标摘要:
{{ JSON.stringify($json.metrics, null, 2) }}

日志摘要:
{{ $json.sanitized_logs }}

Runbook 摘要:
{{ $json.runbook_excerpt }}

请给出结构化诊断、风险等级、建议动作、需要人工确认的地方和下一步检查项。

7.3 Structured Output Parser JSON Schema

n8n 的 Structured Output Parser 可以基于 JSON Schema 约束输出字段。建议使用手写 JSON Schema,不要只依赖自然语言提示词。

{
  "type": "object",
  "properties": {
    "incident_type": {
      "type": "string",
      "enum": ["pod_restart", "high_cpu", "high_memory", "db_slow_query", "network_error", "unknown"]
    },
    "risk_level": {
      "type": "string",
      "enum": ["low", "medium", "high", "critical"]
    },
    "confidence": {
      "type": "number",
      "minimum": 0,
      "maximum": 1
    },
    "summary": {
      "type": "string"
    },
    "evidence": {
      "type": "array",
      "items": {
        "type": "string"
      }
    },
    "likely_causes": {
      "type": "array",
      "items": {
        "type": "string"
      }
    },
    "recommended_actions": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "action": { "type": "string" },
          "risk": { "type": "string", "enum": ["read_only", "low", "medium", "high"] },
          "requires_approval": { "type": "boolean" },
          "expected_result": { "type": "string" },
          "rollback": { "type": "string" }
        },
        "required": ["action", "risk", "requires_approval", "expected_result", "rollback"]
      }
    },
    "missing_context": {
      "type": "array",
      "items": { "type": "string" }
    },
    "data_sensitivity": {
      "type": "string",
      "enum": ["low", "medium", "high"]
    },
    "action_requires_approval": {
      "type": "boolean"
    }
  },
  "required": [
    "incident_type",
    "risk_level",
    "confidence",
    "summary",
    "evidence",
    "likely_causes",
    "recommended_actions",
    "missing_context",
    "data_sensitivity",
    "action_requires_approval"
  ]
}

7.4 期望输出样例

{
  "incident_type": "pod_restart",
  "risk_level": "medium",
  "confidence": 0.78,
  "summary": "payment-api 在 15 分钟内多次重启,日志中出现数据库连接池耗尽,CMDB 显示该服务依赖 postgres-payment。",
  "evidence": [
    "restart increase over 15m = 5",
    "logs contain connection pool exhausted",
    "service tier=tier1 and normal_replicas=6"
  ],
  "likely_causes": [
    "数据库连接池耗尽导致健康检查失败",
    "上游流量突增导致连接占用时间延长"
  ],
  "recommended_actions": [
    {
      "action": "检查 postgres-payment 当前连接数和慢查询,不做写操作",
      "risk": "read_only",
      "requires_approval": false,
      "expected_result": "确认连接数是否接近上限,以及是否存在慢查询堆积",
      "rollback": "无生产变更"
    },
    {
      "action": "如确认连接池耗尽,建议由值班负责人审批后临时扩容 payment-api 副本数",
      "risk": "medium",
      "requires_approval": true,
      "expected_result": "降低单 Pod 连接压力并缓解错误率",
      "rollback": "恢复原 replica 数"
    }
  ],
  "missing_context": [
    "最近一次发布记录",
    "数据库当前 max_connections 配置"
  ],
  "data_sensitivity": "medium",
  "action_requires_approval": true
}

8. 人工审批:把高风险动作卡住

n8n 官方支持 Human-in-the-loop:当 AI Agent 想调用某些工具时,可以先暂停并通过 Slack、Telegram、Teams、Gmail 等渠道请求人工审批。

> 内网隔离下的网络可达性限制 > > 如果 n8n 部署在私有内网,而审批渠道使用公网 SaaS 版企业微信、钉钉、飞书、Slack 或 Teams,外部平台的审批回调可能无法访问内网 WEBHOOK_URL,导致等待审批节点一直卡住。 > > 可落地方案: > > 1. 纯内网协同:优先使用私有化部署的协同工具,例如内网 Mattermost、私有化飞书或私有化钉钉,让回调流量始终在内网闭环。 > 2. n8n Form 审批流(推荐试点):用 Form Trigger 或内部审批页面生成内网审批链接,机器人只发送文本通知和值班链接;审批人通过内网 PC/VPN 打开链接完成 Approve/Reject,避免依赖公网 SaaS 回调穿透内网。 > 3. 审计优先:无论采用哪种审批入口,审批结果都要写入工单或审计 API,不只保留在聊天记录里。

企业内网运维建议:

审批消息模板:

【AI 运维建议待审批】
告警:{{ $json.alert_id }}
服务:{{ $json.service }} / {{ $json.namespace }} / {{ $json.cluster }}
风险等级:{{ $json.risk_level }}
置信度:{{ $json.confidence }}

建议动作:
{{ JSON.stringify($json.recommended_actions, null, 2) }}

证据:
{{ $json.evidence.join('\n') }}

请审批:Approve / Reject

审批拒绝后的处理:

{
  "status": "rejected_by_human",
  "next_step": "请值班人员手动处理,AI 不再继续推进动作",
  "audit_required": true
}

9. 异常处理:Error Workflow 必须单独建

n8n 官方 Error Workflow 需要以 Error Trigger 开始,并在主 workflow 的 Settings 里绑定。

建议创建一个通用 Ops AI Error Handler

Error Trigger
  -> Set: Normalize Error
  -> HTTP Request: Send to 企业微信/Slack/Teams
  -> HTTP Request: Write Audit Event

告警内容模板:

【n8n Workflow 执行失败】
Workflow: {{ $json.workflow.name }}
Execution: {{ $env.N8N_EDITOR_BASE_URL }}/workflow/{{ $json.workflow.id }}/executions/{{ $json.execution.id }}
Last node: {{ $json.execution.lastNodeExecuted }}
Error: {{ $json.execution.error.message }}

处理建议:
1. 先打开 execution URL 查看失败节点输入输出。
2. 如果失败在模型节点,检查模型网关超时/限流。
3. 如果失败在 HTTP Request,检查目标系统可达性和凭证有效性。
4. 如果失败在 Structured Output Parser,检查模型是否返回了非 JSON。

失败处理原则:

10. 场景一:Kubernetes Pod 重启初诊断

目标

当某个服务 Pod 在短时间内频繁重启时,自动收集基础上下文并生成初步诊断报告。

样例输入

{
  "alert_id": "K8S-RESTART-001",
  "source": "prometheus",
  "severity": "warning",
  "service": "order-api",
  "namespace": "prod-order",
  "cluster": "k8s-prod-a",
  "summary": "order-api pod restarted frequently",
  "description": "restart count increased by 6 in 10 minutes",
  "started_at": "2026-05-22T11:00:00+08:00"
}

n8n 节点

Webhook
  -> Normalize Alert
  -> HTTP Request: CMDB service lookup
  -> HTTP Request: Prometheus restart query
  -> HTTP Request: Loki error logs query
  -> AI Agent + Structured Output Parser
  -> IF risk high?
  -> Human Approval or Notify Channel

AI 需要判断

验收标准

失败处理

11. 场景二:数据库慢查询和连接数异常初分析

目标

当数据库出现慢查询、连接数过高或应用报连接池耗尽时,自动生成只读分析报告,并把潜在高风险操作交给 DBA 审批。

样例输入

{
  "alert_id": "DB-SLOW-001",
  "source": "grafana",
  "severity": "critical",
  "service": "billing-api",
  "database": "postgres-billing",
  "summary": "database active connections above threshold",
  "description": "active connections > 90% for 5 minutes",
  "started_at": "2026-05-22T11:10:00+08:00"
}

上下文查询

只读 SQL API 或内部 DBA API 返回:

{
  "active_connections": 185,
  "max_connections": 200,
  "top_queries": [
    {
      "query_id": "q123",
      "avg_time_ms": 3200,
      "calls": 142,
      "sample": "select * from invoice where status = ? order by created_at desc"
    }
  ],
  "locks": [],
  "replication_lag_seconds": 0
}

AI 输出限制

AI 可以建议:

AI 不可以直接建议:

期望输出

{
  "incident_type": "db_slow_query",
  "risk_level": "critical",
  "confidence": 0.74,
  "summary": "billing-api 连接数接近上限,top query 显示 invoice 查询耗时高且调用频繁。",
  "recommended_actions": [
    {
      "action": "DBA 只读检查 q123 的执行计划和索引命中情况",
      "risk": "read_only",
      "requires_approval": false,
      "expected_result": "确认慢查询是否由缺索引或过滤条件导致",
      "rollback": "无生产变更"
    },
    {
      "action": "暂停低优先级账单批处理任务 15 分钟",
      "risk": "medium",
      "requires_approval": true,
      "expected_result": "释放连接并降低业务请求失败率",
      "rollback": "恢复批处理调度"
    }
  ]
}

验收标准

12. 场景三:变更单上线前 AI 风险预审

目标

在上线前自动读取变更单、部署计划、回滚方案和影响服务,生成结构化风险预审,帮助值班负责人决定是否放行。

样例输入

{
  "change_id": "CHG-20260522-008",
  "service": "inventory-api",
  "namespace": "prod-inventory",
  "deploy_time": "2026-05-22T22:00:00+08:00",
  "change_summary": "upgrade inventory-api from v1.8.2 to v1.9.0",
  "rollback_plan": "rollback image tag to v1.8.2 and restart deployment",
  "risk_notes": "includes database migration for new column"
}

节点设计

Form Trigger: Change Review Form
  -> Validate Required Fields
  -> HTTP Request: CMDB service dependencies
  -> HTTP Request: Recent incidents for service
  -> HTTP Request: Deployment freeze calendar
  -> AI Agent: Change Risk Review
  -> Structured Output Parser
  -> IF risk high or missing rollback?
      true -> Human Approval: SRE Lead
      false -> Create Review Comment

结构化输出字段

{
  "change_risk": "low|medium|high|blocker",
  "release_window_ok": true,
  "rollback_plan_ok": true,
  "dependency_risks": ["string"],
  "required_prechecks": ["string"],
  "approval_required": true,
  "block_reasons": ["string"],
  "summary_for_reviewer": "string"
}

验收标准

失败处理

13. 场景四:每日运维巡检报告

目标

每天固定时间自动汇总核心服务健康度,生成巡检报告并推送给值班群。

节点设计

Schedule Trigger: 每天 09:00
  -> HTTP Request: 服务清单
  -> Split In Batches: 每个服务
  -> HTTP Request: 指标摘要
  -> HTTP Request: 最近 24h 告警
  -> AI Agent: Summarize Service Health
  -> Merge: 汇总所有服务
  -> AI Agent: Generate Daily Ops Report
  -> Send Message: 企业微信/Teams
  -> Write Audit: 保存报告

输出形态

【每日运维巡检】2026-05-22

总体状态:黄色

重点风险:
1. payment-api 昨夜 2 次重启,已恢复,建议检查连接池。
2. billing-db 连接数长期高于 75%,建议 DBA 评估慢查询。
3. search-api P95 延迟较昨日上升 30%,建议观察索引任务。

需要人工跟进:
- CHG-20260522-008 涉及数据库迁移,回滚方案不完整。

无异常服务:
- user-api
- auth-api
- notification-api

验收标准

14. 安全与合规清单

上线前逐项确认:

15. 4 周试点计划

第 1 周:单机闭环

目标:跑通一个只读场景。

任务:

验收:

第 2 周:小团队试点

目标:让 2–3 名运维人员在真实低风险告警中使用。

任务:

验收:

第 3 周:规则固化

目标:把试点中的隐性经验变成规则。

任务:

验收:

第 4 周:有限扩展

目标:从一个场景扩展到 2–3 个场景,但不扩大权限。

任务:

验收:

16. 最小验收清单

技术验收:

业务验收:

安全验收:

17. 常见失败与处理

17.1 模型输出不是合法 JSON

处理:

17.2 指标或日志查询超时

处理:

17.3 AI 建议了危险动作

处理:

危险动作拦截示例:

// 采用浅拷贝,避免直接修改 n8n Code 节点中的只读 $json Proxy 对象。
const dangerous = /\b(delete|drop|truncate|force|kill\s+-9)\b|kubectl\s+delete/i;
const output = { ...$json };
const text = JSON.stringify(output.recommended_actions || []);

output.policy_violation = dangerous.test(text);
if (output.policy_violation) {
  output.action_requires_approval = true;
  output.risk_level = output.risk_level === 'critical' ? 'critical' : 'high';
}

return [{ json: output }];

17.4 人工审批超时

处理:

17.5 n8n 自身故障

处理:

18. 管理层摘要

这套方案不是“让 AI 自动运维”,而是“让 AI 成为有边界的初级值班助手”。

它的价值:

不建议第一阶段追求:

推荐先用 4 周完成小范围试点,证明“只读诊断 + 人工审批 + 审计闭环”稳定后,再决定是否扩展到更多服务和更高自动化等级。

19. 参考链接