用LLM Wiki构建SRE知识库

May 27 2026

前段时间，部门leader交给我一个任务：公司SRE平台的工单系统已经累积了7019个人工工单，这些工单里沉淀了大量运维过程中的实际问题和解决经验，leader希望我能用这些数据建立一个SRE领域的专属知识库。

接到任务后，我初步盘算了一下，制定了一个看似顺理成章的计划：

把这7000多个工单全部格式化为Markdown文件，提取工单标题、内容、处理会话以及审批详情。
选型知识库的检索方案，在传统的 RAG（检索增强生成）和最近比较火的 LLM Wiki 之间做个抉择。

但随着项目的推进，我发现事情并没有那么简单。在这个过程中，我对“如何用大模型解决实际工程问题”又有了一些新的体悟，在这里复盘总结一下。

1. 现实的骨感：信息密度极低的“脏数据”

在写脚本把7019个工单全部格式化抓下来之后，我满怀期待地开始分析数据，结果被现实浇了一盆冷水。

我发现大部分的工单内容极其水：基本都是“我想开通XX权限”、“XX环境怎么连不上了”，然后处理结果直接就是“已处理”、“已结束”。中间的沟通会话也往往是简单的确认信息（比如“是这个IP吗？”“是的”）。

这意味着工单本身的信息密度是非常低的。如果采用 RAG 方案，核心逻辑是文本切块（Chunking）和向量检索。面对这种毫无上下文、纯碎片的工单信息，切块后丢进向量数据库，检索出来的绝对是一堆毫无逻辑关联的废话，基本没有可行性。

考虑到 RAG 方案在召回、重排上需要花费极大的精力去调优，而我的工程直觉告诉我：尽量不要搞得那么复杂，怎么简单怎么来，快速跑通才是王道。

所以我决定放弃 RAG，走 LLM Wiki 的方案。

2. 初试 LLM Wiki 与人工“蒸馏”

LLM Wiki 本质上是一种方法论（通过大模型全局阅读并生成结构化的索引和概念页面，查询时先查索引再读原文），具体怎么实现各有各的说法。为了快速验证，我找了 NousResearch 官方的 Hermes Agent SKILL，稍微修改适配了 Cursor 就跑了起来。

第一次 Ingest（数据摄入）跑完后，大模型基于工单生成了 25 个 Entities（实体）和 Concepts（概念）页面。查询的时候确实能起到一些作用，但问题依然回到了数据源本身——工单信息太碎了，Agent 检索回答的依然是碎片信息的拼凑，效果并不理想。

思考了一下，我决定回到问题的本质：大模型再强，也无法从没有逻辑的对话中凭空创造严谨的知识。

于是我做了一个苦力活（也是最关键的一步）：把工单中有用的事实信息分类整理，蒸馏出真正的核心内容。我按照上一步生成的 25 个概念分类，重新梳理了一份 1400 行的 SRE 领域知识文档。在用 Agent 辅助蒸馏的过程中，我反复强调了一个 Prompt 核心：绝对不要添油加醋，必须是工单中确认的客观事实。

这份 1400 行的文档，把原本碎片的工单价值分门别类地聚拢了起来。说实话，单单是这份纯文本发出来，就已经非常有价值了，甚至不需要 Agent 来检索。

3. 扩大战果：整合全域资产

有了这份高质量的“蒸馏”数据后，我开始思考更高维度的解法。

其实部门内部原本是有一些 SRE 相关的系统性文档的，只是非常零散，散落在各个地方，且互相之间有很多复杂的文档引用。既然要做知识库，不如一次性做透。

我利用 WPS 的云文档 MCP 工具（mcp_kso-yundoc），写脚本爬取了所有这些现存的 SRE 领域知识库文档，规范化地保存到 raw/articles 目录下。

加上之前蒸馏出来的 25 份核心工单事实，我的知识库语料扩充到了 646 份高质量文档。

4. 建立真正的 SRE Wiki Index

语料准备就绪后，我基于这些高质量文档，重新跑了一遍 LLM Wiki 的 Ingest 流程。

这一次，奇迹出现了。系统完美地生成了 22 个 Entities 页面、56 个 Concepts 页面，以及 1 个 Comparisons 页面。一整个 SRE 领域的全景索引（Index）被清晰地建立了起来。

看看最终生成的 index.md，非常有成就感：

# Wiki Index

> 金山办公 SRE 平台工单知识库内容目录。
> 每个 wiki 页面按类型归类，附一行摘要。查询前先读此文件定位相关页面。
> Last updated: 2026-05-26 | Total pages: 86

## Entities

