Od dostupnosti k zážitku: AI‑poháněný posun v moderní observabilitě

V roce 2001 IBM sepsala manifest o autonomním IT. Vize autonomního výpočtu rozdělila samo‑správu do čtyř pilířů: samo‑optimalizaci, samo‑léčení, samo‑konfiguraci a samo‑ochranu. Byl jsem ve společnosti Microsoft, když IBM představila tuto IT vizi. Reagovali jsme návrhem technologických konceptů, jako je autonomní datové centrum, ale nakonec šlo o sen, který byl mnohem před svým časem. Neexistoval praktický způsob, jak tuto vizi uvést do reality.

V době, kdy jsem pracoval v Microsoftu, jsem byl v týmu stojícím za Clippym. I když byl animovaný asistent ve tvaru sponky notoricky vtíravý, myšlenka za ním byla rozumná: počítače by měly aktivně pomáhat lidem vykonávat jejich práci. Jen jsme neměli dostatečnou výpočetní sílu a AI, aby to bylo možné. O 25 let později to konečně funguje.

Od úrovně služby k úrovni zážitku

Koncept observability nevznikl v IT. V roce 1960 maďarsko‑americký inženýr a matematik Rudolf E. Kálmán zavedl termín „observability“ k popisu toho, jak dobře lze systém měřit jeho výstupy. Poté v roce 2013 Twitter přijal termín v sérii blogových příspěvků, čímž v podstatě prohlásil, že staromódní monitorování pomocí všech komerčních off‑the‑shelf nástrojů, které měli k dispozici, bylo navrženo pro jinou technologickou éru a nefunguje v architekturách na úrovni mikroservis.

Chtělo by to být jako lékař vyšetřující pacienta. Může zkontrolovat puls, změřit krevní tlak a pozorovat další vnější znaky, aby nepřímo posoudil vnitřní zdraví pacienta. V IT musíme dělat totéž. Když se v pulsu pacienta objeví záblesk, musíme vědět, zda to znamená problémy v ledvinách nebo v játrech. V rozsahu a složitosti operací, se kterými se Twitter potýkal před 20 lety (společnost obsluhovala jen 100 milionů uživatelů s real‑time tweety a kanály), vyžadovala observabilita odlišné nástroje a přístup k monitorování.

Dnešní systémy se staly ještě většími a složitějšími, s závislostmi na sítích pro doručování obsahu, cachování a distribuci bitmap, fontů, souborů JavaScript a podobně po celém světě. Skutečně pochopit výkon reálných aplikací není snadný úkol.

Když IT dostane výzvu v 4 hodin ráno, někdo musí vstát z postele a zjistit, zda je problém způsoben špatným sektorem na pevném disku nebo útočníkem, který se snaží proniknout a způsobit chaos v infrastruktuře. Ve skutečnosti na tom nezáleží: na konci dne je jejich úkolem udržet všechny systémy v chodu. Naštěstí k hodnocení zdraví aplikací dnes můžeme využít veškerou dostupnou telemetrii: každé síťové zařízení, každou aplikaci, tisíce hotových integrací, tok ticketů přes JIRA nebo Atlassian a mnoho dalších signálů.

Toto je místo, kde vstupují Experience Level Objectives (XLO). Pravděpodobně jste slyšeli o Service Level Agreements (SLA) a Service Level Objectives (SLO), ale XLO posouvají věc o krok dál tím, že měří, zda vaši zákazníci a zaměstnanci získávají úroveň zážitku, kterou chtějí. Jde o kvalitu, nejen o dostupnost. Z technického hlediska je jediným způsobem, jak dosáhnout XLO, mít viditelnost od síťové karty až po koncové zařízení uživatele.

V loňském říjnu AWS US‑EAST‑1 selhal. Catchpoint detekoval problém 16 minut před tím, než ho Amazon veřejně potvrdil. Zákazníci s touto viditelností byli schopni reagovat dříve, než jejich uživatelé pocítili následky výpadku.

Slíbením observability je být jako Smokey Bear: detekovat kouř dříve, než vznikne požár. Když je provedeno správně, observabilita vám umožní uhasit prérijní požár dříve, než se změní v obrovskou požární vlnu, která zničí Palisades v Kalifornii. Smokey je včasný varovný systém, který dokáže zachytit i ty nejmenší obláčky kouře bez ohledu na to, odkud pocházejí: problém v AWS, problém v Oracle, problém v GCP, problém v Microsoft Azure nebo něco špatného ve vaší infrastruktuře.

AI rozšiřuje bezpečnostní systémy

Žádný lidský operátor nedokáže sledovat dnešní infrastrukturní systémy. Jediný způsob, jak monitorovat systémy ve velkém, zpracovávat petabajty logů a biliony metrik denně, je použít AI.

Například pokud chcete sledovat výkon čtení/zápisu na disku nebo vstup/výstup či přetečení bufferu paketů ve vašem síťovém prostředí. Můžete použít dynamický práh k definování toho, jak vypadá normální stav, nebo deterministický způsob, jak se podívat na časové řady za poslední týden, měsíc, rok nebo jakýkoli časový rámec, který si zvolíte, a stanovit normální výkonnostní prahy. Jakmile máte tuto statistickou analýzu, můžete nastavit úrovně pro dvě standardní odchylky od průměru, takže když se něco stane mimo tento rozsah, obdržíte upozornění, že výkon může být abnormální.

Vysoce komplexní systémy však mohou přijímat tisíce upozornění denně. Dashboardy začnou blikat a lidé jsou pagováni. Procházet všechna tato upozornění není dobré využití lidského času. Vskutku Vectra odhadují, že organizace dostávají v průměru 2 992 bezpečnostních upozornění denně, z nichž 63 % zůstává nevyřešeno.

Nástroje AI mohou snížit tyto tisíce upozornění denně na pouhých několik desítek. Pamatuji si případ, kdy jediný problém na jedné síťové kartě (NIC) na jednom serveru vyvolal 2 000 následných upozornění. Díky AI dokázal klient provést korelaci upozornění a rychlejší analýzu příčiny, která pak ukázala, že jediný problém v daném okamžiku způsoboval, že celé řídicí panel společnosti se zčervenal.

AI opět činí IT vzrušujícím

Po akvizici Splunku společností Cisco v roce 2023 jsem si vzal volno. V následujících dvou letech jsem sledoval, jak moji přátelé a bývalí kolegové zakládali společnosti, které využívají AI způsoby, jež nebyly možné ani před pěti lety. (Pamatujte, že kdyby byl ChatGPT lidským dítětem, byl by tříletý).

IT týmy potřebují pomoc při odhalování kouře dříve, než zazvoní alarm, ne další řídicí panely, do kterých se dívají. Ti. V podstatě jde o stejný problém, který se snaží řešit IBM, Twitter a dokonce i Microsoft s Clippym.

To je důvod, proč jsem se rozhodl vrátit se zpět. Technologie konečně dosáhla bodu, kdy můžeme naplnit původní slib pozorovatelnosti a autonomního IT.