🟡 Intermediate

AIOps — AI v observability a incident response

AIOps (Artificial Intelligence for IT Operations) je disciplína, ktorá aplikuje strojové učenie, analýzu dát a v poslednom čase aj veľké jazykové modely (LLM) na automatizáciu a zlepšenie IT operácií. Cieľom nie je nahradiť inžiniera, ale eliminovať opakujúcu sa manuálnu prácu a znížiť čas od vzniku problému po jeho vyriešenie.

Krátka história — od Gartneru po LLM vlnu

Gartner zaviedol pojem AIOps v roku 2016 (pôvodne "Algorithmic IT Operations"), keď začal mať zmysel kombinovať strojové učenie s rastúcim objemom telemetrických dát z moderných distribuovaných systémov.

Vlna 1 (2016 – 2022) — klasické ML klasifikátory

Prvé AIOps nástroje fungovali ako chytrejšia vrstva nad existujúcim alertingom. Prijímali streamy alertov, aplikovali klastrovacie algoritmy a pravidlové enginy a redukovali alert fatigue. Nástroje ako Moogsoft, BigPanda alebo Dynatrace Davis (prezentovaný 2017) ukázali, že korelácia alertov naprieč službami je riešiteľná strojovým učením. Slabinou bol vysoký false-positive rate a nutnosť dlhého trénovania modelu na historických dátach.

Vlna 2 (2022 – 2024) — integrovaná observability + ML

Veľkí observability vendori (Datadog, New Relic, Grafana Cloud) integrovali anomaly detection priamo do svojich platforiem. Prestalo byť nutné kúpiť samostatný AIOps nástroj — stačilo zapnúť príslušnú funkciu na už existujúcej telemetrii. Vzniklo konceptové rozlíšenie medzi "full-stack AIOps" (Dynatrace, Datadog) a "event correlation overlay" (BigPanda, Moogsoft).

Vlna 3 (2024 – 2026) — LLM-driven kopiloty a agenti

Príchod LLM do produkcie zmenil AIOps kvalitatívne: namiesto klasifikácie alertov do skupín dokážu modely generovať prirodzeno-jazykové vysvetlenie incidentu, navrhnúť kroky remediácie a automaticky zapísať postmortem. Datadog Bits AI SRE (december 2025), PagerDuty Agentic AI, New Relic AI a Grafana Assistant reprezentujú túto vlnu — systémy, ktoré reagujú autonómne pred tým, než on-call inžinier vôbec otvorí laptop.

Piliere AIOps

Anomaly detection

Detekcia odchýlok od normálneho správania metriky bez nutnosti ručne nastavovať prahy. Modely sa naučia vzory (dennú sezónnosť, týždenný rytmus, load po deployi) a alarmujú pri štatisticky významnej odchýlke.

Alert correlation a deduplication

Stovky alertov z rôznych zdrojov (Prometheus, Nagios, cloud events) sa musia zredukovať na malý počet akčne schopných incidentov. ML klasifikátory grupujú alerty podľa časovej blízkosti, postihnutej služby a topologickej závislosti.

Root Cause Analysis (RCA)

Automatická identifikácia príčiny incidentu naprieč metrikami, logmi, tracmi a profilmi. Najnáročnejší problém v AIOps — vyžaduje kauzálne uvažovanie, nielen koreláciu.

Forecasting a capacity planning

Časové rady metrík (CPU, memory, disk, RPS) sa extrapolujú do budúcnosti. Výsledok sa používa na preemptívne škálovanie alebo kupovanie rezervovaných kapacít.

Automated remediation

Na základe známeho vzoru (napr. CrashLoopBackOff → restart podu, disk > 90 % → prune docker images) systém spustí remediačný skript bez ľudského zásahu.

Incident summarization a postmortem

LLM prečíta slack kanál incidentu, časovú os alertov, runbook kroky a vygeneruje ľudsky čitateľný postmortem draft v štýle "Čo sa stalo, kedy, prečo, čo sme spravili, čo robíme nasledne."

Dátové zdroje pre AIOps

AIOps pipeline je len tak dobrá ako vstupné dáta. Štandardný stos:

