Awaria w sieci rozległej jest rozumiana jako
A. przerwanie możliwości realizowania spoczywających na urządzeniu funkcji w wyniku przekroczenia dopuszczalnej stopy błędów blokowych.
B. chwilowe pogorszenie jakości transmisji, które nie ma natychmiastowego negatywnego wpływu na jej pracę.
C. niesprawność urządzeń lub sieci, całkowicie uniemożliwiającą jej prawidłowe funkcjonowanie.
D. najdrobniejsze choćby stany niezgodności urządzenia lub sieci w stosunku do stanu oczekiwanego.
Pytanie z egzaminu CKE, styczeń 2022 (arkusz EE.20-SG-22.01).
W tym pytaniu chodzi o klasyczne, podręcznikowe rozumienie pojęcia „awaria” w sieci rozległej (WAN). Poprawna odpowiedź opisuje sytuację, w której następuje niesprawność urządzeń lub samej sieci, tak duża, że całkowicie uniemożliwia jej prawidłowe funkcjonowanie. Czyli nie mówimy o lekkim spadku jakości, tylko o stanie, w którym usługa przestaje działać zgodnie z przeznaczeniem. W praktyce: router przestaje routować pakiety, łącze jest fizycznie zerwane, uszkodzony jest moduł optyczny albo padł zasilacz w urządzeniu brzegowym. Z punktu widzenia użytkownika – nie da się zestawić połączenia, transmisja nie dochodzi, usługi sieciowe są niedostępne. Tak to jest definiowane w dokumentacji SLA, ITIL czy w standardach eksploatacji infrastruktury operatorskiej.
Moim zdaniem warto zapamiętać, że awaria to stan „binaryjny”: albo system świadczy usługę w wymaganym minimalnym zakresie, albo nie. Jeśli nie – mamy awarię. W sieciach WAN operatorzy często rozróżniają awarie krytyczne (np. pad głównego łącza między miastami) od incydentów o mniejszym znaczeniu, ale wspólnym mianownikiem jest właśnie całkowite lub prawie całkowite uniemożliwienie prawidłowej pracy. Dobre praktyki (np. ITIL, ISO/IEC 20000) mówią, że awarie wymagają natychmiastowej reakcji, procedur eskalacji, przełączenia na łącza zapasowe, aktywacji mechanizmów redundancyjnych (HSRP, VRRP, BGP failover). W realnych wdrożeniach WAN administratorzy projektują sieć tak, żeby pojedyncza awaria urządzenia lub łącza nie zatrzymała całkowicie ruchu – stąd stosowanie nadmiarowych tras, ringów MPLS, mechanizmów FRR. Ale definicyjnie, jeśli ta nadmiarowość nie zadziała i usługa przestaje funkcjonować, mówimy o awarii w pełnym znaczeniu tego słowa.
Moim zdaniem warto zapamiętać, że awaria to stan „binaryjny”: albo system świadczy usługę w wymaganym minimalnym zakresie, albo nie. Jeśli nie – mamy awarię. W sieciach WAN operatorzy często rozróżniają awarie krytyczne (np. pad głównego łącza między miastami) od incydentów o mniejszym znaczeniu, ale wspólnym mianownikiem jest właśnie całkowite lub prawie całkowite uniemożliwienie prawidłowej pracy. Dobre praktyki (np. ITIL, ISO/IEC 20000) mówią, że awarie wymagają natychmiastowej reakcji, procedur eskalacji, przełączenia na łącza zapasowe, aktywacji mechanizmów redundancyjnych (HSRP, VRRP, BGP failover). W realnych wdrożeniach WAN administratorzy projektują sieć tak, żeby pojedyncza awaria urządzenia lub łącza nie zatrzymała całkowicie ruchu – stąd stosowanie nadmiarowych tras, ringów MPLS, mechanizmów FRR. Ale definicyjnie, jeśli ta nadmiarowość nie zadziała i usługa przestaje funkcjonować, mówimy o awarii w pełnym znaczeniu tego słowa.
W sieciach rozległych bardzo łatwo pomylić różne typy problemów z pojęciem awarii, bo w praktyce użytkownik widzi tylko jedno: „coś nie działa tak, jak powinno”. Z technicznego punktu widzenia awaria to jednak dość precyzyjne określenie. Chodzi o taki stan urządzenia lub sieci, w którym realizacja podstawowych funkcji jest całkowicie uniemożliwiona. Czyli transmisja nie może być wykonana zgodnie z założeniami, usługa przestaje być dostępna, a nie tylko działa gorzej. Tak to jest ujmowane w dokumentacji operatorów, w umowach SLA i w podejściach typu ITIL czy normach dotyczących zarządzania usługami.
Częsty błąd myślowy polega na uznawaniu za awarię absolutnie każdej, nawet minimalnej niezgodności ze stanem idealnym. W praktyce sieć komputerowa nigdy nie jest idealna: zawsze występuje pewien poziom błędów, opóźnień, retransmisji czy fluktuacji przepustowości. Standardy telekomunikacyjne (np. ITU-T) dopuszczają określone wartości parametrów jakościowych, jak stopa błędów, jitter, opóźnienie. Dopiero przekroczenie progów krytycznych i utrata zdolności do świadczenia usługi można traktować jako awarię. Dlatego utożsamianie „najdrobniejszych niezgodności” z awarią jest po prostu zbyt skrajne i niepraktyczne w utrzymaniu sieci.
Inny typ nieporozumienia to traktowanie krótkotrwałego pogorszenia jakości transmisji jako awarii. Chwilowy wzrost opóźnienia, sporadyczny packet loss czy przejściowe zakłócenia to z reguły zjawiska klasyfikowane jako degradacja jakości lub incydent wydajnościowy. Dobre praktyki mówią tu o monitoringu QoS, alarmach progowych, ale nie o awarii w sensie „system przestał działać”. Takie zjawiska są ważne, bo mogą zapowiadać przyszłe problemy, jednak nie spełniają definicji całkowitego uniemożliwienia prawidłowej pracy sieci.
Pojawia się też wątek stopy błędów blokowych. Faktycznie, w standardach transmisyjnych określa się dopuszczalne wartości BER czy BLER i zbyt wysoka wartość może oznaczać, że kanał jest praktycznie bezużyteczny. Jednak w samej definicji awarii sieci WAN najczęściej nie ogranicza się jej tylko do przekroczenia jednego parametru jakościowego. Awaria to szersze pojęcie: dowolna niesprawność urządzeń lub sieci, która powoduje, że system nie może realizować swoich funkcji. Przekroczenie dopuszczalnej stopy błędów może być jednym z mechanizmów prowadzących do awarii, ale nie jedyną i nie koniecznie definicyjną cechą. Z mojego doświadczenia lepiej patrzeć na to praktycznie: jeśli użytkownik nie może korzystać z usługi, a sieć nie jest w stanie zapewnić wymaganej łączności mimo poprawnej konfiguracji po jego stronie, wtedy mówimy o awarii, a nie tylko o chwilowym czy parametrycznym odchyleniu.
Częsty błąd myślowy polega na uznawaniu za awarię absolutnie każdej, nawet minimalnej niezgodności ze stanem idealnym. W praktyce sieć komputerowa nigdy nie jest idealna: zawsze występuje pewien poziom błędów, opóźnień, retransmisji czy fluktuacji przepustowości. Standardy telekomunikacyjne (np. ITU-T) dopuszczają określone wartości parametrów jakościowych, jak stopa błędów, jitter, opóźnienie. Dopiero przekroczenie progów krytycznych i utrata zdolności do świadczenia usługi można traktować jako awarię. Dlatego utożsamianie „najdrobniejszych niezgodności” z awarią jest po prostu zbyt skrajne i niepraktyczne w utrzymaniu sieci.
Inny typ nieporozumienia to traktowanie krótkotrwałego pogorszenia jakości transmisji jako awarii. Chwilowy wzrost opóźnienia, sporadyczny packet loss czy przejściowe zakłócenia to z reguły zjawiska klasyfikowane jako degradacja jakości lub incydent wydajnościowy. Dobre praktyki mówią tu o monitoringu QoS, alarmach progowych, ale nie o awarii w sensie „system przestał działać”. Takie zjawiska są ważne, bo mogą zapowiadać przyszłe problemy, jednak nie spełniają definicji całkowitego uniemożliwienia prawidłowej pracy sieci.
Pojawia się też wątek stopy błędów blokowych. Faktycznie, w standardach transmisyjnych określa się dopuszczalne wartości BER czy BLER i zbyt wysoka wartość może oznaczać, że kanał jest praktycznie bezużyteczny. Jednak w samej definicji awarii sieci WAN najczęściej nie ogranicza się jej tylko do przekroczenia jednego parametru jakościowego. Awaria to szersze pojęcie: dowolna niesprawność urządzeń lub sieci, która powoduje, że system nie może realizować swoich funkcji. Przekroczenie dopuszczalnej stopy błędów może być jednym z mechanizmów prowadzących do awarii, ale nie jedyną i nie koniecznie definicyjną cechą. Z mojego doświadczenia lepiej patrzeć na to praktycznie: jeśli użytkownik nie może korzystać z usługi, a sieć nie jest w stanie zapewnić wymaganej łączności mimo poprawnej konfiguracji po jego stronie, wtedy mówimy o awarii, a nie tylko o chwilowym czy parametrycznym odchyleniu.