Od dostępności do doświadczenia: napędzana sztuczną inteligencją zmiana w nowoczesnej obserwowalności

W 2001 roku IBM napisało manifest autonomicznego IT. Wizja autonomicznego przetwarzania podzieliła samozarządzanie na cztery filary: samodoskonalenie, samonaprawę, samokonfigurację i samoochronę. Byłem w Microsoft, gdy IBM przedstawiło tę wizję IT. Zareagowaliśmy, proponując pomysły technologiczne, takie jak autonomiczne centrum danych, ale ostatecznie była to marzenie, które wyprzedzało swoją epokę. Nie było praktycznego sposobu, aby wprowadzić tę wizję w życie.

W czasach mojej pracy w Microsoft byłem w zespole odpowiedzialnym za Clippy’ego. Mimo że animowany spinacz asystent był niesławnie natrętny, pomysł za nim był słuszny: komputery powinny aktywnie pomagać ludziom w wykonywaniu ich pracy. Po prostu nie mieliśmy wtedy mocy obliczeniowej i sztucznej inteligencji, aby to umożliwić. 25 lat później w końcu to robimy.

Od poziomu usług do poziomu doświadczenia

Koncepcja obserwowalności nie wywodzi się z IT. W 1960 roku węgiersko-amerykański inżynier i matematyk Rudolf E. Kálmán ukazał termin „observability”, aby opisać, jak dobrze system można zmierzyć na podstawie jego wyjść. Następnie, w 2013 roku, Twitter przyjął termin w serii wpisów na blogu, skutecznie stwierdzając, że tradycyjne monitorowanie, przy użyciu wszystkich dostępnych komercyjnych gotowych narzędzi, było przeznaczone dla innej epoki technologicznej i nie działało w architekturach o skali mikroserwisów.

Wyobraź sobie to jak lekarz badający pacjenta. Może sprawdzić puls, zmierzyć ciśnienie krwi i obserwować inne cechy zewnętrzne, aby pośrednio ocenić stan wewnętrzny pacjenta. W IT musimy robić to samo. Gdy pojawi się migotanie w pulsie pacjenta, musimy wiedzieć, czy oznacza to problemy z nerką czy wątrobą. W skali i złożoności operacji, z jakimi Twitter zmagał się już 20 lat temu (firma obsługiwała jedynie 100 milionów użytkowników korzystających z tweetów i kanałów w czasie rzeczywistym), obserwowalność wymagała innego zestawu narzędzi i podejścia do monitorowania.

Współczesne systemy stały się jeszcze większe i bardziej złożone, z zależnościami od sieci dostarczania treści, buforowania i dystrybucji bitmap, czcionek, plików JavaScript i podobnych elementów na całym świecie. Rzeczywiste zrozumienie wydajności aplikacji działających w realnym środowisku nie jest łatwym zadaniem.

Kiedy dział IT otrzymuje zgłoszenie o 4 nad ranem, ktoś musi wstać z łóżka i ustalić, czy problem wynika z uszkodzonego sektora na dysku twardym, czy z działającego złośliwie podmiotu próbującego włamać się i spowodować chaos w infrastrukturze. Nie ma to większego znaczenia, który to jest: w końcu ich zadaniem jest utrzymanie wszystkich systemów w działaniu. Na szczęście, aby ocenić zdrowie aplikacji dzisiaj, możemy zebrać wszystkie dostępne dane telemetryczne: każde urządzenie sieciowe, każdą aplikację, tysiące gotowych integracji, przepływ zgłoszeń przez JIRA lub Atlassian oraz wiele innych sygnałów.

To właśnie tutaj pojawiają się Cele Poziomu Doświadczenia (XLO). Pewnie słyszałeś o Umowach o Poziomie Usług (SLA) i Celach Poziomu Usług (SLO), ale XLO idą o krok dalej, mierząc, czy Twoi klienci i pracownicy otrzymują pożądany poziom doświadczenia. Chodzi o jakość, nie tylko o dostępność. Z technicznego punktu widzenia jedynym sposobem osiągnięcia XLO jest posiadanie widoczności od karty sieciowej (NIC) aż po urządzenie końcowego użytkownika.

