鐵人檔案
我有一隻查得動 Prometheus 的 AIOps agent。丟進真實系統跑 RCA benchmark，九項只拿兩分——猜錯 label、寫錯 TraceQL，最後編出一個不存在的 trace ID。
這 30 天從這份成績單倒著往回挖：agent 架構錯在哪、上下文錯在哪（用 OpenTelemetry Weaver 把 schema 變成機器可讀的約束）、再把散落的訊號收斂成 Signal Plane 讓資料可推斷；接著用評估證明修好了，最後才敢上線（授權邊界、執行護欄、人在迴圈核准）。
終點是告警燒起來、agent 能協助調查、將結論回到 Grafana。
一個查得動 Prometheus 的 agent跟一個查得對的 agent中間隔的不是模型大小是它有沒有辦法知道自己問錯了 今日程式碼在範例 repo OT...
資料一直都夠多少的是「這個欄位到底代表什麼」這件事有被寫下來過 昨天那隻 agent 拿了 4.5/9。先淺聊一下它到底是哪裡不夠？ 這個問題重要，是因為它...
一次性的 apply 是下指令宣告式的 CR 是一個不會停下來的承諾差別要等到某個東西被改壞的那天才看得出來 昨天講到，語意是一份共同的約定。一個團隊自己怎...
注入成功了服務也全綠使用者也沒抱怨然後你的 trace 沒了 昨天裝完 OpenTelemetry（以下簡稱 OTel）Operator，刻意留了一個空白：...
觀察只能告訴你欄位叫什麼至於它代表什麼、值可以有哪些、必不必填那三件事線路上一個字都沒有 前兩天在處理「資料能不能穩定產生、能不能送達」。今天換一個問題：資...
review 的人看得到這個 PR 改了什麼看不到系統目前已經有什麼而命名漂移剛好只住在後面那一半 昨天用 weaver registry infer 從真...
規則存在跟規則會被執行中間差的東西比想像中多 昨天那三條 Rego 規則跑出 9 個違規、離開碼 1，把 userId 跟 user_id 並存這件事抓了出...
治理的難處從來不是「要不要統一」是「哪一層統一，哪一層放手」前者是立場，後者才是設計 昨天 live-check 對著 service.name 說「這個屬...
改名字會被看見改名字底下的內容物不會而後者才是會把下游打死的那一種 昨天把 registry 疊成兩層，也留了一個問題：平台團隊改了 base 裡的一個定義...
前面做的治理讀者一直只有兩種，人跟 CI今天加第三種 這個階段前面做的每一件事，都是為了讓 registry 裡的東西可信：命名有規則、PR 有 gate、...