经验为什么总留在群里？一个 DevOps 运维团队把 AI 用进生产的复盘

凌晨两点，告警又响了。

值班的同学先翻历史群聊，找"上次谁处理过类似问题"，再私聊那位熟悉的同事确认思路；初步定位后，要把日志、时间窗、处理过程重新整理一遍，转给研发。等故障恢复，工单里的根因和处置记录还没补完。

第二天，同类问题又来了。IT运维团队又一次从"谁处理过"开始找答案。

这不是一家的问题。我们后来和不少金融、制造行业的运维团队聊，发现大家卡在几乎一样的三个断点上：经验留在人身上，信息断在系统间，自动化停在脚本里。

哪怕接了大模型，如果缺标准知识、流程连接和安全边界，AI最多帮你"回答问题"，进不了生产主流程。

嘉为蓝鲸DevOps平台运维团队过去一年也在把AI真正用进日常处置。我们没想一步到位做个"全能智能助手"，而是走了一条更稳的路：先把高频经验做成可复用的Skill，再让Skill连上诊断和协同流程，最后在治理边界内做有限自动处置。

01 先把经验变成“能直接执行的数字资产”

很多团队不缺文档，缺的是“遇到问题能直接照着做的知识”。同一类Pod异常，不同人用的命令、判断顺序、输出标准都不一样。新人知道文档在哪，却不知道下一步该干嘛。

我们的做法是：盘点高频、重复、路径相对稳定的场景，把散落在文档、群聊和专家脑子里的处理方式，固化成一份“标准作业单元”——我们叫它Skill。它不是一个提示词，也不是一段脚本包装，而是一份可被AI调用的契约：明确输入条件、执行步骤、判断依据、停止条件和输出格式。

举一个真实在用的例子——Pod异常诊断Skill。它的契约长这样：

• 触发条件：Pod异常、CrashLoop、OOM、服务宕机、副本不足、镜像拉取失败等。用户不用再判断“该找哪个脚本或哪个专家”。
• 必要输入：环境、Namespace、应用名或 Pod名、告警时间窗，先锁定对象，避免查错集群。
• 定位规则：有Pod名就直接诊断；只有应用名，先找工作负载、读真实Selector，再反查 Pod；只有Namespace就扫描异常Pod。不靠名字猜资源关系。
• 诊断分支：查状态、事件、重启原因和日志，识别OOMKilled、镜像拉取失败、资源不足、配置挂载失败等常见根因。
• 停止与转交：PVC问题转存储Skill，节点压力转节点Skill，网络问题转网络Skill；原因不明就停止自动动作、交人工。
• 标准输出：故障对象、时间范围、根因、关键日志/事件、影响范围、建议动作及证据来源——结果能直接复核、提单、审计。

比如收到“KubePodCrashLooping”告警，Skill先从告警字段取出Namespace和应用名，通过工作负载的真实Selector定位异常Pod，再读退出码、重启次数、Events和最近日志。Exit Code137 / OOMKilled就明确指向内存超限；ImagePullBackOff则继续区分是镜像Tag不存在还是拉取凭据异常。完整日志和Events都留在报告里，而不是只丢一句无法复核的“疑似资源问题”。

你现在就能用的一招：别急着上大模型，先把你们团队最高频的3类故障，照上面这张契约表写成Skill。查询和诊断可以直接执行；配置修改、重启、清理这类动作，先展示影响和回退方案、确认后再做。这正是Skill和普通知识库问答的区别：它不仅告诉你“可能是什么”，还规定“怎么确认、何时停、交付什么”。

目前嘉为蓝鲸DevOps团队已经将Kubernetes、网络与存储、日志与Trace、JVM、流水线、部署与资源、巡检与Web冒烟、受控清理及工作项协同等专项Skill统一纳入仓库管理，共享同一套环境定位、安全边界和报告规范。Skill也不是一次性交付物——环境、版本、经验一直在变，只有建立评审、验证和迭代机制，这份资产才持续有效。

02 让AI进流程，而不是停在问答窗口

知识能被查到，不等于流程被打通。一次异常从运维转给研发，最容易丢的就是：发生时间、已执行动作、判断依据。研发常收到一句“服务异常，请协助”，又得重新要日志和上下文，协作时间全耗在反复转述上。