| Page | Summary |
|------|---------|
| [[kae-application-engine]] | KAE 金山应用引擎 — 一站式应用生命周期管理平台（创建/发布/性能分析/日志/配置/OpenAPI/WPS365 API对接/开放平台应用管理） |
| [[kcicd-ci-cd-platform]] | KCICD CI/CD 流水线平台 — 镜像构建/自动部署/多分支编排/Webhook/Git Submodule/国际化镜像加速/构建缓存 |
| [[klb-load-balancer]] | KLB 金山负载均衡 — 上游配置/路由插件/健康检测/证书自动化/七层路由/监控指标/灰度放量 |
| [[khub-image-registry]] | KHUB 镜像仓库平台 — 镜像存储/清理/海外分发/hub-mirror/清理策略/权限管理 |
| [[milvus-vector-database]] | Milvus 向量数据库 — 存储计算分离架构/索引选型/性能基准/部署运维/监控/可用性矩阵 |
| [[business-gateway]] | 业务网关平台 — istio+Envoy 网关/路由/限流/WASM/Lua/鉴权/监控/多实例 |
| [[istio-service-mesh]] | istio 服务网格 — istiod 配置/Sidecar iptables/Proxyless gRPC/东西流量/性能优化 |
| [[domain-management]] | 域名管理 — 购买/备案/解析/国际化域名/域名适配库/Region-Srv/企业自定义域名 |
| [[ssl-certificate]] | SSL 证书管理 — DV/OV/EV 证书/购买/部署/KLB 自动化/巡检 |
| [[inner-ingress-gateway]] | 内网网关 — 集群内服务就近访问/inter-ingress-gateway/跨机房切量 |
| [[region-srv]] | Region-Srv 域名下发服务 — entry 域名配置/v2/v3 接口/全球多区域 |
| [[cdn-service]] | CDN 内容分发网络 — CDN 域名规范/国际化 CDN/wpscdn 域名体系/多厂商覆盖/回源配置 |
| [[iam-identity-management]] | IAM 身份与访问管理系统 — 组织/企业/用户/部门模型，KSO Token 认证体系，云厂 AK/SK 全生命周期管理，权限命名规范，订阅通知，安全系数机制，OAuth2 SSO/KIAM |
| [[kac-access-control]] | KAC 访问控制平台 — 堡垒机/权限审批/操作审计/云厂账号及AK全生命周期管理/KAC配置中心 |
| [[srecli-cli-tool]] | srecli SRE 命令行工具 — AI 驱动的排障搭子，统一对接 KAE/KLB/KDB/KITSM/KCG 能力 |
| [[bastion-host]] | 堡垒机 KSOP — 基于 JumpServer 的商业版堡垒机，域名已迁移至 ksop.kso.net |
| [[kafka-message-queue]] | Kafka 消息队列 — 消息中心/Topic管理/磁盘扩容/消费堆积/跨集群通信 |
| [[kdb-database-platform]] | KDB 金山数据库平台 — 监控架构/备份降本与事故复盘/Binlog 中心规划/MySQL HA/多引擎管理 |
| [[ks3-object-storage]] | KS3 金山对象存储 — Bucket管理/CORS/生命周期/AK-SK/回收站 |
| [[kslm-license-management]] | KSLM 许可证管理 — 软件许可证购买/分配/监控/回收 |
| [[ceph-storage]] | Ceph 存储集群 — YXY Ceph 分布式存储管理 |
| [[sre-team]] | SRE 团队 — 组织架构/职责分工/工单流程/KITSM权限 |

## Concepts

