Awaria

Awaria (ang. failure, w kontekście usług outage) to stan, w którym system, usługa albo urządzenie przestaje działać tak, że nie da się pracować. W rozmowie słowo znaczy tyle co „nie działa". W umowie utrzymaniowej znaczy więcej: to klasa dotkliwości incydentu z własną definicją zdarzenia, własnymi zegarami i konsekwencją finansową, rozliczana według SLA. Dopóki umowa nie mówi, co jest awarią, spór o to zaczyna się przy każdym zgłoszeniu.

Żeby nie mylić czterech słów, wystarczy jedno zdanie: defekt siedzi w produkcie, incydent jest pojedynczym zdarzeniem w usłudze, problem to dochodzenie w sprawie przyczyny, a awaria to etykieta z umowy naklejona na incydent, który zatrzymał pracę. Tabelę porównawczą tych pojęć masz przy haśle incydent. Tu zajmujemy się tym, co ta etykieta zmienia w pracy analityka.

Częsta pomyłka: uznanie, że „awaria" w umowie i „awaria" w rozmowie z użytkownikiem to to samo. Użytkownik mówi „mamy awarię", bo nie może wydrukować dokumentu. Umowa mówi „awaria", gdy proces biznesowy stoi i nie ma obejścia. Między jednym a drugim leży kategoryzacja zgłoszenia, czyli ktoś sprawdza definicję i nadaje priorytet, zanim padnie słowo, które uruchamia zegar kary.

Awaria, usterka, przestój, outage - jak to nazywać po polsku i po angielsku?

Słowo	Kto go używa	Co oznacza
awaria	prawnicy i zakupy przy umowie utrzymaniowej, strona statusu dla klientów, negocjacje z dostawcą	zdarzenie zatrzymujące pracę; w umowie klasa dotkliwości z zegarami i karą
usterka	umowa, protokół odbioru	coś działa źle, ale proces idzie dalej
przestój	raport miesięczny, rozmowa z biznesem	liczba minut albo godzin bez usługi; wchodzi do raportu dostępności
outage	żargon utrzymania, statusy dostawców chmury	niedostępność usługi; najbliższy angielski odpowiednik „awarii"
failure	dokumentacja techniczna, analiza ryzyka	zawiedzenie elementu: serwera, dysku, integracji; niekoniecznie widoczne dla użytkownika
breakdown	maszyny, linie produkcyjne	awaria fizyczna, poza IT

Najwięcej kłopotu robi para awaria i usterka, bo w polskich umowach utrzymaniowych to często dwie z trzech klas zgłoszeń (awaria, błąd, usterka), a każda ma inne czasy i inną karę. Nazwy wędrują z umowy do umowy, a definicje za każdym razem pisze się od nowa. Przy czytaniu cudzej umowy słowo „awaria" bez definicji zdarzenia traktuj jak puste pole.

Czym awaria różni się od incydentu?

W usługach IT awaria to węższe pojęcie. Każda awaria jest incydentem, ale incydentem bywa też spowolnienie, które nikogo nie zatrzymało. Incydent to zdarzenie w usłudze, zarejestrowane i zaopatrzone w priorytet. Awaria to jego etykieta w umowie, zwykle dla przypadków, w których usługa jest niedostępna albo proces biznesowy stoi bez obejścia.

Prosty test, czy zgłoszenie jest awarią w sensie umowy, to trzy pytania zadane po kolei.

1. Czy proces biznesowy stoi, czy tylko idzie wolniej? Portal rejestracji nie odpowiada w żadnej placówce to co innego niż portal wolny w jednej.
2. Czy istnieje obejście? Jeśli rejestracja przez telefon działa, obejście istnieje i według tabeli priorytetów przy haśle SLA to nie jest jedynka.
3. Czy umowa nazywa to zdarzenie awarią? Nazwa musi stać przy definicji zdarzenia; sama etykieta „awaria" w spisie treści umowy nie rozstrzyga niczego.

W MediFlow, naszym case'ie rejestracji online dla sieci przychodni, model wsparcia rozpisany przy haśle ITIL mówi wprost: awaria portalu to incydent krytyczny, zdefiniowany jako „nie można rezerwować w żadnej placówce", z reakcją 30 minut i obejściem 4 godziny. Nocne zrywanie sesji, choć uciążliwe, awarią nie było: szło jako problem do analizy przyczyny.

Co umowa musi powiedzieć o awarii, żeby to słowo coś znaczyło?

Pięć rzeczy. Bloki umowy SLA rozpisujemy przy haśle SLA, tu tylko to, co dotyczy samej awarii.

