AIOps to zastosowanie uczenia maszynowego do danych operacyjnych: progów, które dopasowują się do wzorca ruchu, korelacji zdarzeń pochodzących z jednej przyczyny i grupowania alarmów w jedno zgłoszenie. Nie jest zastępnikiem monitoringu ani dyżuru — jest warstwą nad telemetrią, którą trzeba mieć wcześniej.
Na skróty
Czego dowiesz się z artykułu:
- Jakie klasy sygnałów musi dostać warstwa AIOps, żeby cokolwiek rozstrzygnąć
- Dlaczego ujednolicona semantyka telemetrii jest warunkiem wstępnym, nie dodatkiem
- Co progi dynamiczne robią dobrze, a czego z definicji nie wykryją
- Gdzie przebiega granica między automatyczną reakcją a decyzją dyżurnego
Dla kogo jest ten artykuł:
- Inżynierowie SRE i zespoły utrzymujące usługi produkcyjne
- Liderzy zespołów rozważający wdrożenie narzędzi klasy AIOps
- Osoby odpowiadające za jakość dyżuru i liczbę zgłoszeń nocnych
Czas czytania: 7 minut
Co AIOps dostaje na wejściu
Dokumentacja opentelemetry.io o sygnałach porządkuje wejście w nazwane klasy, z których trzy są tu główne: metryki, czyli zagregowane pomiary liczbowe w czasie; dzienniki zdarzeń, czyli zapisy pojedynczych zdarzeń z kontekstem; oraz trace’y, czyli powiązane zapisy przejścia żądania przez usługi. Lista sygnałów w tym źródle jest szersza i wciąż rośnie, ale warstwa AIOps pracuje przede wszystkim na tych trzech. Każda klasa odpowiada na inne pytanie — metryka mówi, że jest źle, dziennik mówi co się stało, a trace mówi gdzie.
Warstwa modelowa bez wszystkich tych klas pracuje na niepełnym obrazie i to widać w jej wynikach. Narzędzie dostające wyłącznie metryki potrafi wskazać moment anomalii, ale nie potrafi jej przypisać do usługi w łańcuchu wywołań, bo tej informacji po prostu nie ma na wejściu. Dlatego wdrożenia AIOps najczęściej zatrzymują się nie na modelu, a na brakującym trace’owaniu rozproszonym.
Rozdział sre.google o monitorowaniu systemów rozproszonych daje tu poprzeczkę niezależną od narzędzia: wymienia cztery sygnały, od których warto zacząć — opóźnienie, ruch, liczbę błędów i nasycenie zasobów. To jest minimalny zestaw, na którym warstwa AIOps ma czym pracować, i jednocześnie dobry test gotowości: jeśli któregoś z nich nie zbieracie dla usługi, wdrożenie narzędzia tego nie naprawi.
Warunek wstępny: wspólna semantyka telemetrii
To jest miejsce, w którym projekty AIOps przegrywają najczęściej, i zarazem najmniej widowiskowe. Model korelujący zdarzenia musi wiedzieć, że service.name w jednym strumieniu i app w drugim oznaczają to samo — a jeśli nie wie, zbuduje osobne, niepowiązane obrazy tej samej usługi.
Konwencje semantyczne opisane w opentelemetry.io rozwiązują to przez ustalone nazwy i znaczenia atrybutów telemetrii: usługi, zasobu, operacji, błędu. Wartość jest prozaiczna — dopiero przy wspólnym słowniku da się zapytać o wszystkie żądania jednej usługi niezależnie od tego, który zespół instrumentował którą część. Wdrożenie, które zaczyna się od wyboru narzędzia, a nie od ustalenia słownika atrybutów, kupuje sobie mapowanie pól robione ręcznie przy każdym nowym strumieniu.
Praktyczna kolejność jest więc odwrotna do intuicyjnej: najpierw instrumentacja z ustalonymi atrybutami, potem zbieranie wszystkich klas sygnałów do wspólnego miejsca, a narzędzie klasy AIOps na końcu. Odwrotna kolejność daje wdrożenie, w którym model jest uruchomiony, a jego wyniki nie są używane w dyżurze.
Co potrafi warstwa modelowa
Progi dynamiczne są najbardziej dojrzałym zastosowaniem. Dokumentacja learn.microsoft.com o progach dynamicznych w regułach alarmowych opisuje mechanizm, który uczy się historycznego zachowania metryki, buduje na tej podstawie oczekiwany zakres i alarmuje przy odchyleniu od wzorca — z uwzględnieniem sezonowości dobowej i tygodniowej. Zysk jest konkretny i nie wymaga obietnic: reguła nie wymaga ręcznego ustawienia wartości progu dla każdej metryki osobno, a ruch nocny przestaje wyglądać jak awaria.
Czego progi dynamiczne z definicji nie wykryją: stanu, który był zły od początku pomiaru. Model uczy się tego, co widzi, więc usługa odpowiadająca zawsze zbyt wolno zostanie uznana za normalną. Dlatego progi dynamiczne nie zastępują progów wynikających z celu poziomu usługi — oba mechanizmy odpowiadają na różne pytania i oba są potrzebne.
Drugim zastosowaniem jest korelacja i grupowanie. Pojedyncza awaria bazy danych generuje alarmy ze wszystkich usług, które z niej korzystają; warstwa korelująca łączy je w jedno zgłoszenie po wspólnym oknie czasowym i wspólnych atrybutach zasobu. Wartość siedzi w tym, że dyżurny dostaje jedno zgłoszenie z listą skutków, a nie listę zgłoszeń bez przyczyny. Tutaj znowu rozstrzyga słownik atrybutów, nie model.
Role i granica automatyzacji
Inżynier SRE pozostaje odbiorcą i recenzentem wyników, nie ich konsumentem bez prawa głosu. Praktyczna granica, którą warto zapisać przed wdrożeniem: automatyzacja wykonuje działania odwracalne i opisane wcześniej — restart instancji, odcięcie węzła od równoważenia ruchu, zwiększenie liczby replik. Działania nieodwracalne albo niedopisane do listy pozostają decyzją człowieka, także wtedy, gdy model jest ich pewny.
Właściciel usługi odpowiada za cele poziomu usługi, bo to on zna wymaganie biznesowe; bez nich warstwa AIOps optymalizuje ciszę w kanale alarmowym, a nie dostępność. Osoba utrzymująca warstwę telemetrii odpowiada za słownik atrybutów i za to, że nowy strumień wchodzi z poprawnymi nazwami, a nie po mapowaniu doraźnym.
Ostatnia rzecz, którą trzeba nazwać wprost: AIOps nie zmniejsza potrzeby rozumienia systemu. Zmienia pracę dyżurnego z czytania wielu alarmów na ocenę jednego wniosku razem z materiałem, który do niego doprowadził — a ocena wniosku wymaga wiedzy o systemie większej, nie mniejszej. Wdrożenie uzasadniane oszczędnością kompetencji w zespole zwykle kończy się zaufaniem do wyniku, którego nikt nie potrafi zakwestionować.
Czytaj także
- Observability — logi, metryki i trace’y w praktyce — klasy sygnałów i sposób ich zbierania
- Observability vs monitoring — praktyczny przewodnik SRE — różnica, od której zależy, co warstwa modelowa dostanie na wejściu
- Blue-green i canary deployment w praktyce — pierwszy odbiorca metryk rozróżniających wersje
Rozwijaj kompetencje
Temat rozwijają szkolenia AIOps — automatyzacja i optymalizacja operacji IT z użyciem AI oraz Observability — OpenTelemetry, Grafana Stack i AIOps. Pierwsze dotyczy samej warstwy modelowej i jej zastosowań w operacjach, drugie warstwy telemetrii, bez której ta pierwsza nie ma wejścia. Skontaktuj się z nami, żeby dopasować zakres do stanu Waszego monitoringu.
Najczęściej zadawane pytania (FAQ)
Czym AIOps różni się od zwykłego monitoringu z alarmami?
Monitoring porównuje pomiar z progiem ustawionym przez człowieka. AIOps dokłada warstwę, która wyprowadza oczekiwany zakres z historii metryki oraz łączy zdarzenia pochodzące z jednej przyczyny w jedno zgłoszenie. Nie zastępuje progów wynikających z celu poziomu usługi — tamte opisują wymaganie, a nie wzorzec zachowania.
Czy AIOps da się wdrożyć bez trace’owania rozproszonego?
Da się uruchomić, ale wyniki będą ograniczone do wskazania momentu anomalii. Bez trace’ów warstwa modelowa nie ma informacji o przejściu żądania przez usługi, więc nie przypisze anomalii do miejsca w łańcuchu wywołań. To najczęstsza przyczyna wdrożeń, które działają i nie są używane w dyżurze.
Czy można pozwolić narzędziu samodzielnie reagować na incydenty?
Tak, w zakresie działań odwracalnych i opisanych przed wdrożeniem — restartu instancji, odcięcia węzła od równoważenia ruchu, zmiany liczby replik. Działania nieodwracalne i te poza listą zostają decyzją dyżurnego. Granicę warto zapisać razem z listą, bo rozstrzygana w trakcie incydentu zawsze przesuwa się w stronę większej automatyzacji.
Od czego zacząć, jeśli mamy wiele narzędzi monitorujących i żadnego wspólnego słownika?
Od ustalenia nazw atrybutów dla usługi, zasobu i operacji, a potem od sprowadzenia strumieni do wspólnego miejsca. Dopiero mając wspólny słownik warto porównywać narzędzia klasy AIOps, bo ich skuteczność zależy od jakości wejścia bardziej niż od samego modelu. Kolejność odwrotna kończy się mapowaniem pól przy każdym nowym strumieniu.