• RCA 根因分析推断-08-COT Chain of Thought（思维链）
  序言 结合 ai 打造 rca 系统，先让 ai 回答一下。 chat 详细介绍一下 COT “COT” 有多个含义，具体要看上下文。但结合你目前的关注点（AI + 根因分析 + 智能推理 + 运维场景），COT 更可能是指： 🧠 COT = Chain of Thought（思维链） 这是在使用 大语言模型（LLM） 时的一种提示工程和推理策略，它通过**引导模型“逐步推理...
  2025-04-19 06:31:52 | Note
• RCA 根因分析推断-08-NOC Network Operations Center（网络运营中心）
  序言 结合 ai 打造 rca 系统，先让 ai 回答一下。 chat NOC 是什么？ NOC 是 Network Operations Center（网络运营中心）的缩写。 ✅ 简单定义： NOC 是一个集中监控、管理和维护 IT 基础设施和服务可用性的指挥中心，主要职责是确保网络、服务器、应用、服务等持续稳定运行。 📡 NOC 的典型职责： ...
  2025-04-19 06:31:52 | Note
• RCA 根因分析推断-06-alarm 基本的分析流程
  思路 场景 我们需要分析报警，但是资源信息等很多，所以需要分级+剪枝过滤 基本的步骤 1）从 alarm==>app 从报警关联到所有的 app 2) 从 alarm 找到所有的关联报警的资源 app phy / vm / redis / mysql / pod / … 包括网络： vm / phy ====> nginx 3) app 的进一步关联资源 ...
  2025-04-19 06:31:52 | Note
• RCA 根因分析推断-05-alarm sync neo4j 报警数据同步到图数据库
  思路 场景 我们接收到报警之后，需要把报警信息落库。 其实有两种思路。 一种是流，一种是批模式。 优缺点 批 批模式可以做一些批量的优化操作。 比如 A2 的 disk 之类的无用异常过滤。 批模式如果改为 10 秒一次呢？ 有什么问题？ 批模式还可以支持数据的重跑，但是流没有这个能力。 可以两种模式都保留。 流 流模式可以在数据全部落库之后，最后做一下数据的落库...
  2025-04-19 06:31:52 | Note
• RCA 根因分析推断-04-应用到物理机的基本资源？
  思路 应用 从报警的应用触发，经过 3 层左右，关联到所有报警的物理机器资源？ 通用性 可以考虑将开头的 appList 放在入参，和目标存在问题的资源 ipList 放在那里？ 精致的细分 可以把各种资源还是区分开？ 统一调整一下【查看子图】的具体实现逻辑？ 去重 去重的时候，不要把 app 之类的给去没有了？？ 参考资料 思路 应用 ...
  2025-04-19 06:31:52 | Note
• RCA 根因分析推断-03-变更事件的内因+依赖资源的异常
  变更事件 说明 要考虑哪些异常的内因呢？ 同时考虑一些依赖资源的异常。 现状 特别精确的时间范围控制，会导致无法准确的命中。 内因 磁盘 一般 A2 以及以下可以忽略 mem 内存 A2 以及以下可以忽略? disk ? cpu ? 可以看一下 A2 以及以下的是不是没什么用？ GC 服务不可用 依赖资源 公共资源 app vm phy redis m...
  2025-04-19 06:31:52 | Note
• RCA 根因分析推断-02-变更事件笔记 appChangeRecord
  变更事件 说明 如果一个变更，可能会导致对应的异常。 标准化 首先要对报警的数据进行标准的格式化处理。 比如应用名，执行时间等等 变更的内容 ip + appName 时间范围 如果页面选择了一个时间范围 比如：18:00~18:30 那么，对应的变更事件应该怎么办呢？ 1）create_time 事件的创建时间刚好介于 18:00~18:30 16:00 and...
  2025-04-19 06:31:52 | Note
• RCA 根因分析推断笔记
  根因分析 相关内容以前记录的比较多。 逐渐级别推断 资源 应用视角==》单个报警 alarm 报警 报警的主视角 metric 指标 普米: （cpu/mem/disk/net） SQL: SQL 报警 CAT log===>异常日志 知识库 日志 top3 去重的异常日志？ Trace cmdb rpc 事件 变更（标准化） 监听深入 变化值...
  2025-04-19 06:31:52 | Note