我们把Skill嵌进告警诊断、巡检归类和异常协同链路，让AI按既定规则做信息采集、结果归纳和上下文组织。诊断中形成的关键证据、影响范围、处置记录和待办，随流程进到下一环。AI不替责任人决策，只是少让人搬信息。

还是一次真实告警——“某服务错误率持续升高”。传统流程只把告警标题转给研发；接入Skill后：

1. 确认对象：从告警提取环境、Namespace、应用名、时间窗；环境有歧义就列出候选，责任人确认后再继续。
2. 采集证据：查工作负载和Pod状态，关联时间窗内的日志、Events或Trace；集中日志不可用时降级读K8s原生日志，并标注证据来源。
3. 形成结论：区分基础设施、配置依赖、研发代码问题，输出根因、影响范围、关键证据和建议动作；不确定就写明“不确定项”，不强行下结论。
4. 带上下文流转：属于研发问题，工作项自动带上产品模块、环境、目标服务、原始告警、诊断结论、关键日志和严重程度建议。研发从看证据开始，不是从补背景开始。

这里有两个我们坚持的硬规则：

• 每一步都由上一步的真实结果驱动（只有应用名时先找工作负载读 Selector，不直接拼Pod标签）；
• 诊断报告必须先于通知和提单生成（工单结论有证据可追溯，不“先建单后补材料”）。

你可以先落一个场景：挑每月都重复、跨运维和研发协作的那类告警，统一工作项字段和诊断报告模板，然后盯三个指标——补充信息次数、首次有效响应时间、退单率。这三个数持续变好，才说明AI真进了流程，而不是多了个问答入口。

03 用治理边界做“有限自动处置”

AI能调工具之后，企业真正担心的不是“能不能执行”，而是“执行错了怎么办”。权限、风险、责任边界不清，能力越强风险越大。

我们没有追求“无人值守”，而是把治理前置，对场景做风险分层：

• 建议类：涉及核心数据、账号权限、批量配置、关键链路开关，只输出证据和人工处置方案。
• 确认类：影响范围明确但仍需人判断，展示变更内容、风险和回退方案，确认后再执行。
• 自动处置类：只开放低风险、标准化，且同时满足可审计、可追踪、可验证、可回退的动作。

每次处置都记录执行前状态、操作命令、验证结果和回退结果。

举个边界判断的例子：OOMKilled或退出码137的CrashLoopBackOff，系统不会看到告警就重启，而是先查目标环境、Pod状态、退出原因、重启次数和关联事件，确认是否在已定义的低风险范围内。只有故障对象唯一、根因与预设规则一致、影响范围明确、操作前状态已记录、且有可执行验证和回退步骤，才允许受控重建异常Pod，再观察新Pod是否 Ready、重启是否继续、端点是否恢复。

一旦出现高频重启、原因不明、涉及核心数据或有状态服务、回退路径无法确认、验证指标不可用——任一情况就停手，只输出证据和人工建议，进通知或工作项流程。目的不是抬高自动执行比例，而是让每次放权都有清晰依据。

直接拿走用的模板——“自动处置准入表”，每行一个场景，字段就这八个：场景、触发阈值、允许动作、影响范围、验证指标、超时时间、回退动作、责任人。先选无状态、低风险、恢复易验证的场景试运行，连续复盘误判率、处置成功率、回退率后，再决定扩不扩范围。

04 把分散的Skill变成企业资产：嘉为蓝鲸CPack Skill仓库

前三步解决了单个场景如何落地，但企业要把这些实践复制到更多团队和流程，靠“多写几个Skill”远远不够。Skill一旦分散在不同人员、项目和环境中，很快就会出现标准不一、重复建设、权限失控、版本过期和经验无法复用的问题。

Skill解决的是一个场景，Skill仓库解决的是一批场景如何规模化复制和持续运营。这正是嘉为蓝鲸 CPack Skill仓库的定位。

嘉为蓝鲸制品管理平台·CPack 是一款企业级制品管理中枢，满足多技术栈并存、高安全要求场景下的制品管理需求。平台提供Maven、NPM、Hugging Face、Skill等20+种制品仓库，覆盖主流开发语言、国产鸿蒙及AI资产管理等需求，具备制品管理、搜索、分发、分析等核心功能。平台贯通开发、构建、测试至部署全流程，支撑制品全生命周期高效运转，助力企业统一管控制品资产，保障软件供应链与交付安全。