| Page | Summary |
|------|---------|
| [[cloud-native-application-standards]] | 云原生应用规范 — 优雅启停/微服务治理/可观测性/Docker 镜像规范/KLB 使用规范/共享集群/K8S 调度原理/HPA/调度优化/安全规范 |
| [[cloud-vm-image-standardization]] | 云主机基础镜像标准化 — Linux/Windows 系统配置/安全加固/磁盘自动挂载/内核参数优化 |
| [[container-graceful-shutdown]] | K8S 应用优雅启停 — SIGTERM 处理/preStop Hook/Pod 生命周期/1号进程问题/优雅下线流程/滚动升级策略 |
| [[container-image-management]] | 容器镜像管理 — Docker 镜像规范/KHUB/Harbor/hub-mirror/清理策略/海外分发 |
| [[cloud-platform-release-standards]] | 云平台发版流程和标准 — 产研测三方流程/发版节奏/准入准出标准/线上监控指标 |
| [[cloud-service-change-process]] | 云服务变更流程规范 — 核心/企业核心/非核心云服务变更评审要求/warroom 应急处置 |
| [[kso-token-authentication]] | KSO Token 认证与透传 — JWKManager/Claims 提取/透传/刷新/持久化/业务网关集成/鉴权网关规则变量 |
| [[klb-upstream-configuration]] | KLB 上游配置 — 上游组/负载均衡算法/健康检测/流量比例/超时重试 |
| [[sre-client-certificate-login]] | 使用客户端证书登录 SRE — p12 证书加密/HOST 配置/多平台导入方式 |
| [[kdesign-theme]] | Kdesign Theme 主题使用 — 多主题模式/动态皮肤切换/theme-mode |
| [[kdesign-icons-library]] | Kdesign Icons 图标库 — React/Vue/Vue3 SVG 图标/多色填充/Figma IconGen 插件 |
| [[service-governance]] | 微服务治理 — 服务发现/gRPC LB/k8sresolver/东西流量/全链路灰度/蓝绿发版/RPC规范/熔断降级/开发环境治理/流量泳道 |
| [[capacity-management]] | 容量管理 — K8S 集群调度/连接数治理/HTTP 连接池配置/异常连接案例/TIME_WAIT 治理 |
| [[database-capacity-management]] | 数据库容量管理 — MySQL/Redis/TiDB 等容量规划/扩容缩容/数据归档与成本优化 |
| [[mysql-operation-practices]] | MySQL 运维实践 — 开发规范/GTID HA/主从延迟/CHAR-VARCHAR/2020-2023 故障模式/BlockHole 运维 |
| [[redis-operation-practices]] | Redis/Tendis 运维实践 — 使用规范/性能排查/主从复制/宿主机初始化/2020-2023 故障模式 |
| [[tidb-operation-practices]] | TiDB 开发与运维规范 — 开发规范/TiUP 部署/慢查诊断/OOM 预案/系统表与常用命令 |
| [[clickhouse-operation-practices]] | ClickHouse 运维实践 — 表引擎选择/字段设计/SQL 规范/分布式集群方案/高可用架构 |
| [[mongodb-operation-practices]] | MongoDB 运维实践 — 设计规范/索引/API/连接规范/2021-2023 故障模式 |
| [[elasticsearch-operation-practices]] | Elasticsearch 运维实践 — 概念/集群模式/KDB 平台操作/Mapping/自研插件/Go SDK/常见问题 |
| [[network-security-practices]] | 网络安全实践 — DNS/域名安全/SSL证书/本地HTTPS/IP白名单/来源IP与白名单区别/CSRF防护 |
| [[network-infrastructure]] | 网络基础设施 — VPC安全分级/DCI专线/子网带宽/MTU/网卡队列/NCE纳管/内部网站 |
| [[idc-operations-practices]] | IDC 机房运维实践 — 上架流程/现场操作/设备报废/存储介质/OpenStack扩容/NUMA/BIOS |
| [[idc-and-hardware-management]] | IDC 与硬件管理 — 服务器上架/设备报废/存储介质销毁/机房操作规范/NUMA |
| [[observability-platform]] | 可观测性平台 — Prometheus/VM/Grafana/日志平台/Jaeger/50X告警/采样率治理 |
| [[observability-and-monitoring]] | 可观测性与监控 — Metrics/Logging/Tracing 三大支柱/Prometheus/VM/日志平台/Jaeger |
| [[ingress-gateway-comparison]] | 入口网关对比 — Kong vs istio Gateway vs KLB/分层架构/选型建议 |
| [[cascading-failure-patterns]] | 级联故障模式 — KLB/业务网关/连接追踪表溢出/多域名互相影响/客户端重试风暴 |
| [[fault-recovery-and-postmortem]] | 故障复盘方法论 — 故障分级/应急响应/复盘模板/根因分析与改进跟踪 |
| [[tcp-connection-problems]] | TCP 连接问题 — 半连接队列满/TIME_WAIT堆积/连接追踪表满/连接数暴涨/OOM |
| [[config-driven-incidents]] | 配置变更驱动的故障 — 权益变更/DNS配置/健康检查配置/灰度回退 |
| [[client-retry-storm]] | 客户端重试风暴 — 权益变更触发传输重试/推送通道断开触发重连/重试放大机制 |
| [[internationalization-deployment]] | 国际化部署 — 海外机房/网络隔离/监控数据源/域名规范/全链路灰度/账号数据迁移及服务升级 |
| [[i18n-and-multilanguage]] | 国际化与多语言研发 — i18n 工具链/资源文件管理/前后端多语言规范与差异化配置 |
| [[local-development-environment]] | SRE 内网本地开发环境 — 珠海园区 k8s_local_dev 集群，支持本地断点调试和服务网格流量泳道 |
| [[wps-web-plugin-system]] | WPS Web 插件 2.0 体系 — 第二代 JSAPI + Web 插件框架，CEF 改造/FakeHTTPS/WPSvConsole/插件平台 |
| [[wps-365-api-system]] | WPS 365 API 体系 — 云体系统一 API，涵盖 IAM/Drive/会议/日历/邮箱/稻壳等核心领域 |
| [[topic-change-process]] | Topic 变更流程 — 发布方/订阅方标准化 Topic 迁移流程，双写渐进式切换 |
| [[ref-ai-gateway]] | AI 网关运行备忘 — 大模型统一接入/EP管理/灰度放量/模型配额 |
| [[ref-bastion-host]] | 堡垒机运行备忘 — KSOP域名迁移/连接排障/安全组配置/权限管理 |
| [[ref-cdn-configuration]] | CDN 配置运行备忘 — 多厂商覆盖/回源配置/CORS/缓存刷新/排障指南 |
| [[ref-data-migration]] | 数据迁移运行备忘 — DTS工具矩阵/跨区域同步/checksum校验/不支持的场景 |
| [[ref-database-capacity-management]] | 数据库容量管理运行备忘 — 监控指标/扩容阈值/连接池配置/慢查询 |
| [[ref-international-deployment]] | 国际化部署运行备忘 — 海外集群/网络隔离/监控数据源/上线流程 |
| [[ref-ip-whitelist-management]] | IP 白名单管理运行备忘 — 三层架构/KAE出口IP/安全组/桶策略/申请流程 |
| [[ref-k8s]] | K8S 集群管理运行备忘 — 资源配额/调度/命名空间/ETCD/PVC |
| [[ref-kac]] | KAC 配置中心运行备忘 — 下线迁移/域名兼容性/K8S Secret注入 |
| [[ref-kae]] | KAE 应用引擎运行备忘 — 工作负载/健康检查/准入策略/NodePort限制 |
| [[ref-kae-container-troubleshooting]] | KAE 容器排障运行备忘 — ExitCode对照/Pod故障模式/优雅启停 |
| [[ref-kafka-operations]] | Kafka 运维运行备忘 — ConsumerLag/磁盘扩容/Topic管理/客户端兼容性 |
| [[ref-klb-operations]] | KLB 运行备忘 — 路由插件/监控指标/证书管理/上游配置/日志分析/ACL/流量染色 |
| [[ref-kdb]] | KDB 数据库平台运行备忘 — 多引擎支持/安全策略/DDL工单/ClickHouse排障 |
| [[ref-ks3]] | KS3 对象存储运行备忘 — CORS配置/生命周期/回收站/Cloudplex自助 |
| [[ref-kslm]] | KSLM 监控告警运行备忘 — Prometheus保留期/告警平台迁移/knight |
| [[ref-network-security]] | 网络安全运行备忘 — WAF拓扑/DDoS防护/网络隔离/漏洞管理 |
| [[ref-permission-management]] | 权限管理运行备忘 — RBAC模型/策略配置/权限失效/审批缓存 |
| [[ref-sre-team]] | SRE 团队运行备忘 — KITSM 权限/工单审批链/项目加入流程/值班惯例 |

