Tech & AI · 中文

整数尾延迟是人为常量：一个周期性尖刺，追到藏在限流插件里的缓存超时。

「熟悉 Jenkins」写在无数 JD 里，但会写 pipeline 脚本不是那个能力。真正的能力是把交付流水线当生产系统对待：流程幂等、job 状态可观测、配置进代码，并且知道自动化本身什么时候会变成新的熵源。落地素材来自一次真实的 Jenkins 迁移，和其中 diagnose 与 fix 脚本的配对。

雷达为什么是九个轴：一个按问题类别而不是工具清单构建的能力模型，以及护城河到底在哪里。

一条 Kafka 消费积压告警，真因是 ClickHouse 里超过 1 TiB 的升级残留，被一次一秒内完成的后台 merge 引爆

好的 infra engineer 带来的不是「会敲命令」，而是在约束下做取舍的判断力。reconcile、IaC、冗余、降级、限流——现代大规模云管理的每一条方法论，本质都是在回答同一个问题：为了保住整体，你愿意主动放弃什么。

junior SRE 把 system metrics 和 app metrics 横着切，把 CPU 标出来就算监控。真正的转折是从上往下做——不同的主体关心不同的指标，每个主体的 SLO 不同，dashboard 也不同，而 dashboard 存在的意义是回答问题。

不背 K8s 概念,而是从'两个不可回避的事实'推导整个 K8s。子系统、resource kind、Operator 模式,全是必然推论而不是设计选择。

Locality 不是 trade-off,是约束。换 attention 也解决不了。整个计算机系统就是一座由 locality 砌成的金字塔,AI agent 是塔顶新加的一层石头。

K8s 的根选择是承认'错误是常态',用声明式 + reconcile 把这一点内置进系统;AI Agent 工程正在重走同一条路。看懂 K8s,就看懂了 AI Agent 未来 5 年的路线图。

状态：大纲 核心论点 SRE 和 agent engineering 面对的是同构问题：从不可靠组件构建可靠系统。K8s 的 reconciliation loop 让不可靠的容器收敛到声明式状态，agent 系统用类似机制让不可靠的 LLM 决策收敛到预期目标。区别只在不确定性的来源：系统行为 vs 决策过程。 大纲 1. 开篇：同一个问题的两个实例 K8s controller 是确定性的，不需要 guardrail；LLM agent 是概率性的，Policy 层不是可选的 传统 SRE 问的是「is it alive?」，agent…