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.
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.