• Definicja zdarzenia. Opis, który da się sprawdzić: które funkcje, dla ilu użytkowników, w jakich godzinach. Zdanie „nie można rezerwować w żadnej placówce" da się sprawdzić sondą; zdanie „system działa nieprawidłowo" otwiera dyskusję przy każdym zgłoszeniu.
• Zegary. Dla awarii z reguły dwa, liczone osobno: czas reakcji i czas obejścia. Termin usunięcia przyczyny to zwykle osobny zapis, bo po przywróceniu pracy sprawa idzie dalej jako problem. Trzy zegary i to, co je pauzuje, opisujemy przy haśle SLA.
• Wyłączenia. Okno serwisowe, siła wyższa i awaria po stronie klienta nie liczą się do statystyki dostawcy. Ten ostatni zapis jest najczęstszym polem sporu: gdy pada łącze przychodni, a nie serwer dostawcy, zegar dostawcy nie biegnie, choć rejestratorka nie może pracować.
• Pomiar. Kto stwierdza awarię i czym. Przy MediFlow to sonda zewnętrzna co 60 sekund. Bez punktu pomiaru każda awaria zaczyna się od pytania, o której naprawdę się zaczęła.
• Konsekwencja. Kara, jej podstawa i górny limit. Przy awarii liczy się jeszcze jedno: czy kara idzie za przekroczenie zegara przy pojedynczym zdarzeniu, czy za dostępność poniżej progu w skali miesiąca. O tym, dlaczego ten limit zwykle nie pokrywa strat z postoju, piszemy przy haśle SLA.

Do tego jedno zdanie o komunikacji: kto, kiedy i jakim kanałem informuje użytkowników, że awaria trwa. Bez komunikatu użytkownicy zgłaszają tę samą awarię po raz drugi, każdy osobno.

Co robi analityk biznesowy w sprawie awarii?

Analityk awarii nie usuwa. Robi cztery rzeczy, które bez niego się nie wydarzą, i robi je przed pierwszą awarią, bo potem nie ma na to czasu. Na prelekcji o zarządzaniu czasem (Patrycja Sitkowska, 14 lipca 2025) macierz Eisenhowera dostała przykłady z tego samego biurka: pilne i ważne to awaria systemu, ważne i niepilne to analiza wymagań do nowego modułu. Cztery punkty niżej należą do drugiego kwadrantu.

Pisze, ile awarii biznes wytrzyma. To jest wymaganie niefunkcjonalne i musi mieć liczbę. We wpisie o wymaganiach niefunkcjonalnych przykład dla systemu rejestracji w przychodniach brzmi: czas przywrócenia działania po awarii (MTTR) nie dłuższy niż 30 minut oraz „żadne potwierdzone zamówienie wizyty nie ginie w przypadku awarii serwera". Pierwsze zdanie to mierzalny próg niezawodności, drugie to trwałość transakcji. Oba da się sprawdzić, więc oba nadają się do umowy.

Rysuje, co pada razem z czym. W lekcji o diagramie wdrożenia z naszego kursu o podstawach UML jest praktyczna miara: jeśli w wymaganiach pojawiają się słowa „dostępność", „czas odpowiedzi", „lokalizacja danych", „awaria", diagram wdrożenia powinien leżeć na stole. Tam też jest scena, w której jedna ścieżka komunikacji na rysunku zamyka godzinną dyskusję: portal pacjenta łączy się z serwerem produkcyjnym przez internet, z pominięciem sieci lokalnej przychodni, więc awaria internetu przy Polnej odcina komputer rejestratorki, ale pacjenci w domach umawiają się dalej. Tej wiedzy potrzebujesz, żeby odróżnić awarię od awarii po stronie klienta.

Pisze ścieżki awarii, zanim ktoś je przejdzie. W tekście o przypadkach użycia każdy krok scenariusza głównego przechodzi trzy pytania: inne działanie aktora, złe dane, awaria. Odpowiedzi trafiają do rozszerzeń, bo tam biznes odpowiada na pytania przed developmentem, a nie po awarii. Ten sam brak nazywamy w tekście o specyfikacji wymagań pomijaniem ścieżek błędów: specyfikacja opisuje, co się dzieje, gdy wszystko idzie dobrze, i milczy o tym, co przy awarii. W lekcji o diagramie sekwencji z tego samego kursu UML zasada brzmi: przebieg główny na jednym rysunku, „slot zajęty" na drugim, awaria płatności na trzecim.