Zdroj	Nástroj	Čo ponúka
Metriky	Prometheus, VictoriaMetrics	Časové rady CPU, memory, latencia, RPS
Logy	Loki, ELK, OpenSearch	Textové udalosti, chybové hlášky
Traces	Tempo, Jaeger	Distribuované sledovanie volaní medzi službami
Profily	Pyroscope, Parca	CPU a memory profily na úrovni funkcie
Eventy	K8s events, Alertmanager	Štruktúrované udalosti z infraštruktúry
Change events	Deploy timeline, ArgoCD	Kedy sa zmenil kód alebo konfigurácia

Change events sú zvlášť dôležité pre RCA — významná časť incidentov je priamo spojená s deploymi. Korelácia "alert vznikol 4 minúty po deployi v 14:23" je často až 80 % práce analytika.

Klasické ML techniky

Time-series anomaly detection

STL decomposition (Seasonal and Trend decomposition using Loess) rozkladá metriku na trend, sezónny komponent a rezíduum. Anomália = rezíduum presahujúce konfidečný interval.

Prophet (Facebook/Meta) je bayesovský model vhodný pre metriky s viacnásobnou sezónnosťou (denná + týždenná). Automaticky zvláda sviatky a outliers.

Isolation Forest je ensemble metóda, ktorá anomálie izoluje náhodným delením priestoru — vhodná pre vysoko-dimenzionálne metriky kde tradičné metódy zlyhávajú.

# PromQL: dynamický prah cez predict_linear + stddev
# Alert ak skutočná hodnota odchýľa od predikcie o viac ako 3 sigma

(
  rate(http_requests_total{job="api"}[5m])
  -
  predict_linear(rate(http_requests_total{job="api"}[1h], 3600))
)
/
stddev_over_time(rate(http_requests_total{job="api"}[7d:5m])
) > 3

Tento dotaz porovnáva aktuálne RPS s lineárne extrapolovanou hodnotou za hodinu a normalizuje odchýlku smerodatnou odchýlkou za 7 dní — jednoduchý, ale efektívny "sigma anomaly detector" bez externého ML systému.

Alert clustering — DBSCAN

DBSCAN (Density-Based Spatial Clustering of Applications with Noise) grupuje alerty na základe hustoty v priestore {čas, service_hash, alert_type_hash}. Alerty mimo zhlukov sú označené ako noise a potlačené.

from sklearn.cluster import DBSCAN
import numpy as np

def cluster_alerts(alerts: list[dict]) -> dict[int, list]:
    """
    Zoskupi alerty podla casovacej blízkosti a sluzby.
    Vracia {cluster_id: [alerty]}, cluster_id=-1 je noise.
    """
    features = np.array([
        [
            a["timestamp"],
            hash(a["service"]) % 10_000,
            hash(a["alert_name"]) % 1_000,
        ]
        for a in alerts
    ])
    # eps=120 sekund, min_samples=2 alerty tvoria zhLuk
    labels = DBSCAN(eps=120, min_samples=2).fit_predict(features)

    groups: dict[int, list] = {}
    for alert, label in zip(alerts, labels):
        groups.setdefault(int(label), []).append(alert)
    return groups

Kauzálna inferencia a graph-based RCA

Judea Pearl-ove Directed Acyclic Graphs (DAG) modelujú kauzálne závislosti medzi službami. Pri anomálii v službe D algoritmus prechádza grafom smerom k príčinám a hľadá, ktorý predchodca najlepšie vysvetľuje anomáliu (napr. cez PC algoritmus alebo Granger causality).

Graph-based RCA (napr. implementácia v Dynatrace Smartscape) buduje topologický graf služieb z traces a koreluje propagáciu anomálie smerom od listov ku koreňom.

Vlna 2026 — LLM-driven AIOps

Incident kopiloty

Vedúce observability platformy integrovali LLM priamo do incident workflow:

Datadog Bits AI SRE (december 2025) — pri spustení alertu autonómne analyzuje runbooky, telemetriu a topológiu, validuje hypotézy a doručí výsledky do Slacku/PagerDuty skôr, než on-call inžinier otvorí notifikáciu. Natívna integrácia s Datadog mobile app a ServiceNow/Jira.

New Relic AI (Applied Intelligence) — párovanie zrelastého AIOps enginu (anomaly detection, alert korelácia) s prirodzeno-jazykovým rozhraním. Inžinieri sa pýtajú "aký bol 99. percentil latencie pre checkout včera vs. dnes" priamo v NR UI bez nutnosti písať NRQL.

