О проекте
About the Project
Гибрид: детерминированный Knowledge Graph + LLM-пайплайн за policy-gate. Обогащение алертов, RCA и controlled remediation в Kubernetes. Спроектирован честным к своим слепым зонам — система помечает, чего она не знает, вместо того чтобы выдавать догадки за факты.
A hybrid: deterministic Knowledge Graph + an LLM pipeline behind a policy gate. Alert enrichment, RCA and controlled remediation for Kubernetes. Built to be honest about its blind spots — it marks what it doesn't know instead of passing guesses off as facts.
Безопасность прежде всего
Safety-first remediation
Главный страх «AI сам трогает прод» снят архитектурно: можно ли запускать kubectl-write считается детерминированно (8 risk-axes → policy-engine), а не берётся из ответа модели. Dry-run по умолчанию, approvals, anti-replay, savepoint-изоляция.
The core fear — “the AI touches prod on its own” — is removed by design: whether a kubectl write may run is computed deterministically (8 risk axes → policy engine), not taken from the model’s answer. Dry-run by default, approvals, anti-replay, savepoint isolation.
Самокорректирующийся Knowledge Graph
Self-correcting Knowledge Graph
Граф зависимостей кластера из нескольких источников (топология, деплои, события, метрики, логи) с anomaly-detection и integrity-watchdog'ом, который ловит дрейф качества данных сам. Масштабируется на тысячи сервисов.
A multi-source dependency graph of the cluster (topology, deploys, events, metrics, logs) with anomaly detection and an integrity watchdog that catches data-quality drift on its own. Scales to thousands of services.
Честность по умолчанию
Honest by design
Сигналы помечены по достоверности (is_proxy), известные слепые зоны задокументированы в самом ответе. Система не выдаёт «зелёное», когда у неё просто нет данных — редкий, но решающий для доверия признак.
Signals are tagged by confidence (is_proxy); known blind spots are documented in the response itself. It won’t report “green” when it simply has no data — a rare but decisive trait for trust.
Как это работает
Конвейер инцидента — 6 ступеней. Честно: что уже live, а что включается с LLM-флагом.
1 · IngestliveAlertManager webhook → HMAC + anti-replay + dedup.
2 · Enrich (KG)liveГраф добавляет контекст: деплои, blast radius, pod-события, логи, ingress 5xx/p95.
3 · Reason (LLM)за флагомГипотез-агенты строят версии из контекста; critic ранжирует и режет слабые.
4 · Respondlive +LLMОдин Discord-эмбед: факты + подсказка root-cause; с LLM — связный narrative.
5 · Remediateopt-inПредложить/применить kubectl-фикс за детерминированным policy-gate + approval.
6 · Self-watchlive7 self-health-чеков /30мин, включая integrity-watchdog графа.
How it works
The incident pipeline — 6 stages. Honest about what's live today vs what the LLM flag turns on.
1 · IngestliveAlertManager webhook → HMAC + anti-replay + dedup.
2 · Enrich (KG)liveThe graph adds context: deploys, blast radius, pod events, logs, ingress 5xx/p95.
3 · Reason (LLM)flaggedHypothesis agents draft versions from the context; a critic ranks and prunes weak ones.
4 · Respondlive +LLMOne Discord embed: facts + a root-cause hint; with LLM, a coherent narrative.
5 · Remediateopt-inPropose/apply a kubectl fix behind a deterministic policy gate + approval.
6 · Self-watchlive7 self-health checks /30 min, including a graph integrity watchdog.
Как выглядит выводWhat the output looks like
Синтетический пример critical-эмбеда в Discord (данные вымышленные).A synthetic example of a critical Discord embed (fictional data).
🔴 Critical · checkout-service · prod
🎯 Likely cause
deploy #482 4 min before — p95 +180%, 5xx 0.6 rps at api.example.com/checkout
🌐 Endpoint health (ingress-derived)
5xx 0.6 rps · p95 920 ms
💥 Blast radius
3 svc → orders-service, cart-service, payments-gateway · 1 URL
🩺 Pod events
CrashLoopBackOff ×7 (OOMKilled)
🔧 Suggested action
kubectl rollout undo deploy/checkout-service [⚙️ Apply — dry-run ✓, risk: medium]
Почему это безопасно для прода
Главный страх «AI сам трогает прод» снят архитектурно — решение принимает не модель:
- Детерминированный policy-gate: можно ли запускать
kubectl-write считается из структурного intent'а по 8 risk-axes, а не берётся из ответа LLM (его risk — лишь advisory).
- Dry-run по умолчанию + approval: реальный apply только после
--dry-run=server и явного подтверждения кнопкой (risk ≤ medium).
- TOCTOU-подпись intent + anti-replay + savepoint-изоляция + полный OTEL-аудит каждого действия.
- Default = advisory: из коробки copilot не зовёт
kubectl вообще — анализирует и пишет в Discord.
Why it's safe next to prod
The core fear — "the AI touches prod on its own" — is removed by design; the model doesn't make the call:
- Deterministic policy gate: whether a
kubectl write may run is computed from the structured intent across 8 risk axes — not taken from the LLM (its risk field is advisory only).
- Dry-run by default + approval: a real apply happens only after
--dry-run=server and an explicit button confirmation (risk ≤ medium).
- TOCTOU intent signature + anti-replay + savepoint isolation + full OTEL audit of every action.
- Default = advisory: out of the box the copilot never calls
kubectl — it analyzes and posts to Discord.
Сырой алертер против копайлотаRaw alerter vs. the copilot
| Raw alerter | SRE AI Copilot |
|---|
| Контекст | только сработавшее правило | + деплои, зависимости, логи, ingress RED |
| Первопричина | копаешь сам | ранжированная гипотеза с evidence |
| Blast radius | неизвестен | кого зацепит — посчитано |
| Действие | вручную | предложенный фикс за policy-gate |
| Доверие | — | детерминированный гейт, approval, dry-run |
| Raw alerter | SRE AI Copilot |
|---|
| Context | just the firing rule | + deploys, dependencies, logs, ingress RED |
| Root cause | you dig | ranked hypothesis with evidence |
| Blast radius | unknown | who's affected — computed |
| Action | manual | suggested fix behind a policy gate |
| Trust | — | deterministic gate, approval, dry-run |
1600+ tests
multi-source KG
8-axis policy gate
MCP tools (SRE + client-dev)
honest blind-spot tagging