★ FEATURED ARTICLE 前一阵子和一个朋友复盘他们团队的线上事故处理过程发现一个特别有意思的现象他们的监控、告警、CI/CD、日志系统全都上了工具链不可谓不完整但每次出大事最后能真正定位问题的人还是那几个老法师。新来的同学哪怕手里有全套的权限和文档也只能在旁边递扳手。这个现象其实就是典型的DevOps进程里被长期忽略的人类瓶颈。大家老觉得DevOps的瓶颈在工具、在流程、在自动化覆盖率实际跑过几年之后你会发现真正卡住整条流水线的往往是知识——它长在特定的人身上没法复制没法扩展也没法在凌晨两点的告警风暴里随叫随到。这篇文章我想聊聊如何把AIOps和SECI模型结合起来把DevOps团队里那些靠人肉传承的知识逐步变成一条自动化的知识管理流水线。我会把SECI的四步知识转化落到AIOps的具体技术实现上再附上我们在实践过程中踩过的坑。适合那些已经在维护一定规模的DevOps平台且开始觉得人不够用、知识不够用的团队。1. 先说结论DevOps最贵的部分从来不是工具很多人对DevOps的理解是一套流水线代码提交后自动构建、自动测试、自动部署、自动监控然后告警触发人上去处理。这套东西本身已经非常成熟了Jenkins、GitLab CI、ArgoCD、Prometheus、Grafana配套生态相当完善。但如果你把视角拉到整个事故响应链路会发现有一个环节始终无法自动化从告警到根因再到修复方案的那段思考过程。这段思考过程长在哪里长在技能型员工的经验里。一个服务出问题了有经验的人知道这个问题大概率是上游流量抖动引起的看这几个指标就能确认新人只会盯着报错日志一行一行看半个小时后还在第一行。这里的差距不是工具给的是长期的模式识别训练出来的。SECI模型在知识管理学里讲得很清楚知识分成显性知识和隐性知识。显性知识是文档、代码注释、操作手册能写出来、能存下来。隐性知识是那种只可意会不可言传的东西——比如你怎么通过一个网络延迟曲线的拐点判断是磁盘IO的问题而不是网络链路的问题。DevOps场景里的头疼之处在于隐性知识的占比远高于显性知识。而且团队里最核心的隐性知识往往只存在于一两个人脑子里。他们一旦休假、离职、或者那天刚好不在线上值班整个团队的故障恢复效率会直线下滑。这就是人类瓶颈的本质——组织的知识密度没有跟上系统复杂度的发展速度。所以我的结论是DevOps建设的前半场拼工具链后半场拼知识管理。而知识管理这件事恰好是AIOps最擅长的领域。它不替代人做决策但它可以把人的经验沉淀成系统的、可被检索、可被复用的知识资产。1.1 知识管理不是建个Wiki这里必须先泼一盆冷水。大多数团队提到知识管理第一反应是建Wiki、写文档、整理Confluence页面。这个做法不能说是错的但它的效果通常都不好。原因很简单文档是静态的系统是动态的。你写下这个服务依赖MySQL和Redis的时候可能确实是这样。三个月后中间加了一层缓存文档没更新新人按照文档排查方向完全跑偏。写文档没有即时激励。工程师的天性是解决问题不是记录问题是怎么解决的。能在故障处理完之后补文档的人本身已经是稀有物种。显性化之后的隐性知识会失真。经验丰富的人写文档时很多关键判断是无意识的他觉得这个显然不用写恰恰那个地方就是新人的认知盲区。所以做DevOps领域的知识管理核心不在管理而在**自动化地沉淀**。知识不应该由人主动去写而应该由系统在运行过程中自动抽取、自动结构化、自动关联。这才是AIOps真正能发力的点。1.2 知识瓶颈的三个表现形态我观察了很多DevOps团队知识瓶颈通常以三种形态出现知识孤立A同事解决过一个问题记录散落在自己的本地笔记、聊天记录、甚至脑子里。B同事遇到同样的问题不知道有人解决过从头再踩一遍坑。知识过时业务变更了、架构调整了但知识库还停留在老版本。比没有知识更可怕的是错误的知识。知识不可执行文档写了一大堆但新的值班人员面对告警时仍然不知道该先看哪个指标、按什么顺序排查。这三种形态其实就是SECI模型里没有闭环的具体表现隐性知识没有外化、外化的显性知识没有组合成系统、组合后的知识没有内化到新人的行动里。下面我会把SECI的每一步拆出来对应到AIOps的具体落地方式上。2. SECI模型给我的启发知识的本质是一个循环过程SECI模型是野中郁次郎提出的组织知识创造理论。它把知识的转化过程分成四步社会化、外化、组合、内化。国内做知识图谱和语义层的朋友对这套语言应该不陌生它解释的其实是知识的生命周期社会化从隐性知识到隐性知识。徒弟跟着师傅干活师傅带徒弟靠观察、模仿、实践来传递经验。外化从隐性知识到显性知识。把经验通过语言、文字、图表表达出来变成可以被他人理解的内容。组合从显性知识到显性知识。把零散的文档、数据、知识片段梳理成体系形成知识库、标准流程、方法论。内化从显性知识到隐性知识。通过实践把书面知识变成个人的操作本能。我之所以觉得这个模型特别适合DevOps场景是因为DevOps团队的知识流转本质上就是一个庞大的SECI过程工程师处理线下故障获得经验这属于社会化有同事在复盘会议上把这个过程讲出来变成复盘文档属于外化文档积累得多了整理成排查手册、标准预案属于组合新的同事按照手册去演练、去值班慢慢变得熟练属于内化。但在传统模式下这四个步骤都是靠人肉完成的每一个环节都有损耗。外化的环节靠工程师自觉补文档组合的环节靠技术主管人肉整理内化的环节靠新人自己悟性。AIOps就能在这四个环节分别提供显著的自动化能力。2.1 外化让机器替人写文档SOCIALIZATION和EXTERNALIZATION在AI时代可以彻底打穿。过去认为抽取隐性知识这个过程只有人能做到但是大语言模型出现之后情况已经变了。一个运维工程师在排查过程中心里的那套推理链——看到这个告警想到那个服务检查这几个指标确认那个根因——它其实是有迹可循的日志、指标、变更记录、操作审计都是痕迹。AIOps可以把这些痕迹串联起来自动生成一份结构化的排查记录包括告警上下文、关键指标变化、操作动作、结论和后续建议。这就把让工程师写复盘变成了让工程师确认AI生成的复盘。外化的成本一下降了一个数量级。我在实践过程中发现工程师对确认的意愿远高于从零开始写这就是落地可行性的关键。2.2 组合知识图谱比文件夹更接近活的知识库外化完成之后会产生大量的结构化知识片段。如果按传统方式管理就是丢进某个目录挂几个标签本质上还是一个死库。SECI模型里的组合步骤要求的是知识之间建立连接。在这个层面知识图谱或者说语义层比传统的标签体系更适合做承载一次代码变更可以关联到它影响了哪些服务的哪些指标一个告警可以关联到历史上同类告警的根因是什么当时是谁用什么方式解决的一份故障报告可以关联到这已经是本月第三次同类问题的变体。这些关联关系用传统文件夹结构根本表达不出来。而知识图谱天然就是为这种多跳关联设计的。有了图谱之后知识的组合就从人工梳理变成了自动推理。2.3 内化把知识喂给值班的人内化阶段的自动化是我目前认为AIOps最实用也最见效果的部分。通过语义检索和RAG我们可以把图谱里沉淀的知识在正确的时间推送给需要的人。具体来说事件发生时值班人员不需要翻文档库只需要输入一条告警信息系统会自动召回历史上相似度最高的事件、对应的根因分析和处置步骤直接把一套排查行动建议给到值班人员。这本质上就是在加速内化过程——新人不需要经过漫长的经验积累就可以获得接近老师傅的判断路径。我打个比方以前培养一个能独立值班的运维工程师大概需要跟着处理几十个真实故障踩无数个坑才能形成直觉。现在通过这种内化加速新人可以在处理第三个同类事故时就表现得像一个处理过三十次事故的人。这就是知识自动化真正的杠杆所在。3. AIOps落地的核心用语义层把事故现场变成知识资产接下来聊具体的技术实现方式。AI开发流程与普通后端开发有个显著不同点普通后端处理的是结构化输入输出AIOps处理的是混沌的、多源异构的运行时数据。所以要落地上面那一套思路必须解决数据的统一表征问题这一步就是语义层。业界在知识图谱、本体、语义层这几个概念上争议不少这里不引战。我只说在实际项目里的选择我们最终采用的是轻量级本体 知识图谱存储 语义检索接口三段式架构。不用太重的本体建模标准但保留结构化关联的核心能力。3.1 事故现场的结构化从非结构数据中抽取事件要素故障发生的那一刻现场是什么样的告警平台发出了一条文本告警日志系统滚动着海量报错监控面板上的曲线在跳变也许还伴随着一次版本发布的变更记录。这些数据形式完全不同但它们描述的是同一个现实系统正在经历一次不正常的状态变化。AIOps要做的第一件事就是把这场混乱结构化。我们参考事件溯源的模式设计了统一的事件模型incident model包含时间窗口事件开始、持续时长涉及实体受影响的服务、主机、中间件实例告警序列触发顺序、告警级别、告警内容摘要上下文事件并行释放出的变更信息操作记录操作者的动作、命令、验证方式最终结论根因、影响范围、修复手段、预防措施在这个环节大语言模型扮演的是结构化抽取器的角色。关键设计是不要让它自由发挥结构而是提供一个JSON Schema让它把非结构化内容填充进预定义字段。实测下来这种方法比让模型自由输出文本的准确率要高得多下游知识图谱的入库成本也低很多。3.2 知识图谱Schema设计的轻量化实践第一版做知识图谱时我们掉进了一个大坑试图建模一切。把服务调用链、基础设施拓扑、人员组织架构、代码仓库关系全部灌进去最后图谱不仅难维护查询性能也撑不住。后来总结出一条可行原则图谱只存与事件根因和处置经验直接相关的实体关系其他信息交给原有系统。我们的核心本体设计如下服务name、owner、依赖列表告警type、level、message、metric_name、threshold事故title、root_cause、impact、timeline、resolution、prevention变更type、environment、related_code、approver处理人name、role、action_taken关系类型控制在四种以内service_owned、triggered_alert、caused_incident、related_to_change、resolved_by。这个精简设计让图谱的构建和查询都变得非常轻量却足以回答值班过程中最高频的问题这个服务以前出过什么事当时怎么解决的和这次变更有没有关系3.3 语义检索RAG让知识可以被问出来知识有了怎么触达用户我们在图谱之上架了一层语义检索服务底层就是向量数据库加图查询的组合。具体做两件事对每次inccident的结构化记录做向量化存到向量库对图谱的关系路径保留图查询能力。查询时用户用自然语言描述当前我看到的现象系统先在向量库里召回最相似的历史事故再用图查询把关联的变更、告警、处理人信息一并拉出来组成一个完整的上下文交给LLM做应答生成。这个应答的格式不是一个答案而是一套行动建议——先看什么、再查什么、尝试什么。3.4 工具选型的实际对比我们对比了市面上几种主流方案这里给一个参考视角组件我们的选择落选方案原因向量检索MilvusWeaviate团队对Milvus更熟且性能调优文档更全图数据库Neo4jNebulaGraph团队规模小Neo4j生态和应用工具更顺手NebulaGraph性能更强但运维成本高LLM推理私有化部署小型模型API调用涉及内部系统数据出域合规过不了私有化是唯一解工作流编排Apache Airflow自研调度时间线驱动型任务Airflow天然合适自研维护成本高不值得这轮选型没有标准答案。我的经验是优先选团队成员已有的经验栈别迷信技术先进。知识管理系统拼的不是算法是运营的持续性。你维护不动的东西再先进也会变成摆设。4. 落地三轮迭代从记录事故到预防事故的三个阶段理论框架讲了这么多真正能可靠的落地还是得一步步来。我建议分三个阶段推进每个阶段有明确的交付物避免摊大饼。4.1 第一阶段做记录自动化把外化成本降下来第一个阶段只做一件事让每次事故处理完自动产出一份结构化的事故档案。别急着做智能推荐也别急着做图谱推理。先把最基础的外化成本降下来。实现上在告警平台的webhook里加一个订阅事件被标记为已解决时自动触发一个知识抽取流程。流程包括def extract_incident_knowledge(event): payload { incident_id: event[id], alert_sequence: event[alerts], change_events: load_changes_in_time_window(event[start], event[end]), operator_actions: event[action_logs], resolution_status: event[status] } structured llm_structured_extract( prompt_templateINCIDENT_EXTRACTION_TEMPLATE, payloadpayload, schemaINCIDENT_JSON_SCHEMA ) save_to_graph(structured) save_to_vector_store(structured) notify_owner(f事故档案已生成: {event[id]})这一步之后团队的核心收益是每个事故都留下了机器可读的、可检索的结构化痕迹。工程师不需要写故障复盘系统替他起草他只需要审核确认。这里还涉及一个非常容易被忽视的运营细节让人审核确认而不是完全自动化。很多团队做知识管理失败是因为完全没有人审最后沉淀了大量质量不可控的内容。我们的经验是AI生成完之后在即时通讯工具IM里推送一条确认消息处理人点一下确认键才算入库否则只进临时区。这个小门槛换取内容可信度非常值得。4.2 第二阶段做检索增强让知识主动出现记录积累了一段时间之后我建议至少积累200个以上真实事故或事件样本可以开始做第二层闭环把历史和当前事故做关联。具体做法是在事故发生时同时触发知识召回任务。当前事件S及S涉及的关键字段被向量化在历史库中执行相似度搜索搜索范围限定在同服务、同类告警或邻近时间窗口。查出来的候选内容大多是结构和向量库里的片段和当前事件信息组装成prompt发送给值班人员检测到你可能正在处理事件#E-1042以下是历史上处理过的一起高度相似事件。那次事件的根因结论是资源耗尽导致的OOM循环当时的处置动作清单会考虑自动扩容、重启主从、检查慢查询。您可以参考这些建议但需要结合当前实际情况验证。这里系统的定位非常关键它不宣称这就是根因只用历史上发生过类似情况你可以先往这个方向排查的口吻把决策权留在人手里。这个定位不仅适合组织文化也是系统在事实上能做到的精度——相似并不等于相同只在做过相似处理后给出相关上下文才是安全的AI能力边界。4.3 第三阶段做变化预警让知识反哺预防第三阶段是锦上添花的那一层——把知识库和变更管理打通。知识图谱里已经存放了历史事故与变更的关联关系。当有新的应用发布、配置变更、流量切换动作发生时系统会自动扫描图谱看这个动作是否命中了历史上的高危模式。这个实现非常简单就是一个图查询加规则匹配问题难的不是算法而是规则的提炼能力。比如我们沉淀过一条规则在过去三个月里某服务在变更后8小时内出现同类告警的概率显著高于其他时段。那下一次该服务再提交变更系统会自动向变更审批人推送一条提示附上历史事件的时间分布和建议预留的回滚窗口。AIOps走到这一步就没有停留在事故处理更快的层面而是真正进入事故更少发生的层面了。知识不再只是应急的时候拿来用而是在风险尚未发生的时刻提前给人提个醒。5. 踩过的那些坑和它们背后的经验最后复盘几个我们在推进这整套体系时踩过的坑希望你能绕开。5.1 知识抽取质量差的病根schema设计缺陷第一次做结构化抽取时我们定义的字段太宽泛让大模型自由总结根本原因结果模型生成的描述五花八门甚至同一类问题在几次事故里被总结成完全不同的两套说法。后来我们把字段拆成更小的约束项比如故障代码、指标异常特征、依赖服务的健康状态拆开填充描述类字段全部改成选择题和列表选项。一个典型经验是任何自由文本都会在聚合分析时变成垃圾堆。想让数据有利于后续聚合统计就要在抽取阶段尽量用枚举值、关键词列表和确定性的结构化格式而不是放一个让模型自由发挥的空白框。5.2 知识的时效性维护只进不出的库是第二个垃圾堆知识图谱一生走的是只增不删的路最后就会充满过时信息。旧架构下的服务已经下线了图谱里还躺着关于它的几十条高风险规则每次关联都命中这些已经不存在的东西影响也不好。我们的解法是在实体和事件上都加了生命周期状态字段定期由一个定期扫描任务完成对比当前CMDB的资产清单将已下线或废弃的服务对应节点标记为inactive。这次的检索默认排除inactive节点这样既能保留历史事件可供追溯又不会影响当前值守场景的判断。5.3 不要急着训练专属模型不少团队看了这个思路之后第一反应是我们是不是应该微调一个专属运维大模型。我给的建议是别急。在积累到足够数量级的数据比如数万条高质量事故样本之前微调模型的收益非常有限整体性价比很低。先用通用模型的zero-shot能力配上一个精心设计的schema做抽取配合RAG或者单纯Faiss库检索就能拿到不错的效果。我们做了两个多迭代之后知识质量已经足够支撑值守场景。若真到那一步再去考虑小参数模型或者领域适配时机才合适。5.4 组织阻力比技术阻力大这部分属于比较容易被忽略的。在推进时会遇到几个典型的抵触反应工程师担心AI记录我的操作是不是在监控我的工作状态新人觉得直接给答案我还有什么成长针对第一类我们在团队里很明确地表了态系统只记录解决过的故障知识不做行为合规审计二者在权限上彻底隔离。针对第二类我们把解释口径统一为这是给你的知识文案助手是减轻你工作负担的让系统输出的表达调整为不仅给结论也给完整的推理路径和背景让新人能通过它理解老同事的判断逻辑保持持续学习。5.5 用字段对比验证知识库是否真的有效知识管理项目很难量化这是很多团队推动不动的原因。我们采取的思路是把知识系统启动前后的值班工单做字段级对比对比维度包括平均告警确认时长、事件升级率、第一次处置方向正确率、MTTR、事件复盘报告生成时长。前三个和知识系统直接相关后两个能间接体现知识沉淀的效率。做对比时我们惊讶地发现MTTR下降幅度最大原因并不是定位更快了而是沟通成本降低了——系统整理好的上下文让几个人在协同排查的时候不用反复对齐当前进展到哪了联动效率直接上一个台阶。这个发现让我意识到知识管理系统的效率杠杆很多时候出现在非常意外的位置上。6. 从知识管理到团队演进我的几点实践体会整个尝试跑下来之后我最大的体会是AIOps在知识管理上的定位应该理解为团队学习能力的放大器应该是组织级的机制设计。如果只把它看成又一工具它会被用来做无数次分析之后仍然不管用如果把它看成一个知识流转系统需要跟流程机制一起去建设效果会很不一样。关于推进顺序比较值得推荐的路径是先让机制跑起来再上技术。即先在团队里确认每次事故都要留下沉淀的规矩然后引入AI把成本降到最低。如果一开始就上复杂系统却没有人用大概率也是空转。这半年我自己的一个直观感受是晚上睡到三点被电话叫起来不再会慌张了。因为心里有底——知识库里有上百条过往处理过的相似异常的处置记录在等着而且它们会主动跑出来帮我把方向标好。这种底气的建立比看到几条指标曲线漂亮得多。
阅读完成 · 觉得有帮助？