## Comparisons

| Page | Summary |
|------|---------|
| [[ingress-gateway-comparison]] | 入口网关对比：Kong vs istio Gateway vs KLB — 功能/场景/运维/选型建议 |

## Queries
<!-- 值得保留的查询结果 -->

5. 交付与总结

最后，我基于 LLM Wiki 的机制，单独抽取了一个 wiki-query 的只读查询 SKILL，交付给了负责 Agent 的团队。

现在，一个专用的 SRE 领域知识库查询 Agent 正式上线了。当用户提问时，Agent 的工作流非常清晰：

先看 Index 目录，定位到可能相关的几个概念/实体页面。
直接读取这几个文档的原始内容（因为长文本大模型的上下文窗口现在足够大）。
综合多份原文进行总结回答，并在回答中附带上精准的文档引用链接。

为什么最终没有用 RAG？

在这次实践中，我深刻体会到，当一个业务领域的概念繁杂、专业名词多且上下文强依赖时，RAG 的召回率往往是个灾难。你要花大量的时间去搞定 Chunking 策略、微调 Embedding 模型、优化多路召回和重排机制，ROI 非常低。

而 LLM Wiki 的思路，其实就是利用了当前大模型超长上下文的能力——大力出奇迹。通过前期建立良好的索引目录，查询时直接把整篇甚至多篇高度相关的文档塞给大模型，让它自己去阅读理解。这种做法不仅实现起来简单直接，而且几乎杜绝了碎片化导致的幻觉，给出的答案质量极高。