技術 Day11：機器可讀的意圖，讓 registry 說得出「為什麼」

這個欄位有哪些值，registry 答得出來哪一種值代表「這個服務是好的」目前只寫在 dashboard 標題跟幾個人的腦子裡 昨天把 registry 開...

技術 Day10：來把 registry 交到 AIOps agent 手上

前面做的治理讀者一直只有兩種，人跟 CI今天加第三種 這個階段前面做的每一件事，都是為了讓 registry 裡的東西可信：命名有規則、PR 有 gate、...

技術 Day9：breaking change，diff 看得到的跟它看不到的

改名字會被看見改名字底下的內容物不會而後者才是會把下游打死的那一種 昨天把 registry 疊成兩層，也留了一個問題：平台團隊改了 base 裡的一個定義...

技術 Day8：分層與所有權，哪一層統一哪一層放手

治理的難處從來不是「要不要統一」是「哪一層統一，哪一層放手」前者是立場，後者才是設計 昨天 live-check 對著 service.name 說「這個屬...

技術 Day7：治理成為大門，CI gate 與 live-check 守在兩個時間點

規則存在跟規則會被執行中間差的東西比想像中多 昨天那三條 Rego 規則跑出 9 個違規、離開碼 1，把 userId 跟 user_id 並存這件事抓了出...

技術 【Day6】命名漂移：用 Rego policy 把它攔下來

review 的人看得到這個 PR 改了什麼看不到系統目前已經有什麼而命名漂移剛好只住在後面那一半 昨天用 weaver registry infer 從真...

技術 Day5：Weaver 上手，schema 是團隊共識

觀察只能告訴你欄位叫什麼至於它代表什麼、值可以有哪些、必不必填那三件事線路上一個字都沒有 前兩天在處理「資料能不能穩定產生、能不能送達」。今天換一個問題：資...

技術 Day4：有注入了不代表遙測有被送達

注入成功了服務也全綠使用者也沒抱怨然後你的 trace 沒了 昨天裝完 OpenTelemetry（以下簡稱 OTel）Operator，刻意留了一個空白：...

技術 Day3：OTel Operator，把「持續維護」從人身上搬到迴圈裡

一次性的 apply 是下指令宣告式的 CR 是一個不會停下來的承諾差別要等到某個東西被改壞的那天才看得出來 昨天講到，語意是一份共同的約定。一個團隊自己怎...

技術 Day2：AIOps 要的不是更多資料，是可推斷的資料

資料一直都夠多少的是「這個欄位到底代表什麼」這件事有被寫下來過 昨天那隻 agent 拿了 4.5/9。先淺聊一下它到底是哪裡不夠？ 這個問題重要，是因為它...

技術 Day1：失敗現場，一個查得動 Prometheus 的 agent，卻拿不到 60 分

一個查得動 Prometheus 的 agent跟一個查得對的 agent中間隔的不是模型大小是它有沒有辦法知道自己問錯了 今日程式碼在範例 repo OT...

技術 Day 30: 如何使用 AWS bedrock multi-agent 協助維運人員對 AWS 服務做 operation (下)

昨天完成設定之後，除了驗證各個 agent 是否正常運作之外，還可以透過 Multi-agent collaboration trace timeline 確認...

技術 資料領域需要什麼都來點 Ops：DevOps, DataOps, MLOps, AIOps

各種 Ops 是傳統組織架構崩解的號角 傳統功能性部門的分工方式容易造成資訊孤島，卻又為了企業營運活動而必須合作。純專案組織不用跨部門合作了，不必分享資訊也不必...