W zeszły październik AWS US‑EAST‑1 przestał działać. Catchpoint wykryło problem 16 minut przed tym, jak Amazon publicznie przyznał jego istnienie. Klienci posiadający taką widoczność mogli zareagować, zanim ich użytkownicy odczuli skutki awarii.

Obietnica obserwowalności jest jak Smokey Bear: wykrywać dym, zanim pojawi się ogień. Przy odpowiednim podejściu obserwowalność pozwala ugasić pożar na prerii, zanim przekształci się w pożar, który zniszczy Palisades w Kalifornii. Smokey jest wczesnym systemem ostrzegawczym, który potrafi wykrywać te małe podmuchy dymu, niezależnie od ich źródła: problem z AWS, problem z Oracle, problem z GCP, problem z Microsoft Azure lub coś nie tak w Twojej infrastrukturze.

AI skalują systemy bezpieczeństwa

Żaden człowiek nie jest w stanie nadążyć za dzisiejszymi systemami infrastruktury. Jedynym sposobem monitorowania systemów w skali, przetwarzając petabajty danych logów i biliony metryk dziennie, jest wykorzystanie AI.

Na przykład, jeśli chcesz śledzić wydajność odczytu/zapisu na dysku lub przepustowość wejścia/wyjścia czy przepełnienia bufora pakietów w środowisku sieciowym, możesz użyć dynamicznego progu, aby określić, jak wygląda normalność, lub deterministycznego podejścia do analizy danych szeregów czasowych z ostatniego tygodnia, miesiąca, roku lub dowolnego wybranego okresu, i ustalić normalne progi wydajności. Gdy masz tę analizę statystyczną, możesz ustawić poziomy na dwie odchylenia standardowe od średniej, tak aby gdy coś wydarzy się poza tym zakresem, otrzymasz alert, że wydajność może być nieprawidłowa.

Jednak wysoce złożone systemy mogą otrzymywać tysiące alertów dziennie. Pulpity zaczynają migać, a ludzie są powiadamiani. Przeglądanie wszystkich tych alertów nie jest efektywnym wykorzystaniem czasu ludzi. Rzeczywiście, Vectra szacuje, że organizacje otrzymują średnio 2 992 alerty bezpieczeństwa dziennie, z czego 63 % pozostaje niezaadresowanych.

Narzędzia AI mogą ograniczyć te tysiące alertów dziennie do zaledwie kilku dziesięciu. Pamiętam przypadek, w którym pojedynczy problem na jednej karcie sieciowej w jednym serwerze spowodował 2 000 zależnych alertów. Dzięki AI klient był w stanie przeprowadzić korelację alertów i szybciej dotrzeć do analizy przyczyny źródłowej, co z kolei wykazało, że jeden problem w tym konkretnym momencie powodował, że cały pulpit firmy zmienił się na czerwony.

AI znów czyni IT ekscytującym

Wziąłem trochę wolnego po tym, jak Cisco przejęło Splunk w 2023 roku. Przez kolejne dwa lata obserwowałem, jak moi przyjaciele i byli koledzy zakładali firmy, aby wykorzystywać AI w sposób, który jeszcze pięć lat temu był niemożliwy. (Pamiętajcie, że gdyby ChatGPT był ludzkim dzieckiem, miałby trzy lata).

Zespoły IT potrzebują pomocy w wykrywaniu dymu, zanim włączy się alarm, a nie kolejnych pulpitów do wpatrywania się. Oni. W pewnym sensie jest to ten sam problem, z którym IBM, Twitter i nawet Microsoft z Clippym starają się zmierzyć.

To jest powód, dla którego postanowiłem wrócić. Technologia w końcu osiągnęła punkt, w którym możemy spełnić pierwotną obietnicę obserwowalności i autonomicznego IT.