Grafana Assistant — kontext-vedomý kopilot zabudovaný do Grafana Cloud. Pomáha písať PromQL/LogQL dotazy, kreovať dashboardy a triažovať incidenty cez chat rozhraním.

PagerDuty Agentic AI — tri agentské role: SRE agent (klasifikácia, kontext, riešenie), Operations Analyst (kríž-nástrojová analýza), Scheduler (dynamický on-call management).

Honeycomb Query Assistant — prirodzeno-jazyková tvorba BubbleUp dotazov nad vysokokardinálnymi event dátami; silný v find-the-needle-in-haystack scenároch.

Postmortem auto-generation

LLM agent (napr. cez Slack API alebo PagerDuty timeline API) načíta:

Sekvenciu alertov s časovými pečiatkami
Slack kanál incidentu
Kroky runbooku, ktoré boli vykonané
Deploy timeline (kedy čo prišlo na produkciu)

A vygeneruje draft v štandardnom postmortem formáte: udalosti, impact, root cause, časová os, follow-up akcie.

Natural language telemetry query

Používateľ: "ukaz mi 95p latency pre /api/checkout za poslednú hodinu vs. včera rovnaký čas"

LLM preloží na PromQL:
  histogram_quantile(0.95,
    sum by (le) (
      rate(http_request_duration_seconds_bucket{
        handler="/api/checkout"
      }[1h])
    )
  )
+ offset 24h variant

Vráti: Grafana panel s oboma časovými radmi

On-call assistant agenti

Agenti s tool-use prístupom spúšťajú reálne akcie — nielen navrhujú:

Alert: PodCrashLoopBackOff api-server-7d9f4
→ Agent: kubectl logs api-server-7d9f4 --previous
→ Agent: (analyzuje logy) OOMKilled, limit 512Mi
→ Agent: kubectl describe deployment api-server
→ Agent: (vidí zmenu limits v poslednom deployi)
→ Agent navrhuje: patch resources na 1Gi alebo rollback
→ [Čaká na schválenie] → vykonáva zvolenú akciu

Open-source ekosystém

Prometheus Anomaly Detector (openshift/prometheus-anomaly-detector) — Fourier transform a Prophet na PromQL metrikách, beží ako sidecar k Prometheus
Robusta — K8s incident response platform, automaticky zbiera diagnostiku pri alertoch, posiela do Slacku, integrovateľná s vlastnými playbookmi v Pythone
KEDA — event-driven autoscaling z metrických signálov (Prometheus, Kafka, Redis), priamy most medzi AIOps signálmi a remediačnými akciami
OpenTelemetry GenAI SIG — štandardizuje sémantické konvencie pre LLM traces, aby bolo monitorovanie AI systémov interoperabilné naprieč vendormi
K8sGPT — open-source nástroj na analýzu K8s stavov s LLM backendom (OpenAI, Ollama, lokálne modely)

Referenčná architektúra

                      AIOps Reference Architecture
┌───────────────────────────────────────────────────────────────┐
│                        DATA SOURCES                           │
│  Prometheus   Loki   Tempo   Pyroscope   Events   Deploys     │
└──────────────────────────┬────────────────────────────────────┘
                           │  OTLP / scrape
                           v
┌──────────────────────────────────────────────────────────────┐
│                   INGEST & STORE LAYER                        │
│  OTel Collector  ──►  Metrics DB (Mimir/Thanos)              │
│                  ──►  Log store  (Loki)                       │
│                  ──►  Trace store (Tempo)                     │
│                  ──►  Profile store (Pyroscope)               │
└──────────────────────────┬───────────────────────────────────┘
                           │
                           v
┌──────────────────────────────────────────────────────────────┐
│                   ANALYTICS LAYER                             │
│  ┌─────────────────┐    ┌────────────────────────────────┐   │
│  │  ML Anomaly Det.│    │  Log Embedding Engine          │   │
│  │  (Prophet/IsoF) │    │  (chunk logs → vector DB)      │   │
│  └────────┬────────┘    └───────────────┬────────────────┘   │
│           │                             │                     │
│           └──────────────┬──────────────┘                     │
│                          v                                    │
│              ┌────────────────────────┐                       │
│              │  LLM Reasoning Engine  │                       │
│              │  + Tool Use            │                       │
│              │  (PromQL, LogQL,       │                       │
│              │   kubectl, runbook)    │                       │
│              └────────────┬───────────┘                       │
└──────────────────────────┬────────────────────────────────────┘
                           │
                           v
