Prawidłowa kolejność alarmów w cyfrowych sieciach rozległych to: Critical, Major, Minor, Warning – od najbardziej krytycznego do najmniej istotnego. Taki podział wynika z ogólnie przyjętych praktyk w zarządzaniu siecią (network management), zarówno w systemach opartych na SNMP, jak i w rozwiązaniach klasy operatorskiej (NOC, SOC). Alarm typu Critical oznacza sytuację, w której usługa jest realnie niedostępna lub poważnie zagrożona: awaria łącza podstawowego, uszkodzenie głównego routera, brak zasilania w kluczowym węźle, utrata synchronizacji na łączu transmisyjnym. W praktyce, przy alarmie Critical administratorzy reagują natychmiast, często w trybie 24/7, bo zwykle jest to zdarzenie wpływające bezpośrednio na klienta lub na całą sieć. Alarm Major to nadal poważny problem, ale zwykle z jakąś formą obejścia lub częściową degradacją, a nie całkowitym brakiem usługi. Przykład: awaria jednego z redundantnych łączy w parze, uszkodzenie jednego z zasilaczy w urządzeniu z podwójnym PSU, przeciążenie interfejsu powodujące zauważalne opóźnienia, ale nie całkowitą utratę ruchu. Z mojego doświadczenia w wielu firmach telco alarmy Major są realizowane w krótkim czasie, ale niekoniecznie „na sygnale” jak Critical. Minor to alarm o mniejszym wpływie na usługę, często związany z degradacją parametrów, która jeszcze nie przekracza progów SLA. Może to być np. pojedynczy błąd CRC na łączu, lekkie przekroczenie temperatury, ale jeszcze poniżej poziomu krytycznego, czy problemy z jednym z wielu portów, które nie są aktualnie używane produkcyjnie. Tego typu alarmy często są planowane do usunięcia w ramach normalnych prac utrzymaniowych. Warning natomiast to ostrzeżenie – sygnał, że coś może się w przyszłości przerodzić w poważniejszy problem, ale na razie nie wpływa istotnie na działanie sieci. To mogą być pierwsze oznaki rosnącego jittera, niewielkie przekroczenie progu wykorzystania pasma, lekko podwyższona temperatura urządzenia czy komunikaty o zbliżającym się końcu żywotności modułu optycznego. W dobrze zorganizowanym NOC alarmy sortuje się właśnie według tej hierarchii, żeby operatorzy najpierw gasili „pożary” (Critical), potem poważne usterki (Major), a na końcu zajmowali się kwestiami prewencyjnymi (Minor, Warning). Taka kolejność jest spójna z dobrą praktyką ITIL/FCAPS, gdzie priorytetyzacja incydentów jest kluczowa dla stabilności sieci.