Przypadki użycia AI w operacjach sieciowych dużych centrów danych
Większość twierdzeń o AI w operacjach sieciowych jest zbyt ogólna, by można było na nich polegać w praktyce. Użyteczna wersja jest węższa: niewielka liczba zadań, w których model rzeczywiście robi coś, czego nie potrafi prosty próg. Cztery z nich sprawdzają się w sieciach dużych centrów danych, a każde z nich opisano tu pod kątem tego, co robi, czego wymaga i co zmienia dla operatora na zmianie.
Cztery zadania warte automatyzacji
Wykrywanie anomalii w zachowaniu interfejsów i ruchu sieciowego
Problem. Statyczne progi ustawia się na najgorszy scenariusz, przez co umykają im ciche degradacje: łącze zaczynające tracić ułamek procenta pakietów, interfejs, w którym powoli rośnie liczba błędów CRC, wzorzec ruchu zmieniający się na wiele godzin przed pierwszym zgłoszeniem.
Co robi platforma. Platforma z czasem uczy się normalnego zakresu wartości dla każdego interfejsu, łącza i urządzenia, w tym dobowego i tygodniowego kształtu ruchu, a następnie oznacza odchylenie od tej linii bazowej, a nie od stałej liczby. Kandydatami do wyznaczania linii bazowej są między innymi wykorzystanie pasma, przepustowość, opóźnienie, jitter, utrata pakietów, błędy interfejsów i tłumienie optyczne.
Co się zmienia. Degradujący się moduł optyczny lub niestabilny port zostaje zidentyfikowany, gdy jest to jeszcze problem wydajnościowy, a nie dopiero wtedy, gdy staje się przestojem.
Korelacja alertów między urządzeniami, warstwami i domenami
Problem. Jedna awaria wyżej w łańcuchu generuje alerty ze wszystkich urządzeń znajdujących się za nią. W dużym środowisku oznacza to setki powiadomień dla jednej przyczyny, a pierwszym zadaniem operatora staje się sortowanie, a nie naprawa.
Co robi platforma. Zdarzenia z pułapek SNMP, syslogu i alertów progowych są grupowane na podstawie topologii sieci i czasu wystąpienia: które urządzenia znajdują się za uszkodzonym łączem, które alerty pojawiły się w tym samym oknie czasowym, które mają wspólną zależność w mapie L2/L3. Powiązane zdarzenia łączą się w jeden incydent z prawdopodobnym źródłem na górze listy.
Co się zmienia. Mniej, ale większych incydentów zamiast zalewu objawów oraz punkt wyjścia, który już wskazuje prawdopodobne źródło.
Prognozowanie trendów pojemności dla łączy i urządzeń
Problem. Decyzje dotyczące pojemności często zapadają dopiero po tym, jak łącze osiągnie nasycenie w szczycie ruchu — czyli w najbardziej kosztownym momencie na odkrycie tego problemu.
Co robi platforma. Historyczne wykorzystanie każdego interfejsu i urządzenia jest ekstrapolowane w oparciu o jego własną krzywą wzrostu, dzięki czemu pytanie zmienia się z „co jest obecnie obciążone” na „które łącza pierwsze osiągną swój limit i kiedy”. Ta sama metoda ma zastosowanie do limitów zasobów urządzeń, takich jak liczba portów, rozmiary tablic i zapas przepustowości.
Co się zmienia. Modernizacje planuje się względem konkretnej daty, a nie incydentu, a najbardziej obciążone ścieżki otrzymują uwagę, zanim staną się przyczyną niepowodzenia zadania.
Automatyczne wskazówki dotyczące przyczyny źródłowej
Problem. Analiza przyczyn źródłowych w dużej sieci to głównie zbieranie dowodów: pobieranie liczników interfejsów, sprawdzanie ostatnich zmian, porównywanie czasu wystąpienia z innymi warstwami. Jest to powolne i za każdym razem powtarzane w ten sam sposób dla każdego incydentu.
Co robi platforma. Gdy otwiera się incydent, platforma zbiera dowody, które inżynier musiałby zgromadzić ręcznie: ścieżkę topologii, liczniki interfejsów i błędów w oknie czasowym zdarzenia, skorelowane zdarzenia z sąsiednich urządzeń, ostatnie zmiany konfiguracji oraz kondycję sprzętową zaangażowanych urządzeń. Prezentuje najbardziej prawdopodobną przyczynę wraz z danymi, które ją potwierdzają.
Co się zmienia. Wskazówka jest skrótem, a nie wyrokiem. Inżynier nadal ją weryfikuje, ale zaczyna od zebranych dowodów, a nie od pustego terminala.
Co musi być gotowe wcześniej
Te przypadki użycia zawodzą znacznie częściej z powodów związanych z danymi niż z modelem. Poniższa lista to praktyczne wymagania wstępne.
Dokładna topologia, ponieważ korelacja i wskazówki dotyczące przyczyny źródłowej są tak dobre, jak stojąca za nimi mapa zależności
Wystarczająco długa historia do zbudowania linii bazowej, ponieważ wykrywanie anomalii musi wiedzieć, jak wyglądała normalność dla tego konkretnego łącza, a nie dla łącza uogólnionego
Znormalizowane zdarzenia ze sprzętu wielu producentów, dzięki czemu ten sam stan zgłaszany przez dwóch producentów jest traktowany jako ten sam stan
Telemetria warstwy sprzętowej obok widoku sieciowego, ponieważ przełącznik z uszkodzonym zasilaczem i przeciążone łącze uplink różnią się w licznikach, a wyglądają identycznie w zgłoszeniu
Jasno określona granica automatyzacji: na co platforma może reagować samodzielnie, co może jedynie rekomendować, a co jest rejestrowane do celów audytowych
Warstwy stojące za tymi przypadkami użycia
Monitoring sieci dostarcza surowy materiał: przełączniki, routery, zapory sieciowe, load balancery i przełączniki Fibre Channel; wykorzystanie pasma, przepustowość, opóźnienie, jitter i utratę pakietów; stan portów, błędy interfejsów, błędy CRC i tłumienie optyczne; topologię L2 i L3 z zależnościami między urządzeniami; a także pułapki SNMP, syslog i zdarzenia progowe skorelowane w celu redukcji szumu.
SmartBSM to warstwa, która działa na tych danych: inteligentna korelacja alertów i redukcja szumu, identyfikacja przyczyny źródłowej, korelacja incydentów, planowanie i prognozowanie pojemności oraz automatyczne generowanie topologii usług, które mapuje, jakie usługi biznesowe zależą od dotkniętej ścieżki.
Operacje AI obejmują część międzywarstwową, w której zdarzenie sieciowe jest odczytywane razem z sygnałami sprzętowymi, pamięci masowej i aplikacyjnymi — dzięki temu problem, który wygląda na przeciążenie, można prześledzić aż do faktycznie uszkodzonego komponentu.
Wiarygodne źródła
Najczęstsze pytania o AI w operacjach sieciowych
Jakie są główne zastosowania AI w operacjach sieciowych dużych centrów danych?
Konsekwentnie pojawiają się cztery: wykrywanie anomalii względem wyuczonych linii bazowych zamiast stałych progów, korelacja alertów grupująca objawy jednej przyczyny w pojedynczy incydent, prognozowanie trendów pojemności ekstrapolujące wykorzystanie poszczególnych interfejsów oraz automatyczne wskazówki dotyczące przyczyny źródłowej, które zbierają dowody, jakie inżynier musiałby zgromadzić ręcznie.
Czym wykrywanie anomalii oparte na AI różni się od alertowania progowego?
Alert progowy uruchamia się, gdy wartość przekroczy granicę ustaloną wcześniej przez człowieka, zwykle na tyle wysoką, by uniknąć fałszywych alarmów, przez co powolne degradacje pozostają poniżej niej niezauważone. Wykrywanie oparte na linii bazowej uczy się normalnego zakresu i dobowego kształtu dla każdego interfejsu lub urządzenia i oznacza odchylenie od tego wzorca, dzięki czemu łącze zachowujące się nietypowo dla samego siebie zostaje wykryte, nawet gdy jego wartości bezwzględne wyglądają akceptowalnie.
Czy korelacja alertów zmniejsza ich liczbę, czy tylko je grupuje?
Grupuje je, co właśnie zmniejsza obciążenie pracą operatora. Zdarzenia źródłowe są zachowywane, ponieważ inżynierowie nadal potrzebują dowodów z poszczególnych urządzeń podczas diagnozowania. Zmienia się to, że jedna przyczyna źródłowa generuje jeden incydent do obsłużenia zamiast dziesiątek osobnych powiadomień.
Czego potrzebuje platforma operacji sieciowych, zanim funkcje AI staną się użyteczne?
Dokładnej topologii, wystarczającej ilości danych historycznych do wyznaczenia linii bazowych, znormalizowanych zdarzeń ze sprzętu wielu producentów oraz telemetrii warstwy sprzętowej obok widoku sieciowego. Bez tego model koreluje niepełne dane, a jego wnioski dziedziczą te braki.
Czy operacje sterowane przez AI powinny automatycznie reagować na awarie sieciowe?
To decyzja organizacyjna, a nie techniczna. Powszechnym podejściem jest pozwolenie platformie na wykrywanie, korelowanie i rekomendowanie, podczas gdy każda zmiana w działającej sieci przechodzi przez proces zatwierdzania i zarządzania zmianą organizacji, a działanie jest rejestrowane do celów audytowych.
Które produkty Sensaka obejmują operacje sieciowe wspierane przez AI?
Monitoring sieci zapewnia warstwę urządzeń, interfejsów, topologii i zdarzeń. SmartBSM dodaje na tej podstawie inteligentną korelację alertów, analizę przyczyn źródłowych, analizę pojemności i mapowanie usług biznesowych, a strona dotycząca operacji AI opisuje, jak korelacja międzywarstwowa łączy zdarzenia sieciowe z kontekstem sprzętowym, pamięci masowej i aplikacyjnym.