Průměrný enterprise provozuje 1 000+ mikroslužeb, generuje terabajty logů denně a jeho on-call inženýr dostane 500+ alertů za směnu. Lidský mozek tohle nezpracuje. AIOps — aplikace strojového učení na IT operations — mění paradigma z reaktivního „hasiče požárů” na proaktivní, samoopravující se infrastrukturu. V tomto článku rozebíráme, co AIOps v roce 2026 reálně umí, kde selhává a jak ho nasadit pragmaticky.
Co je AIOps — a co není¶
Termín AIOps poprvé definoval Gartner v roce 2017 jako spojení big data analytics a machine learning aplikované na IT operations. Od té doby se z marketingového buzzwordu stal reálný engineering discipline s měřitelnými výsledky.
AIOps v praxi pokrývá čtyři klíčové oblasti:
- Anomaly Detection: Automatická detekce odchylek v metrikách, logách a traces bez manuálních thresholdů. ML modely se učí „normální” chování a signalizují statisticky významné anomálie.
- Event Correlation: Seskupování tisíců alertů do logických incidentů. 500 alertů z jednoho root cause = 1 incident, ne 500 ticketů.
- Root Cause Analysis (RCA): Automatická identifikace příčiny problému v komplexním dependency grafu. Kauzální inference místo manuálního procházení dashboardů.
- Auto-Remediation: Automatická oprava známých problémů bez lidského zásahu. Runbooky řízené ML modely, které rozhodují kdy a jak zasáhnout.
Co AIOps není: není to náhrada za monitoring. Prometheus, Grafana, Datadog — to vše zůstává. AIOps je vrstva inteligence nad existujícím observability stackem, která z dat extrahuje akční insights.
Proč teď — tři konvergující trendy¶
AIOps existuje roky, ale teprve v 2025–2026 dosáhl inflexního bodu díky třem faktorům:
- LLM revoluce: Velké jazykové modely (GPT-4o, Claude, Gemini) umí interpretovat logy, stack traces a konfigurační soubory v přirozeném jazyce. RCA se mění z pattern matchingu na reasoning over context. Incident responder může napsat „proč spadl checkout service?” a dostat strukturovanou analýzu s evidencí.
- OpenTelemetry standardizace: OTel se stal de-facto standardem pro traces, metrics i logs. Jednotný datový model umožňuje korelaci across celého stacku — od frontendu přes backend po infrastrukturu. Vendor lock-in mizí.
- Explosion complexity: Kubernetes, service mesh, multi-cloud, edge computing — moderní infrastruktura má tisíce pohyblivých částí. Člověk to nezvládne. Buď automatizujete, nebo tonete v alertech.
5 úrovní AIOps maturity¶
Ne každá organizace potřebuje plně autonomní infrastrukturu. AIOps se implementuje postupně:
| Úroveň | Popis | Příklad |
|---|---|---|
| L0 — Manual | Statické thresholdy, manuální triage | Alert: CPU > 90 % → pager → člověk řeší |
| L1 — Assisted | ML-driven anomaly detection, ale člověk rozhoduje | ML detekuje latency anomálii, navrhne možné příčiny |
| L2 — Semi-auto | Automatická korelace + RCA, člověk schvaluje remediation | Systém identifikuje root cause, navrhne rollback, čeká na approve |
| L3 — Auto | Automatická remediation pro známé scénáře | Memory leak → auto-restart podu, traffic spike → auto-scale |
| L4 — Autonomous | Self-healing infrastruktura, predictivní akce | Predikce capacity exhaustion za 48h → preemptivní scale-up |
Většina českých firem je na L0–L1. Cílem pro 2026 by mělo být dostat se na L2–L3 pro kritické systémy.
Anomaly Detection — beyond static thresholds¶
Statické thresholdy (CPU > 80 %, response time > 500 ms) generují false positives i false negatives. CPU na 85 % v 10:00 je normální; v 3:00 je to anomálie. Response time 600 ms je OK pro batch job; pro checkout je to incident.
Moderní anomaly detection používá:
- Seasonal decomposition: STL (Seasonal-Trend decomposition using Loess) rozloží časovou řadu na trend, sezónnost a residuum. Anomálie = statisticky významná odchylka v residuu. Zachytí denní, týdenní i měsíční patterns.
- Isolation Forest: Unsupervised ML algoritmus optimální pro high-dimensional data. Efektivně izoluje outliers bez nutnosti labelovaných dat. Datadog a Elastic ho interně používají pro metric anomaly detection.
- Transformer-based models: Časové řady jako sekvence — transformery (TimesFM od Google, Chronos od Amazon) predikují expected behavior a detekují deviace. State-of-the-art pro multivariate anomaly detection.
- Log anomaly detection: LLM-based parsery extrahují strukturované eventy z nestrukturovaných logů. Drain nebo Brain pro log template mining, pak statistická analýza frekvence a sekvence log patterns. Nový log pattern, který systém dosud neviděl? → alert.
Praktický tip: Začněte s golden signals (latency, traffic, errors, saturation). 4 metriky, dobře monitorované a s ML anomaly detection, zachytí 80 % incidentů. Nepokoušejte se monitorovat vše najednou.
Event Correlation a noise reduction¶
Typický incident v microservices architektuře generuje kaskádu alertů. Database je pomalá → 50 služeb timeoutuje → load balancer reportuje 5xx → health checky selhávají → Kubernetes restartuje pody → nové pody se startují → resource contention roste. Výsledek: 500+ alertů za 5 minut, všechny ze stejného root cause.
Event correlation redukuje tento noise:
- Topology-aware grouping: Znalost dependency grafu (service A → service B → database) umožňuje seskupit alerty do kauzálních řetězců. Nástroje: PagerDuty Event Intelligence, BigPanda, Moogsoft.
- Temporal clustering: Alerty ve stejném časovém okně (±2 min) s podobnými atributy se shlukují. DBSCAN nebo hierarchické clustering na feature vektorech (service, severity, message embedding).
- Graph-based correlation: Dependency graf infrastruktury + propagace anomálií po hranách. Pokud služba A závisí na B a obě mají anomálii, korelujeme. Knowledge graph technologie (Neo4j, Apache AGE) pro real-time traversal.
Reálné výsledky: organizace reportují 80–95 % redukci alert volume po nasazení event correlation. 500 alertů → 5 incidents → 1 root cause.
Root Cause Analysis s LLM¶
RCA je nejsložitější a zároveň nejvíce transformovaná oblast AIOps v roce 2026. LLM modely přidávají schopnost reasoning — nejen pattern matching, ale kauzální uvažování nad komplexním kontextem.
Jak LLM-powered RCA funguje v praxi:
- Context assembly: Systém sbírá relevantní data — anomální metriky, error logy, traces, recent deployments, config changes, k8s events. Vše se kompiluje do strukturovaného kontextu.
- Causal reasoning: LLM analyzuje kontext a navrhuje hypotézy. „Deploy v 14:23 změnil connection pool size z 50 na 10. Database connections saturovaly v 14:25. Latency služby X vzrostla v 14:26. Hypotéza: connection pool change je root cause.”
- Evidence scoring: Každá hypotéza se vyhodnocuje proti datům. Koreluje časově? Odpovídá dependency grafu? Jsou podobné incidenty v historii?
- Recommendation: Top hypotéza s remediation návrhem. „Rollback deploy #4521 nebo zvýšit connection pool na 50.”
Nástroje v produkci:
- Datadog Watchdog RCA: ML-driven root cause analysis integrovaná do APM. Automaticky koreluje traces, metrics a logs. LLM-powered natural language summaries od 2025.
- Dynatrace Davis AI: Kauzální AI engine s topology awareness. Automaticky mapuje dependency graph a propaguje root cause. Jeden z nejpokročilejších produkčních AIOps systémů.
- Grafana Sift: Open-source přístup — Grafana plugins pro automatický drill-down z alertu do root cause přes dashboardy. Integrace s LLM pro interpretaci dat.
- Custom LLM pipelines: RAG (Retrieval-Augmented Generation) nad runbooky, incident historií a dokumentací. Claude nebo GPT jako reasoning engine, vektorová databáze jako knowledge base. Open-source stack: LangChain + ChromaDB + Prometheus/Loki data.
Auto-Remediation — self-healing infrastructure¶
Auto-remediation je svatý grál AIOps. Systém nejen detekuje a diagnostikuje problém, ale sám ho opraví. V roce 2026 je to realita pro definované scénáře:
- Kubernetes auto-healing: HPA (Horizontal Pod Autoscaler) pro traffic spiky. VPA (Vertical Pod Autoscaler) pro resource tuning. PodDisruptionBudgets + rollout strategies pro zero-downtime deploys. KEDA pro event-driven scaling (queue depth, custom metrics).
- Automated rollback: Canary deploy s automatic rollback při error rate > threshold. Argo Rollouts nebo Flagger monitorují golden signals a rollbackují deploy pokud metriky degradují. Žádný lidský zásah — deploy se vrátí sám.
- Chaos engineering integration: Litmus, Chaos Mesh — pravidelné injektování selhání do produkce. Ověřuje, že auto-remediation skutečně funguje. Netflix princip: „Pokud nemáte chaos testing, nevíte jestli vaše auto-healing funguje.”
- Runbook automation: PagerDuty Rundeck, Ansible + Event-Driven Ansible (EDA). ML model klasifikuje incident → spustí příslušný runbook → vykoná kroky → ověří fix → eskaluje pokud selže. Člověk zasahuje jen v L3+ scénářích.
Guardrails pro auto-remediation¶
Automatická oprava bez guardrails je nebezpečná. Systém, který „opravuje” problém, může způsobit horší incident. Klíčové safety mechanismy:
- Blast radius limits: Auto-remediation smí ovlivnit max X % podů/instancí najednou. Nikdy nerestartujte celý cluster automaticky.
- Cooldown periods: Po automatické akci čekat N minut a ověřit, že metriky se zlepšily. Pokud ne → rollback remediation + eskalace.
- Human-in-the-loop pro kritické systémy: Payment processing, health systems — auto-remediation navrhne akci, člověk schvaluje. Slack/Teams notification s approve/reject tlačítkem.
- Audit trail: Každá automatická akce se loguje s důvodem, kontextem a výsledkem. Compliance requirement pro regulované odvětví.
Implementační stack pro české firmy¶
Pragmatický AIOps stack, který můžete nasadit s existujícím týmem:
Open-source základ¶
# Observability layer
Prometheus + Grafana — metriky a dashboardy
Loki — log aggregation
Tempo / Jaeger — distributed tracing
OpenTelemetry Collector — unified data collection
# AIOps layer
Robusta — K8s troubleshooting + auto-remediation
Grafana ML — anomaly detection na Prometheus data
Elasticsearch ML — log anomaly detection
Argo Rollouts — automated canary + rollback
# LLM layer
RAG pipeline (LangChain) — RCA nad runbooky + incident historií
ChromaDB / Qdrant — vector store pro knowledge base
Claude API / local LLM — reasoning engine
Enterprise alternativa¶
- Datadog: All-in-one. APM + logs + metrics + Watchdog AI. Nejrychlejší time-to-value, ale nejvyšší TCO.
- Dynatrace: Nejpokročilejší AIOps (Davis AI). Automatický discovery, topology mapping, root cause. Ideální pro komplexní enterprise prostředí.
- Elastic Observability: Open-source jádro + komerční ML features. Dobrý balance cena/funkcionalita. Silný v log analytics.
- Azure Monitor + AI: Nativní pro Azure workloady. Application Insights, Log Analytics, AIOps features integrované do platformy. Logická volba pro Azure-heavy organizace.
Metriky úspěchu AIOps¶
AIOps se musí měřit. Bez metrik nevíte, jestli investice funguje:
- MTTD (Mean Time To Detect): Čas od vzniku problému po detekci. Cíl: < 2 minuty pro P1 incidenty. Baseline bez AIOps: typicky 15–30 minut.
- MTTR (Mean Time To Resolve): Čas od detekce po vyřešení. AIOps cíl: 50 % redukce. Auto-remediation scénáře: MTTR → 0 (self-healing).
- Alert-to-incident ratio: Kolik alertů vygeneruje 1 incident. Bez korelace: 100:1. S AIOps: 5:1. Metrika noise reduction.
- False positive rate: Kolik anomaly detection alertů je skutečných. Cíl: < 20 % false positive. Příliš mnoho false positives = alert fatigue = ignorování alertů.
- Auto-remediation coverage: Kolik % incidentů se vyřeší automaticky. Start: 10–20 %. Zralá organizace: 60–80 % L1/L2 incidentů.
- On-call burden: Počet page-outs per engineer per week. Cíl: < 2. AIOps eliminuje šum a řeší triviální incidenty automaticky.
Od hasičů k architektům¶
AIOps mění roli SRE/ops týmů z reaktivních hasičů na architekty self-healing systémů. Cílem není eliminovat lidi z operations — cílem je přesunout jejich čas od manuálního triagování alertů k budování robustnější infrastruktury.
Kde začít: OpenTelemetry pro standardizovaný sběr dat. ML anomaly detection na golden signals (4 metriky). Event correlation pro noise reduction. To je základ, který přinese okamžité výsledky — méně šumu, rychlejší detekce, méně nočních page-outů.
Auto-remediation a LLM-powered RCA jsou další fáze — stavějte na solidním observability základu, ne na buzzwordu.