它以嘉为蓝鲸DevOps研发效能平台为工程底座，将分散的运维经验、诊断规则和协同流程沉淀为可管理的Skill资产，再连接企业已有的环境、工具、数据和权限体系。它不是脱离现有流程的另一个AI工具，而是让智能能力能够被统一管理、稳定调用和持续维护的企业能力资产中心。

对企业来说，这座Skill仓库带来的不只是“多了一批 AI能力”，而是四项可以规模化复制的核心价值：

• 统一沉淀，让专家经验成为企业资产：把散落在个人、群聊、文档和脚本里的经验集中收录，避免关键人员变动后知识流失，让一次实践能够被整个组织持续复用；
• 统一调用，让成熟能力随取随用：按业务场景快速找到并调用合适的Skill，复用嘉为蓝鲸DevOps已有能力，缩短新场景建设周期，减少不同团队重复开发、重复集成；
• 统一治理，让AI真正敢进生产：将权限、确认、审计、验证和回退纳入统一管理，在释放 AI效率的同时守住生产安全边界，让每一次调用都有依据、每一次执行都可追溯；
• 统一运营，让知识资产持续增值：围绕使用效果持续评审、优化和迭代Skill，使能力跟随业务、环境和流程共同演进，让Skill仓库从项目成果成长为企业长期运营的智能资产中心。

嘉为蓝鲸DevOps Skill仓库不要求客户一次性改造现有体系。更容易理解、也更稳妥的做法，是先选一个典型问题跑通，再逐步复制：

1. 先选一个值得解决的问题：例如重复出现的Pod异常，或跨团队反复补充信息的告警。记录当前处理时长和协作次数，明确希望改善什么；
2. 只接入解决问题所需的系统：连接必要的DevOps工具、日志和协同流程，先从只读查询和诊断开始，不急于开放生产写操作；
3. 把企业规则写进Skill仓库：在标准Skill基础上补充客户自己的环境识别、判断规则、审批要求、责任分工和报告格式；
4. 小范围验证后再复制：先在有限环境或团队中试运行，对比定位时间、补充信息次数和执行成功率，验证有效后再推广到相似场景。

完成这四步，企业得到的就不再是一个演示用的AI场景，而是一项可以复用的企业能力：问题有明确入口，诊断有统一规则，执行有安全边界，结果有指标验证。后续新增场景时，可以沿用同一套仓库规范继续扩展。

最终形成的，是一座能够由企业持续使用和扩展的Skill仓库：CPack统一承载和管理Skill资产，嘉为蓝鲸DevOps连接研发工具与流程，企业规则形成业务差异，持续运营让经验不过期。

对管理者来说，仓库的价值不在于“有多少个Skill”，而在于能否减少重复建设、加快经验复制、控制生产风险，并把个人经验真正沉淀为企业资产。这些价值最终仍要回到业务指标，下面是我们在阶段性实践中观察到的变化。

05 写在最后：我们验证过的，和你现在能做的

跑了一段时间，覆盖Kubernetes、日志与Trace、JVM、流水线、部署巡检等多类场景后，我们看到的不是"AI替代了几个人"，而是几个核心指标的变化：

• 常见告警首次定位时间缩短约30%；
• 二线重新补充问题背景的时间，从十余分钟降到3—5分钟；
• 新人独立处理常见问题的上手周期，从约一周缩到2—3天。

这些数会因你们流程成熟度、场景复杂度和覆盖范围而异，但方向是稳的：常见告警从"先找人"变"先走统一诊断入口"；经验从个人记忆变成可维护的Skill 资产；异常上下文能随流程传递，不再二次采集；低风险标准动作按统一规则执行，过程可验证、结果可复盘。

如果你也在做DevOps+AI落地，我们的建议是先别追"全能助手"，把经验Skill化→流程协同化→有限自动处置这三步走实。真正可落地的AI，不是让模型无所不能，而是让正确的经验进入正确的流程，在清晰边界内稳定创造价值。

如果你正在寻找一套能把Skill统一沉淀、调用、治理和运营起来的工程化方案，欢迎与我们交流具体行业中的落地方式。