┌──────────────────────────────────────────────────────────────┐
│                   ACTION LAYER                                │
│  Slack/PagerDuty alert  │  Auto-remediation webhook          │
│  Postmortem draft       │  Runbook execution                  │
│  Dashboard annotation   │  Escalation to on-call             │
└──────────────────────────────────────────────────────────────┘

Kľúčom tejto architektúry je vector DB pre log embeddingy — umožňuje sémantické podobnostné hľadanie ("nájdi logy podobné tomuto error stacku z minulého mesiaca") a RAG LLM na relevantný kontext bez nutnosti posielať celé logové súbory do promptu.

OpenTelemetry GenAI Semantic Conventions

OpenTelemetry GenAI SIG (od 2024) štandardizuje, ako sledovať LLM volania v traces. Toto je dôležité pre samotné AIOps systémy, ktoré používajú LLM — ich overhead a správanie musí byť tiež monitorovateľné.

# Python priklad: OTel GenAI semantic conventions pre LLM span
from opentelemetry import trace
from opentelemetry.semconv._incubating.attributes import gen_ai_attributes

tracer = trace.get_tracer("aiops.incident-analyzer")

with tracer.start_as_current_span("gen_ai.chat") as span:
    span.set_attribute(gen_ai_attributes.GEN_AI_SYSTEM, "openai")
    span.set_attribute(gen_ai_attributes.GEN_AI_REQUEST_MODEL, "gpt-4o")
    span.set_attribute(gen_ai_attributes.GEN_AI_OPERATION_NAME, "chat")
    span.set_attribute(
        "gen_ai.request.max_tokens", 2048
    )
    # Po dokonceni volania
    span.set_attribute(gen_ai_attributes.GEN_AI_USAGE_INPUT_TOKENS, 1_240)
    span.set_attribute(gen_ai_attributes.GEN_AI_USAGE_OUTPUT_TOKENS, 380)
    span.set_attribute(
        "gen_ai.response.finish_reasons", ["stop"]
    )
    # Vlastny atribut pre AIOps usecase
    span.set_attribute("aiops.incident.id", "INC-2025-04-22-001")
    span.set_attribute("aiops.action.type", "rca_analysis")

Týmto spôsobom sú LLM volania z AIOps systému plne viditeľné v Tempo/Jaegeri a možno ich korelovať so skutočnými alertami, ktoré ich spustili.

Build vs. Buy — rozhodovací rámec

Typ organizácie	Odporúčaná cesta	Príklady
Malá org (<20 inžinierov)	Managed platforma	Datadog, New Relic, Grafana Cloud — AIOps je zabudovaný, žiadna údržba ML
Stredná org (20-100 inž.)	Open-source stack + malé interné rozšírenie	Prometheus + Loki + Tempo + Robusta + vlastné playbooks; LLM cez API pre postmortem
Veľká org (100+ inž., silná regulácia)	Vlastná platforma	Interná vector DB, fine-tuned model na vlastných runbookoch, on-premise LLM (napr. Mistral) pre PII compliance

Kľúčové otázky pre build vs. buy:

Objem dát — pri petabajtoch logov denne sú náklady na managed platformy vysoké
Data residency — telemetria môže obsahovať PII, ktorá nesmie opustiť EÚ alebo internú sieť
Customizácie — vlastný ontologický model služby sa lepšie implementuje interne
Inžinierska kapacita — údržba ML pipeline nie je zadarmo

Pitfalls a antipatterns

Alert fatigue nezmizne automaticky

ML model s vysokým false-positive ratom situáciu nezlepší — nahradí stovky statických alertov stovkami ML alertov. Kľúčom je iteratívne ladenie presnosti (precision) modelu, nie iba recall.

LLM halucinácie v RCA

LLM dokážu generovať presvedčivo znejúci root cause analysis, ktorý je fakticky nesprávny. Pravidlo: každý LLM návrh musí byť ukotvený (grounded) v reálnej telemetrii — citácia konkrétnej log hlášky, konkrétnej metriky, konkrétneho trace spanu. Nikdy neprijímajte LLM záver bez overenia.

Privacy: telemetria obsahuje PII a secrets