Czwarta rzecz to liczenie awarii jak danych. W kursie wprowadzającym do analizy biznesowej jest historia Kasi, która z dwutygodniowych notatek o zgłoszeniach robi jednostronicowe zestawienie: typy zgłoszeń według częstości, średni czas zamknięcia każdego typu, rozkład według biurowców. Wniosek wychodzi sam: jeden typ zgłoszeń, awarie sprzętu czyszczącego, odpowiada za większość czasu obsługi i koncentruje się w dwóch lokalizacjach. Z tego wynika propozycja: harmonogram serwisu prewencyjnego w dwóch biurach i prosta instrukcja pierwszej reakcji dla ekip. Całe zestawienie powstaje w arkuszu kalkulacyjnym.

Jak traktować awarię, zanim nastąpi?

Jako ryzyko. W lekcji o zarządzaniu ryzykiem w kontekście procesowym z kursu o architekturze procesów biznesowych ryzyka operacyjne obejmują błędy ludzkie, awarie systemów oraz zależności zewnętrzne, a przy ocenie zagrożeń liczą się dwa czynniki: prawdopodobieństwo i wpływ. Ta sama lekcja każe zagospodarować także ryzyka o niskim prawdopodobieństwie, po których „firma idzie z dymem", i dać każdemu konkretnego właściciela, nierzadko innego niż właściciel procesu. Miejsce na to jest w rejestrze ryzyk. Do systematycznego wyliczania potencjalnych awarii służy FMEA (Failure Mode and Effects Analysis): w naszym próbnym egzaminie CBAP wyjaśnienie jednej z odpowiedzi opisuje ją jako metodę identyfikacji potencjalnych awarii, ich przyczyn i skutków. Dla analityka to pytanie „co może paść, dlaczego i co wtedy widzi użytkownik" zadane przy każdym elemencie diagramu wdrożenia.

Druga część to plan na czas, gdy awaria już trwa. SLA mówi, jak szybko dostawca wróci z awarią; business continuity i disaster recovery mówią, co firma robi w tym czasie i ile danych może stracić. W MediFlow biznes ustalił RTO 4 godziny i RPO 15 minut, a przychodnie na czas awarii przechodzą na zapisy telefoniczne i papierową listę przyjęć, którą system drukuje każdego wieczora właśnie na tę okoliczność. Te dwie liczby wyciąga od interesariuszy analityk, pytaniami „ile godzin bez systemu firma wytrzyma" i „ile danych możemy stracić". Bez nich IT albo przepłaci, albo zbuduje coś, co przy pierwszej awarii położy biznes.

Czy awaria to tylko sprawa IT?

Słowo pada też poza serwerownią. Dwa przykłady z naszych materiałów.

Linia produkcyjna. W lekcji o zarządzaniu współpracą z kursu wprowadzającego jest ćwiczenie z planem komunikacji kryzysowej dla LogiPak, producenta opakowań metalowych: w zakładzie doszło do poważnej awarii linii, w której ucierpiało dwóch pracowników, a firma musi spójnie skomunikować się z pracownikami, rodzinami poszkodowanych, mediami, klientami i inwestorami. Wzorcowa odpowiedź stawia jednego rzecznika i pierwszy komunikat do pracowników w dwie godziny. Rola analityka kończy się na tabeli komunikacji; naprawą linii zajmuje się utrzymanie ruchu.

Sprzęt w biurowcach. Historia Kasi z sekcji wyżej dzieje się w firmie obsługującej biurowce: awarie sprzętu czyszczącego, dwie lokalizacje, harmonogram serwisu prewencyjnego. W wymaganiach interesariuszy, które Kasia spisuje, ekipy chcą jasnej procedury, kogo wzywać, a najemcy krótszego czasu reakcji.

Co mówi nasz job board?

Odczyt z 5 września 2026: 241 aktywnych ofert dla analityków. Rdzeń „awar" (awaria, awaryjny, awaryjne) daje zero trafień. „Incydent" i „incident" zero, ITIL jedna, SLA jako osobne słowo zero. „Wsparcie" albo „support" stoi w 21 ofertach, „utrzymanie" albo „maintenance" w dwóch, BPMN dla porównania w 29. Agregator przechowuje wyłącznie zajawki ofert, więc liczby pochodzą z nagłówków i zajawek.

Wniosek jak przy hasłach SLA i incydent: obsługa awarii siedzi w pisaniu wymagań utrzymaniowych i czytaniu umów, a te w ogłoszeniach rzadko dostają własne słowo. Żywe liczby z rynku masz w Barometrze rynku BA.

Najczęstsze pytania

Czy każda awaria oznacza karę dla dostawcy?

Zależy od zapisu o konsekwencjach. W przykładzie MediFlow kara liczy się od dostępności w miesiącu poniżej progu, więc pojedyncza awaria obsłużona w czasie z umowy sama z siebie kary nie uruchamia. W innych umowach karę nalicza się za każdą rozpoczętą godzinę przekroczenia zegara obejścia. Podstawę naliczenia i górny limit trzeba przeczytać w sekcji konsekwencji, razem z wyłączeniami.

