<?xml version="1.0" encoding="utf-8" ?><rss version="2.0"><channel><title><![CDATA[Stars_of_Stars的博客]]></title><description><![CDATA[]]></description><link>https://blog.youkuaiyun.com/Stars_of_Stars</link><language>zh-cn</language><generator>https://blog.youkuaiyun.com/</generator><copyright><![CDATA[Copyright &copy; Stars_of_Stars]]></copyright><item><title><![CDATA[【OpsPilot-08】从告警解析到处置触发：我的数据流设计之路]]></title><link>https://blog.youkuaiyun.com/Stars_of_Stars/article/details/162218326</link><guid>https://blog.youkuaiyun.com/Stars_of_Stars/article/details/162218326</guid><author>Stars_of_Stars</author><pubDate>Tue, 23 Jun 2026 03:50:18 +0800</pubDate><description><![CDATA[我的贡献不是某个高性能算法，而是让这条路线上的数据流稳定、清晰、可对接。这条链路的每个环节都定义了清晰的输入输出格式。前四篇博客已经记录了每个环节的设计思路和实现细节，这篇作为收官，把它们串成一条完整的链路。如果一开始就把精力放在向量数据库调优上，可能连基本的端到端联调都完不成。是预设的，但实际故障的严重程度可能远低于或高于预设场景。的完整数据流，确保每个环节的数据格式稳定、接口清晰、可被下游消费。这样无论上游怎么命名，下游看到的都是统一格式。，但没有它，多源观测的输出和知识库的输入永远对不齐。]]></description><category></category></item><item><title><![CDATA[【OpsPilot-07】基础模块的接口契约测试与前后端联调验证]]></title><link>https://blog.youkuaiyun.com/Stars_of_Stars/article/details/162213896</link><guid>https://blog.youkuaiyun.com/Stars_of_Stars/article/details/162213896</guid><author>Stars_of_Stars</author><pubDate>Tue, 23 Jun 2026 03:25:45 +0800</pubDate><description><![CDATA[项目进入收尾阶段，核心模块陆续完工。我的角色从模块开发转向测试验证——但我的测试重点不是完整的故障剧本（那需要Agent编排层和真实LLM配合），而是验证我负责的基础模块（告警接收、知识库检索、根因分析接口）的接口契约稳定性和前后端数据一致性。]]></description><category></category></item><item><title><![CDATA[【OpsPilot-06】从个人模块到团队基础设施：后端接口Schema的设计与演进]]></title><link>https://blog.youkuaiyun.com/Stars_of_Stars/article/details/162213712</link><guid>https://blog.youkuaiyun.com/Stars_of_Stars/article/details/162213712</guid><author>Stars_of_Stars</author><pubDate>Mon, 22 Jun 2026 23:58:18 +0800</pubDate><description><![CDATA[前几篇博客记录了我独立开发根因分析模块的过程。进入5月后，团队进入密集联调阶段，我发现自己早期写的代码没有被"替换"，而是被——我定义的接口Schema和数据结构，成了前后端对接的基准。这篇记录这个转变，以及我在其中的具体工作。]]></description><category></category></item><item><title><![CDATA[【OpsPilot-05】知识库规模化：从20条条目到检索质量调优的工程实践]]></title><link>https://blog.youkuaiyun.com/Stars_of_Stars/article/details/161984996</link><guid>https://blog.youkuaiyun.com/Stars_of_Stars/article/details/161984996</guid><author>Stars_of_Stars</author><pubDate>Sun, 14 Jun 2026 22:34:17 +0800</pubDate><description><![CDATA[前几篇博客记录了知识库原型和检索策略的选型。核心工作是把知识库从3条原型条目扩展到20条生产级条目，并解决规模化后的检索质量问题。这篇记录这个过程中的技术决策和踩坑。]]></description><category></category></item><item><title><![CDATA[从根因分析到闭环处置：与多源观测、自动化执行模块的联调对接]]></title><link>https://blog.youkuaiyun.com/Stars_of_Stars/article/details/160867872</link><guid>https://blog.youkuaiyun.com/Stars_of_Stars/article/details/160867872</guid><author>Stars_of_Stars</author><pubDate>Thu, 07 May 2026 21:52:51 +0800</pubDate><description><![CDATA[（博客2已接入）（任务4的输出，这周对接）队友目前的多源观测模块实现了三个并行查询工具：PromQL查询指标曲线Elasticsearch日志检索服务状态检查节点输出一个字典，我需要从中提取关键字段注入根因分析的上下文。解决方案：在接口层加了一个，把输出转成我的知识库Schema能理解的格式。比如时间序列数组提取max_value和（上升/下降/平稳），日志摘要统一成的句式。]]></description><category></category></item><item><title><![CDATA[RAG知识库原型搭建：从JSON Schema到向量检索的初步实践]]></title><link>https://blog.youkuaiyun.com/Stars_of_Stars/article/details/160599608</link><guid>https://blog.youkuaiyun.com/Stars_of_Stars/article/details/160599608</guid><author>Stars_of_Stars</author><pubDate>Wed, 29 Apr 2026 20:35:57 +0800</pubDate><description><![CDATA[上一篇梳理了的接入机制，这周开始动手实现我负责的核心模块——RAG知识库和根因分析。说实话，从看懂文档到写出能跑的代码中间隔着不少坑，这篇笔记记录一下知识库原型的搭建过程和遇到的具体问题。一、为什么选RAG而不是微调这个决策在博客1里提过，但直到真正开始实现才意识到它的现实意义。我们团队没有几千条标注好的故障处理记录来微调模型，而且运维知识更新太快——今天的新中间件明天可能就过时了。更重要的是，根因分析必须可解释：你不能告诉老板模型觉得可能是数据库问题，你需要说明。]]></description><category></category></item><item><title><![CDATA[Alertmanager webhook机制与Agent接入思考]]></title><link>https://blog.youkuaiyun.com/Stars_of_Stars/article/details/160598594</link><guid>https://blog.youkuaiyun.com/Stars_of_Stars/article/details/160598594</guid><author>Stars_of_Stars</author><pubDate>Tue, 28 Apr 2026 17:55:07 +0800</pubDate><description><![CDATA[如果不分析，万一静默规则配错了，真实故障会被漏掉。的告警产生和推送，下游是知识库检索和自动化执行。如果上游的数据格式和推送逻辑没搞清楚，后面做根因分析就成了无源之水。上一篇梳理了项目总体的技术路线和模块划分，这周开始具体啃各个组件的接入细节。如果异步处理，又需要维护一个告警队列和状态机。，模型大概率会给出三个独立的根因，而不是识别出它们共享同一个根因。的告警模型做理解，直接拿原始数据喂给大模型，效果会很差。告警规则，对同一个概念的标签命名可能不一样：有的用。被抑制的告警不进入根因分析的主流程，但会作为。]]></description><category></category></item><item><title><![CDATA[OpsPilot智能运维Agent设计：从告警风暴到根因分析的技术路径思考]]></title><link>https://blog.youkuaiyun.com/Stars_of_Stars/article/details/160507961</link><guid>https://blog.youkuaiyun.com/Stars_of_Stars/article/details/160507961</guid><author>Stars_of_Stars</author><pubDate>Sat, 25 Apr 2026 23:23:35 +0800</pubDate><description><![CDATA[最近几周一直在啃项目的技术方案，今天把思路整理一下，也算是对自己负责模块的一个阶段性梳理。我们项目叫OpsPilot，定位是面向中小型企业业务系统的智能运维Agent。说实话，一开始我对这个题目的理解比较浅，觉得就是"用大模型读告警、给建议"而已。但深入调研之后发现，真正的难点不在于"让LLM说话"，而在于。]]></description><category></category></item></channel></rss>