Logy webovej aplikácie rutinne obsahujú IP adresy, user IDs, niekedy aj session tokeny. Pred odoslaním do externého LLM (OpenAI, Anthropic API) je nutná sanitizácia:

Stripping email, IP, UUID patternou
Anonymizácia user identifikátorov
Kontrola, či logs-to-LLM pipeline nepretekajú do tretích strán

Model drift po architekturálnej zmene

Anomaly detection model trénovaný pred migráciou na microservices bude po migrácii vkladať alerty na všetko, lebo naučené vzory sú neplatné. Modely treba re-trénovať (alebo aspoň rekalibrovať) po významných architekturálnych zmenách.

Cost: LLM volania sa škálujú nelineárne

Ak každý Prometheus alert spustí LLM analýzu (napr. 500 alertov/h × 1 000 tokenov = 500 000 tokenov/h), náklady rýchlo prekročia úsporu z automatizácie. Riešenie: LLM aplikovať len na incidenty, nie na každý alert; používať lacnejší model pre prvotný triage a drahý model len pre finálnu analýzu.

Metriky úspechu AIOps

Metrika	Čo meria	Cieľ
MTTD (Mean Time to Detect)	Čas od vzniku problému po prvý alert	Znížiť z minút na sekundy
MTTR (Mean Time to Resolve)	Čas od incidentu po návrat do normálneho stavu	Znížiť o 30-60 %
Alert-to-incident ratio	Koľko alertov tvorí jeden incident	Cieľový pomer 10-50:1
Noise reduction rate	% potlačených alertov ktoré neboli akčne schopné	>60 %
Postmortem actionable fraction	% postmortemov s konkrétnym follow-up	>80 %
False positive rate (ML alerts)	% ML alertov ktoré neoznačujú reálny problém	<15 %

Evolučná cesta: od alertingu k autonómii

AIOps nie je binárne rozhodnutie — implementuje sa postupne:

Level 0 — Reaktívny alerting
  Statické prahy, ručná diagnostika, manuálny postmortem

Level 1 — Korelácia a grouping
  ML grupovanie alertov, zníženie hluku, kontext incidentu

Level 2 — Asistovaná diagnostika
  LLM navrhuje root cause, ukazuje relevantné logy/traces,
  inžinier rozhoduje a vykonáva

Level 3 — Asistovaná remediácia
  Systém navrhuje konkrétne príkazy, inžinier schvaľuje
  a systém vykonáva (human-in-the-loop)

Level 4 — Autonómna remediácia (známe scenáre)
  Pre dobre definované playbook scenáre systém koná
  autonómne, inžiniera notifikuje ex-post

Level 5 — Plná autonómia (experimentálne)
  Systém samostatne rozhoduje, navrhuje architekturálne
  zmeny, experimentuje s remediačnými stratégiami
  (2026: stále v research fáze pre kritické systémy)

Väčšina organizácií v roku 2026 operuje na Level 2-3. Posun na Level 4 vyžaduje vysokú dôveru v model, kvalitnú test coverage runbookov a dobre definované blast-radius limity pre automatické akcie.

Zdroje a ďalšie štúdium

OpenTelemetry GenAI Semantic Conventions — oficiálny spec pre LLM telemetriu
Datadog Bits AI SRE — referenčná implementácia LLM incident response agenta
Robusta — K8s incident response — open-source playbook engine pre Kubernetes
K8sGPT — open-source K8s analýza s LLM backendom
KEDA — Event Driven Autoscaling — autoscaling z metrických signálov
Grafana Slo — SLO management s anomaly detection
PagerDuty AIOps — event intelligence a alert korelácia
Pearl, J. (2009). Causality: Models, Reasoning, and Inference — základná literatúra ku kauzálnej inferencii v RCA

AIOps v roku 2026 prestal byť marketingovým buzzwordom a stal sa praktickou inžinierskou disciplínou. Kombinácia klasických ML metód (STL, Isolation Forest, DBSCAN) s LLM reasoning vrstvou umožňuje systémy, ktoré nielen detekujú anomálie, ale aj vedia prečo vznikli a čo s nimi robiť. Kľúčovým predpokladom úspechu zostáva kvalita vstupných dát — bez dobre štruktúrovanej observability (metrics, logs, traces, profiles, change events) zostane každý AIOps systém slepým hádaním.