Czy każda niedostępność systemu to awaria?

Awarią w sensie umowy jest tylko ta niedostępność, która mieści się w definicji zdarzenia i nie łapie się na żadne wyłączenie. Okno serwisowe zaplanowane i ogłoszone z wyprzedzeniem zostaje poza statystyką. Niedostępność spowodowana przez łącze klienta to awaria po stronie klienta, również poza statystyką dostawcy.

Co to jest awaria po stronie klienta?

Zdarzenie, którego przyczyna leży w infrastrukturze albo działaniach odbiorcy usługi: łącze, komputer rejestratorki, błędna konfiguracja u klienta. Umowy wyłączają je ze statystyki dostawcy. Taki spór da się rozstrzygnąć w minutę, jeśli granica „to nasze, to wasze" jest narysowana na diagramie wdrożenia.

Czym awaria różni się od usterki?

Skalą skutku. Usterka to coś, co działa źle, ale proces idzie dalej; awaria zatrzymuje pracę. W umowach obie mają osobne czasy i osobne kary, a o tym, do której klasy trafia zgłoszenie, rozstrzyga definicja zdarzenia zapisana w umowie.

Co to jest MTTR i MTBF?

MTTR to średni czas naprawy, czyli średni czas przywrócenia działania po awarii, a MTBF to średni czas między awariami. Oba są wskaźnikami niezawodności z wpisu o wymaganiach niefunkcjonalnych i oba są średnimi z okresu: w umowie mierzą jakość utrzymania w miesiącu, a nie termin dla jednego zgłoszenia. Termin dla pojedynczej awarii określa czas obejścia.

Sprawdź, czy umiesz to zastosować

Dwa krótkie quizy, oba bez konta: diagram wdrożenia, 10 pytań o węzły, artefakty i rolę tego diagramu w planowaniu wdrożeń, oraz zarządzanie ryzykiem w kontekście procesowym, 10 pytań, w tym o to, co znaczy, że każde ryzyko musi mieć konkretnego właściciela.

Historia Kasi i ćwiczenie z komunikacją kryzysową dla LogiPak są w kursie wprowadzającym do analizy biznesowej. Program zobaczysz bez logowania; darmowe konto otwiera pierwszą lekcję kursu, te dwie siedzą w płatnej części. Te same quizy masz też na platformie po założeniu darmowego konta: wynik zostaje w historii podejść, konto bez subskrypcji ma trzy podejścia do testów w miesiącu.

Gdzie iść dalej

• Incydent - zdarzenie, na które umowa nakleja etykietę „awaria"; tabela czterech pojęć
• SLA - bloki umowy, trzy zegary, tabela priorytetów i to, czego SLA nie załatwi
• ITIL - trzy ścieżki zgłoszeń w MediFlow: incydent, problem, wniosek o zmianę
• Defekt - to, co bywa przyczyną awarii i żyje dłużej niż ona
• Wymaganie niefunkcjonalne - miejsce na dostępność, MTTR i trwałość transakcji
• Diagram wdrożenia - rysunek, z którego czyta się, co pada razem z czym
• Business continuity i disaster recovery - co firma robi, gdy awaria trwa dłużej niż obejście
• Eskalacja - co zrobić, gdy awaria stoi mimo umowy

Definicja incydentu krytycznego i model wsparcia MediFlow pochodzą z naszych haseł SLA i ITIL, rozgraniczenie czterech pojęć z haseł defekt i incydent, RTO i RPO z haseł disaster recovery i business continuity. Przykłady wymagań o awarii z wpisu o wymaganiach niefunkcjonalnych, ścieżki błędów z wpisów o przypadkach użycia i specyfikacji wymagań. Scena z awarią internetu i praktyczna miara z lekcji o diagramie wdrożenia, zasada trzech rysunków z lekcji o diagramie sekwencji (kurs „Podstawy UML"). Historia Kasi i ćwiczenie LogiPak z kursu „Wprowadzenie do analizy biznesowej", klasyfikacja ryzyk z kursu „Architektura procesów biznesowych". Macierz Eisenhowera z prelekcji Patrycji Sitkowskiej (14 lipca 2025), opis FMEA z wyjaśnienia odpowiedzi w naszym próbnym egzaminie CBAP. Liczby z job boardu policzone 5 września 2026 na 241 aktywnych ofertach, po rdzeniach wyrazów. Podział zgłoszeń na awarię, błąd i usterkę to praktyka polskich umów utrzymaniowych, nie termin z ITIL.