智能运维评审如何识别隐性风险把大模型接入运维系统最需要评审的不是回答写得像不像专家而是它能看到什么、能建议什么、建议会不会被当成命令执行。模型输出有不确定性日志和告警也可能含有错误或恶意文本两者之间必须有一层不依赖模型判断的控制逻辑。把诊断、决策和执行拆开诊断服务可以读取已经脱敏的日志、指标和事件生成假设与建议。它不应直接拿到kubectl exec、删除资源、修改流量或重启数据库的凭据。需要变更时系统先生成结构化提案校验目标范围、风险级别和变更窗口再由审批流程或预先定义的自动化规则决定是否执行。紧急动作也应有最小权限、审计记录和停止开关。type Proposal struct { Action string json:action Namespace string json:namespace Resource string json:resource } func allowed(p Proposal) bool { return p.Action describe || p.Action get_logs }这段代码故意只允许只读动作。真正的参数校验不能只查危险字符还要使用受限的 API 客户端、固定的资源类型和命名空间范围。字符串过滤容易漏掉编码、语义和库调用层面的绕过。上下文是外部输入不是可信指令日志行、工单标题和监控标签都可能被拼入提示词。传入模型前应进行长度限制、脱敏、字段白名单和分段处理并把它们明确标记为“待分析的数据”而不是系统规则。不要把密码、访问令牌、完整请求体或客户数据送给模型供应链。对模型输出采用严格 schema 解析字段不完整、枚举不合法或内容超长时直接拒绝而不是猜测其意图。系统还要设置调用超时、并发上限、会话轮数和成本预算。模型失败时返回已有的仪表盘链接、查询建议或人工升级入口即可不能为了给出答案而无限重试。置信度分数可以作为排序信号却不能成为自动执行生产变更的授权依据。评审要覆盖故障当天的路径检查 PR 时除了正常诊断要测试输入注入、权限不足、工具超时、重复告警、过大日志和模型返回无效 JSON。演练一个只读影子模式收集提案、与人工结论对照、记录误报漏报但不触碰生产资源。上线后监控工具调用拒绝率、延迟、上下文裁剪量和人工否决原因。最后确认谁能禁用 Agent、谁能查看审计记录、恢复后如何清理临时权限。AIOps 可以缩短检索信息的时间但它不能替运维团队承担变更责任。把不可逆动作留在可验证的人和规则手里才是评审真正要守住的边界。评审记录还应写明数据保留期限、供应商故障时的替代流程以及用于评估效果的指标。没有这些运营约束最初安全的只读助手也可能在后续迭代中逐渐获得不该有的访问范围。每次新增工具或上下文字段都应重新检查它是否改变了风险边界。