Prawidłowa kolejność poziomów alarmów w typowych urządzeniach cyfrowych sieci rozległych to: Critical, Major, Minor, Warning – od najbardziej krytycznego do najmniej istotnego. Taka hierarchia nie jest przypadkowa, tylko wynika z praktyki eksploatacji sieci i z przyjętych w branży standardów zarządzania, opartych m.in. na modelu FCAPS oraz zaleceniach ITU-T i ogólnie przyjętych zasadach w systemach NMS/EMS. Alarm typu Critical oznacza zwykle całkowitą utratę usługi albo bardzo poważne zagrożenie ciągłości działania, np. brak łączności z głównym routerem brzegowym, uszkodzenie modułu zasilania bez redundancji, awaria łącza szkieletowego w sieci operatora. W praktyce takie zdarzenie wymaga natychmiastowej reakcji, często zgodnie z procedurą „incident management” i z jasno określonym SLA. Major to nadal poważna usterka, ale niekoniecznie pełny blackout – np. awaria jednego z redundantnych interfejsów, mocno podwyższony poziom błędów na łączu, przeciążenie routera rdzeniowego. Usługa jeszcze działa, ale jej jakość jest mocno zagrożona. Minor oznacza problem o mniejszym wpływie na usługę, często częściowy lub lokalny, np. pojedyncze błędy transmisji, brak jednego z dwóch źródeł zasilania przy zachowanej redundancji, sporadyczne restarty interfejsu. To sygnał, że coś warto zaplanować do naprawy, ale nie jest to pożar do gaszenia na już. Warning to najniższy poziom – ostrzeżenia, stany graniczne, np. rosnące wykorzystanie pasma, rosnąca temperatura urządzenia, licznik błędów przekraczający próg ostrzegawczy. Z mojego doświadczenia takie warningi służą głównie do proaktywnego utrzymania sieci – żeby zauważyć trend zanim dojdzie do Major lub Critical. W dobrze skonfigurowanym systemie monitoringu (np. w NMS operatora) priorytetyzacja w tej kolejności pozwala zespołowi utrzymania sieci skupić się najpierw na przywróceniu kluczowych usług, a dopiero potem na optymalizacji i „kosmetyce” parametrów. Moim zdaniem znajomość tej hierarchii jest obowiązkowa dla każdego, kto chce sensownie interpretować alarmy w sieciach WAN i nie gubić się w natłoku zdarzeń.
W cyfrowych sieciach rozległych logika priorytetów alarmów nie jest ustawiona przypadkowo ani „na wyczucie”. Kolejność Critical, Major, Minor, Warning wynika z tego, jaki jest realny wpływ danego zdarzenia na ciągłość i jakość usług oraz z przyjętych w branży zasad zarządzania incydentami. Kiedy ktoś miesza tę kolejność, najczęściej stoi za tym myślenie typu: „to mi się wydaje ważniejsze, więc dam wyżej”, zamiast oparcia się na definicjach stosowanych w systemach NMS/EMS, zgodnych z dobrymi praktykami operatorów i zaleceniami ITU-T czy typowych implementacji FCAPS. Przestawienie Major przed Critical oznacza w praktyce odwrócenie logiki. Critical jest zawsze tym alarmem, który mówi: usługa jest poważnie zagrożona lub już niedostępna. To może być awaria głównego łącza WAN, pad całego węzła, utrata synchronizacji na kluczowym interfejsie. Major to krok niżej – poważny problem, ale jeszcze nie pełny blackout, np. awaria jednego z dwóch redundantnych elementów. Jeśli Major jest ustawiony przed Critical, to w centrum nadzoru sieci (NOC) priorytetyzacja zdarzeń będzie nielogiczna: operator może reagować szybciej na mniej groźne problemy, a poważniejsze zostaną zepchnięte na dalszy plan. Innym typowym błędem jest mieszanie Minor i Warning albo traktowanie Warning jako czegoś „prawie krytycznego”. Warning to z definicji ostrzeżenie – stan, który jeszcze nie narusza parametrów usługi, ale sygnalizuje zbliżanie się do progu, np. rosnące wykorzystanie CPU, temperatura bliska limitu czy opóźnienia na granicy SLA. Minor natomiast oznacza już realny, choć ograniczony wpływ na usługę lub infrastrukturę, który warto naprawić, ale bez paniki. Dodatkowym źródłem zamieszania bywa też zwykła literówka w nazwie poziomu (np. „Worning”), co sugeruje brak obycia z typową terminologią stosowaną w interfejsach zarządzania urządzeniami sieciowymi. Moim zdaniem uporządkowanie tych pojęć jest kluczowe, bo dopiero wtedy dashboardy, raporty i systemy alarmowe zaczynają mieć sens: najpierw gasi się pożary (Critical), potem poważne usterki (Major), później drobne problemy (Minor), a na końcu analizuje ostrzeżenia (Warning) i planuje działania prewencyjne. Bez tej hierarchii łatwo w praktyce albo przepalić zasoby na mało istotne alarmy, albo przegapić realną awarię o dużym zasięgu.