基于大模型的运维 SOP 自动生成与执行：从经验文档到可执行脚本，运维知识的工程化

基于大模型的运维 SOP 自动生成与执行：从经验文档到可执行脚本，运维知识的工程化

一、运维 SOP 的工程困境：文档与执行的鸿沟

运维标准操作流程（SOP）是保障运维操作一致性与安全性的核心文档。然而，传统 SOP 以文档形式存在，面临三个根本性问题：一是文档与实际操作脱节——SOP 描述的是"应该怎么做"，但实际执行时运维人员可能因时间压力或习惯偏离文档；二是文档更新滞后——系统架构变更后，SOP 往往数周甚至数月后才更新；三是文档不可执行——SOP 是自然语言描述，无法直接转化为可运行的脚本。

大模型驱动的 SOP 自动生成，将运维知识从"静态文档"升级为"可执行代码"：模型根据故障描述自动生成操作步骤，并输出可执行的 Shell/Python 脚本，运维人员审核后一键执行。这一范式将运维知识从"人脑记忆"外化为"可复现的代码"。

二、从故障描述到可执行 SOP 的生成链路

flowchart TD A[故障描述] --> B[意图解析] B --> C[知识检索] C --> D[SOP 步骤生成] D --> E[脚本代码生成] E --> F[安全审查] F --> G[人工审核] G --> H[执行与反馈] subgraph 知识源 C1[历史工单库] C2[运维 Wiki] C3[Runbook 文档] C4[监控指标关联] end subgraph 安全审查 F1[危险命令检测] F2[影响面评估] F3[回滚方案验证] end C --> C1 C --> C2 C --> C3 C --> C4 F --> F1 F --> F2 F --> F3

关键环节是"安全审查"：生成的脚本必须经过危险命令检测（如rm -rf /、DROP TABLE）、影响面评估（操作会影响哪些服务）、回滚方案验证（操作失败后如何恢复）。安全审查不通过的脚本禁止执行。

三、工程实现：SOP 自动生成与执行系统

# sop_generator.py — 运维 SOP 自动生成引擎 from dataclasses import dataclass from typing import List, Optional import re @dataclass class SOPStep: order: int description: str command: Optional[str] verification: str # 验证步骤 rollback_command: str # 回滚命令 risk_level: str # low, medium, high @dataclass class GeneratedSOP: title: str incident_type: str steps: List[SOPStep] prerequisites: List[str] estimated_duration: str risk_summary: str class SOPGenerator: """运维 SOP 自动生成器""" DANGEROUS_PATTERNS = [ r'rm\s+-rf\s+/', r'DROP\s+TABLE', r'DELETE\s+FROM\s+\w+\s*;', # 无 WHERE 的 DELETE r'SHUTDOWN', r'reboot', r'kubectl\s+delete\s+namespace', r'docker\s+system\s+prune\s+-a', ] def generate_sop(self, incident_description: str) -> GeneratedSOP: """根据故障描述生成 SOP""" # 1. 意图解析 intent = self._parse_intent(incident_description) # 2. 知识检索：查找历史相似工单与 Runbook context = self._retrieve_knowledge(intent) # 3. LLM 生成 SOP 步骤 prompt = f"""作为运维工程师，根据以下故障描述生成标准操作流程（SOP）。 故障描述：{incident_description} 故障类型：{intent['type']} 受影响服务：{intent['affected_services']} 历史参考：{context} 要求： 1. 每个步骤包含：描述、执行命令、验证方法、回滚命令 2. 命令必须包含完整的参数，可直接复制执行 3. 验证方法必须可自动化检查 4. 回滚命令必须能撤销当前步骤的影响 5. 标注每个步骤的风险等级 输出 JSON 格式： {{ "title": "SOP 标题", "steps": [ {{ "order": 1, "description": "步骤描述", "command": "执行命令", "verification": "验证命令", "rollback_command": "回滚命令", "risk_level": "low|medium|high" }} ], "prerequisites": ["前置条件"], "estimated_duration": "预估时间", "risk_summary": "风险摘要" }}""" response = self._call_llm(prompt, temperature=0.1) sop_data = self._parse_response(response) # 4. 安全审查 sop_data = self._security_review(sop_data) return sop_data def _security_review(self, sop: dict) -> GeneratedSOP: """安全审查：检测危险命令与缺失的回滚方案""" steps = [] for step_data in sop.get('steps', []): command = step_data.get('command', '') risk_level = step_data.get('risk_level', 'low') # 危险命令检测 for pattern in self.DANGEROUS_PATTERNS: if re.search(pattern, command, re.IGNORECASE): risk_level = 'high' step_data['description'] += ( f' [⚠️ 危险命令检测: {pattern}]' ) break # 回滚方案验证 if not step_data.get('rollback_command'): risk_level = 'high' step_data['description'] += ' [⚠️ 缺少回滚方案]' steps.append(SOPStep( order=step_data['order'], description=step_data['description'], command=step_data.get('command'), verification=step_data.get('verification', ''), rollback_command=step_data.get('rollback_command', ''), risk_level=risk_level, )) return GeneratedSOP( title=sop.get('title', ''), incident_type=sop.get('incident_type', ''), steps=steps, prerequisites=sop.get('prerequisites', []), estimated_duration=sop.get('estimated_duration', ''), risk_summary=sop.get('risk_summary', ''), ) def _parse_intent(self, description: str) -> dict: """解析故障描述的意图""" prompt = f"""从以下故障描述中提取结构化信息： {description} 输出 JSON：{{"type": "故障类型", "affected_services": ["服务列表"], "severity": "critical|warning|info"}}""" response = self._call_llm(prompt, temperature=0.1) return self._parse_response(response) def _retrieve_knowledge(self, intent: dict) -> str: """检索历史工单与 Runbook""" # 简化实现：实际应查询向量数据库 return f"故障类型 {intent['type']} 的历史处理记录"

四、SOP 自动生成的边界与权衡

生成脚本的可靠性：LLM 生成的 Shell/SQL 命令可能包含语法错误或不适用于当前环境的参数。建议在审核流程中增加"沙箱预执行"——在隔离环境中 dry-run 生成的脚本，验证语法与逻辑正确性。

环境差异的适配：不同环境（开发/测试/生产）的配置差异（主机名、端口、数据库名）需要参数化。建议在 SOP 模板中使用变量占位符（如{{DB_HOST}}），执行时根据目标环境自动替换。

知识库的时效性：RAG 检索的知识如果过时（如已废弃的运维工具），生成的 SOP 可能包含无效操作。建议对知识库设置过期机制，超过 6 个月未更新的文档标记为"待验证"。

人工审核的必要性：AI 生成的 SOP 必须经过人工审核才能执行，特别是 high 风险步骤。审核重点：命令是否正确、影响面是否可控、回滚方案是否可行。AI 生成的是"草稿"，人工审核是"把关"。

五、总结

大模型驱动的 SOP 自动生成，将运维知识从"静态文档"升级为"可执行代码"。核心机制是意图解析提取故障特征、知识检索提供历史参考、LLM 生成操作步骤与脚本、安全审查检测危险命令。工程落地的关键在于：危险命令检测防止误操作、回滚方案验证保障可逆性、环境参数化适配多环境、人工审核不可省略。SOP 自动生成的目标是加速运维响应，而非替代人工判断——AI 生成草稿，人工审核把关，两者结合才能实现安全高效的运维自动化。