Tech & AI

探针库和告警规则是同一类东西：一堆随时间累积的判定。告警规则已经演示过这类东西的结局，所以问「怎么做成熟」等价于问「怎么不重演那个结局」。以及一个结构性优势：探针有调用记录，所以第一次可以做基于使用的垃圾回收。

RCA 的交付物不该是一个点，而是一条因果链加每条边的反事实检验，再加一份未解释残余清单。链画出来之后，「哪个才是真正的根因」这个争论就消失了，剩下的是切断点的成本比较。

人看监控靠视觉模式识别，所以需要选时间窗；agent 不需要，因为比较逻辑可以直接写进表达式。告警规则早就是给机器看的监控，只是被设计成只输出一位信息。照这个思路写了第一个探针，实测 667 条生产告警规则里 94 条已经静默失效。

一次 4 TB 宽表点查调查：暖缓存、零远程读，仍要 1.12 秒，CPU 内存带宽全部正常。分析型数据库的一等指标是每条查询的扇出，不是主机资源水位。

IaC、K8s、AI Agent 是同一个控制论范式的三次落地：声明期望状态、观测实际状态、diff、收敛。前两代的收敛是数学保证，第三代退化成概率——工程要做的不是消灭这个退化，是用五个杠杆把它兜住。

把工作项目的状态维护、边界控制和输出格式做成一套 2000 行的 hook + skill：必须发生的事挂事件触发，需要判断的事延迟到压缩阶段。以及 CLAUDE.md 为什么会越写越像一份带勘误的日志。

从 context-infrastructure 这个 repo 本身的三层记忆架构和路由表说起，到一套生产 oncall skill 的四条硬约束，再到从 gstack 批判性抄来的取舍，最后是一次对自己系统的六层诚实体检。这篇讲怎么用，不讲为什么。

九个分数如何从证据密度推导、每个分数意味着什么，以及一份独立交叉验证雷达形状的行为记录。

一个平时 0 副本的重查询计算池背后的五个设计决策：用物理隔离而不是负载分级、用离散容量而不是逐查询伸缩、按瓶颈类型而不是按数据量定容、把 controller 收敛成对一个字段的 patch，以及一条假设「每个健康信号最终都会骗人」而设计的 readiness 路径。spot 只是分池决策的结果，不是重点。

审计了一个每天产出约 960 条 OpsGenie 告警、约 85% 是默认 P3、背后有 367 条 paging 规则的 pager：定位四个结构性根因，重建准入、去重和 ownership，让腐化从默认结局变成需要对抗系统的例外。