企业内网运维场景:用 n8n 落地端到端 AI Workflow
- 原始文章:How to build your first end-to-end AI workflow in n8n
- 原文 URL:https://thenewstack.io/build-n8n-ai-workflow/
- 原始分享链接:https://share.google/PAFFeWyFg3tWfqcsS
- 上游总结路径:/home/lin/.hermes/projects/hermes-gsummary-workflow/runs/outputs/20260522-191154-How-to-build-your-first-end-to-end-AI-workflow-in-n8n-2212124-788521280-summary.md
- 补充参考:n8n 官方 Docker、自托管、Webhook、Structured Output Parser、Human-in-the-loop、Error Workflow 文档
0. 我把你的请求改写成了什么
你的原始请求是:把这篇文章提炼为一篇用于企业内网运维场景可落地的端到端 AI workflow,必要时自行搜索网络教程和官方文档。
我将它改写为更可执行的交付目标:
> 基于 n8n 端到端 AI workflow 文章,结合 n8n 官方文档,写一份企业内网运维团队可试点落地的教程。教程必须包含:最小架构、部署方式、安全边界、完整工作流节点设计、结构化 AI 输出、人工审批、异常处理、3 个可复制场景、样例输入/输出、验收标准、失败处理和 4 周试点计划。
改写点:
- 将“企业内网运维场景”收敛为“只读诊断 + 结构化建议 + 人工审批 + 审计归档”的安全试点,而不是一开始就让 AI 自动改生产。
- 将原文的“文章投稿工作流”迁移为“运维告警/变更/巡检工作流”。
- 补充 n8n 官方能力:Docker 自托管、Webhook、Structured Output Parser、Human-in-the-loop、Error Workflow。
- 明确第一阶段禁止自动执行生产写操作,所有高风险动作必须人工审批。
1. 核心结论
企业内网落地 AI workflow,不应该从“自动修复生产故障”开始,而应该从“自动收集上下文、生成结构化诊断、给出低风险建议、等待人类审批、留下审计记录”开始。
最小可落地版本是:
监控/工单/人工表单
-> n8n Webhook/Form Trigger
-> 参数校验与资产信息补全
-> 只读日志/指标/CMDB 查询
-> 内网 LLM / AI Agent 结构化诊断
-> JSON Schema 校验
-> IF/Switch 风险分级
-> 企业微信/Slack/Teams 人工审批
-> 只读报告归档或低风险通知
-> Error Workflow 统一告警第一阶段的目标不是替代运维人员,而是把 20 分钟的信息收集和初步判断压缩到 1–3 分钟,并且输出可审计、可复核、可拒绝的建议。
2. 适用边界
适合先做:
- Kubernetes Pod 异常初诊断。
- 数据库慢查询/连接数异常初分析。
- 变更单上线前风险预审。
- 每日巡检报告生成。
- 告警聚合和重复告警归并。
暂时不要做:
- 自动重启生产服务。
- 自动执行
kubectl delete、数据库 DDL、批量变更、发布回滚。 - 让 AI 直接连接生产数据库写入数据。
- 让 AI 自由调用 shell 命令。
- 在没有审批和审计的情况下对外发通知或关闭工单。
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 审计文件或内部审计 API4. 部署 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说明:
n8n_data保存 SQLite 数据库、凭证、workflow、加密相关文件。N8N_ENCRYPTION_KEY必须固定并安全备份;容器重建、迁移 PostgreSQL 或恢复备份时都要使用同一个值,否则 n8n Credentials 中的密钥可能无法解密。/files用于读写试点样例文件,不要挂载生产敏感目录。WEBHOOK_URL应设置为内网可访问的反向代理地址。- 如果需要给监控系统回调,使用内网 DNS + 反向代理,不建议用公网穿透。
- 完全离线环境不要依赖公网镜像地址;先通过
docker save/load或企业 Harbor/Registry 分发镜像。
4.2 反向代理建议
用 Caddy、Nginx 或 Traefik 放在 n8n 前面,做:
- 内网 TLS。
- IP allowlist。
- SSO 或基础认证。
- 访问日志。
- 请求大小限制。
示例 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 分离。第一阶段不要过早上队列模式,除非已经出现并发执行瓶颈。
进入队列模式前至少确认:
- PostgreSQL 已替代 SQLite。
- 所有实例共享同一个
N8N_ENCRYPTION_KEY。 - Redis 高可用或至少可监控。
- Worker health check 已接入监控。
- 二进制数据不用本地文件系统共享,必要时使用对象存储。
5. 模型服务:内网优先,兼容 OpenAI API
第一阶段推荐部署一个内网 OpenAI-compatible 网关,让 n8n 只看到统一的 Chat Model 接口。
可选方案:
- Ollama:简单,适合单机试点和中文/英文通用任务。
- vLLM:适合 GPU 服务器和较高并发。
- LM Studio:适合个人验证,不建议作为团队生产服务。
- 企业已有模型网关:优先使用,便于审计和权限控制。
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 或企业内部批准模型安全要求:
- 不把公网 API Key 写在 workflow 节点里。
- 不把生产日志原文长期保存到模型提示词记录里。
- 先脱敏再进入模型:手机号、身份证、Token、Cookie、数据库密码、客户名称等必须掩码。
- 正则脱敏只能作为兜底;更可靠的做法是在 Loki LogQL、CMDB 查询参数、API 网关或日志采集侧先过滤敏感字段。
- 模型输出只能作为建议,不能直接作为生产动作。
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 Accepted6.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"
}必填字段:
alert_idsourceseverityservicenamespaceclustersummarystarted_at
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 || ''
}
}];验收标准:
- 任意入口都能输出统一字段。
- 缺少
service、summary等关键字段时进入失败分支。 - 不把原始 payload 中的 Token、Cookie、Authorization 字段传给 AI。
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,不只保留在聊天记录里。
企业内网运维建议:
- 第一阶段所有写操作工具都必须启用人工审批。
- 审批消息必须展示:告警 ID、服务、风险等级、AI 建议动作、证据、回滚方式。
- 审批人只能是值班负责人或服务 owner。
- 审批结果必须归档到工单或审计日志。
审批消息模板:
【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。失败处理原则:
- 失败时不自动重试高风险动作。
- 查询类节点可重试 1–2 次。
- 模型节点超时后降级为“需要人工分析”,而不是生成猜测结论。
- 所有失败都要保留 execution URL 或内部审计 ID。
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 ChannelAI 需要判断
- 是否存在 OOMKilled。
- 是否存在启动探针或存活探针失败。
- 是否最近发布过新版本。
- 是否日志出现数据库、缓存、配置或依赖错误。
- 是否需要人工审批扩容或回滚。
验收标准
- 输出包含至少 3 条证据。
- 不能建议直接
kubectl delete pod作为默认动作。 - 所有变更类建议必须
requires_approval=true。 - 置信度低于 0.5 时必须列出缺失上下文。
失败处理
- Prometheus 查询失败:继续执行,但
missing_context必须包含指标缺失。 - Loki 查询失败:继续执行,但禁止给出高置信度根因。
- 模型输出非 JSON:进入 Error Workflow,不继续通知为“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 可以建议:
- 检查应用连接池配置。
- 暂停非核心批处理。
- 联系 DBA 查看慢查询执行计划。
- 走审批后扩容连接池或实例资源。
AI 不可以直接建议:
- Kill 生产连接。
- 修改数据库参数。
- 执行 DDL。
- Drop index / create index on production without review。
期望输出
{
"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": "恢复批处理调度"
}
]
}验收标准
- 不把 SQL 原文里的敏感字段泄露到公开群。
- 所有写操作必须审批。
- 报告里必须区分“已观察证据”和“推测原因”。
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"
}验收标准
- 如果
rollback_plan为空,必须输出change_risk=blocker。 - 如果涉及数据库迁移,必须
approval_required=true。 - 如果服务近 24 小时有 P1/P2 故障,必须提示延后或提高审批等级。
失败处理
- CMDB 不可用:不自动放行,输出“上下文不足,需要人工审核”。
- 冻结窗口 API 不可用:不自动放行。
- AI 输出无法解析:进入人工审核,不生成通过结论。
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. 安全与合规清单
上线前逐项确认:
- 模型服务部署在内网或经过企业批准的模型网关。
- n8n workflow 不保存明文 Token、Cookie、数据库密码。
- 所有 API Key 使用 n8n Credentials 管理。
- 第一阶段不启用 AI 直接执行生产写操作。
- Execute Command 节点默认不启用;如必须使用,只能运行白名单脚本,且在隔离容器中执行。
- 日志进入模型前已脱敏。
- 高风险动作必须人工审批。
- 审批消息包含证据、风险、预期结果、回滚方式。
- Error Workflow 已配置。
- workflow execution 日志保留策略已确定。
- 查询 Metrics / Logs / CMDB 的节点已按敏感级别配置
Save execution data: Don't Save,避免 n8n 数据库长期保存敏感上下文。 - 已配置执行历史清理策略,例如
EXECUTIONS_DATA_PRUNE=true和EXECUTIONS_DATA_MAX_AGE=168,把敏感历史和数据库膨胀控制在可接受范围内。 - 失败时默认转人工,不默认继续自动推进。
- 测试环境和生产环境 workflow 分离。
15. 4 周试点计划
第 1 周:单机闭环
目标:跑通一个只读场景。
任务:
- 部署 n8n 单机 Docker。
- 接入内网模型或测试模型网关。
- 做一个 Webhook 告警入口。
- 固定返回 1–2 个模拟 CMDB/指标/日志接口。
- 完成 Structured Output Parser。
- 生成第一份结构化诊断报告。
验收:
- 输入样例告警后,能输出合法 JSON。
- 缺字段进入失败分支。
- 模型输出非 JSON 能被拦截。
第 2 周:小团队试点
目标:让 2–3 名运维人员在真实低风险告警中使用。
任务:
- 接入真实 CMDB 只读 API。
- 接入 Prometheus/Loki 只读查询。
- 推送到企业微信或 Teams。
- 每条 AI 建议都要求人工确认。
验收:
- 至少处理 10 条真实或半真实告警。
- 人工反馈记录“有用/无用/错误原因”。
- 不发生任何未经审批的生产动作。
第 3 周:规则固化
目标:把试点中的隐性经验变成规则。
任务:
- 固化高风险动作列表。
- 固化脱敏规则。
- 固化不同告警类型的 JSON Schema。
- 增加 Error Workflow。
- 增加审计日志。
验收:
- 每条输出都能追溯到输入和上下文来源。
- 高风险建议 100% 进入审批分支。
- 错误执行有统一告警。
第 4 周:有限扩展
目标:从一个场景扩展到 2–3 个场景,但不扩大权限。
任务:
- 增加数据库慢查询初分析。
- 增加上线前变更风险预审。
- 增加每日巡检报告。
- 评估是否需要 PostgreSQL/Redis/Queue mode。
验收:
- 每个场景都有样例输入、预期输出和失败处理。
- 仍保持只读或人工审批写操作。
- 明确下一阶段是否值得投入生产化。
16. 最小验收清单
技术验收:
- n8n 可在内网访问。
- Webhook Test URL 和 Production URL 行为已区分。
- Structured Output Parser 能拦截非 JSON 输出。
- Error Workflow 已绑定主工作流。
- Credentials 中没有硬编码 Token。
- 日志脱敏规则已测试。
业务验收:
- 运维人员能理解 AI 输出。
- 每条建议都有证据。
- 高风险动作不会绕过人工审批。
- 输出能进入工单或审计系统。
- 失败时系统不会误报“已完成诊断”。
安全验收:
- 模型不接触未脱敏敏感数据。
- workflow 不拥有生产写权限。
- AI 不直接执行 shell。
- 审批记录可追溯。
- 回滚路径明确。
17. 常见失败与处理
17.1 模型输出不是合法 JSON
处理:
- Structured Output Parser 拦截。
- 进入 Error Workflow。
- 通知值班人员“AI 诊断失败,需要人工处理”。
- 不把自由文本当成正式诊断。
17.2 指标或日志查询超时
处理:
- 查询类节点可重试 1–2 次。
- 超时后继续生成低置信度报告。
missing_context必须包含缺失项。- 不允许输出高置信度根因。
17.3 AI 建议了危险动作
处理:
- 通过后置 Code 节点扫描危险关键词。
- 命中
delete/drop/truncate/force/kubectl delete/kill -9等词时,强制改为人工审批。 - 审批消息标记“高风险建议”。
危险动作拦截示例:
// 采用浅拷贝,避免直接修改 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 人工审批超时
处理:
- 设置等待超时时间。
- 超时后标记为
approval_timeout。 - 通知值班群。
- 不执行任何写操作。
17.5 n8n 自身故障
处理:
- 保留主机/容器监控。
- 持久化
/home/node/.n8n。 - 定期导出 workflow。
- 生产化前迁移 PostgreSQL。
- 关键场景配置外部告警,不依赖 n8n 自己给自己报故障。
18. 管理层摘要
这套方案不是“让 AI 自动运维”,而是“让 AI 成为有边界的初级值班助手”。
它的价值:
- 减少告警上下文收集时间。
- 降低低级漏查概率。
- 让诊断输出结构化、可审计。
- 把高风险动作挡在人工审批前。
- 为后续更成熟的自动化积累真实样本。
不建议第一阶段追求:
- 全自动修复。
- 大规模多团队统一平台。
- 复杂多智能体系统。
- 直接接管生产变更。
推荐先用 4 周完成小范围试点,证明“只读诊断 + 人工审批 + 审计闭环”稳定后,再决定是否扩展到更多服务和更高自动化等级。
19. 参考链接
- The New Stack 原文:https://thenewstack.io/build-n8n-ai-workflow/
- n8n Docker 安装:https://docs.n8n.io/hosting/installation/docker/
- n8n Webhook 常见问题:https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.webhook/common-issues/
- n8n Structured Output Parser:https://docs.n8n.io/integrations/builtin/cluster-nodes/sub-nodes/n8n-nodes-langchain.outputparserstructured/
- n8n Human-in-the-loop:https://docs.n8n.io/advanced-ai/human-in-the-loop-tools/
- n8n Error Workflow:https://docs.n8n.io/flow-logic/error-handling/
- n8n Queue Mode:https://docs.n8n.io/hosting/scaling/queue-mode/