Odpowiedź.

W historii rozwoju rozproszonych systemów IT kwestie obsługi błędów i scenariuszy awarii przez długi czas pozostawały na drugorzędnych rolach, ustępując miejsca logice biznesowej. Jednak wzrost skali i złożoności infrastruktury z czasem pokazał, że niedopracowane scenariusze obsługi błędów prowadzą do masowych awarii i utraty danych.

Problem polega na tym, że złożone systemy doświadczają wielu typów awarii: od niedostępności poszczególnych usług po niespójność danych lub częściowe awarie kanałów komunikacyjnych. Często klienci pod „awariami” rozumieją tylko oczywiste błędy (na przykład, serwer jest niedostępny), ignorując łańcuchy błędów między usługami lub degradację doświadczeń użytkownika.

Efektywne rozwiązanie opiera się na podejściu systemowym:

Wykrywanie wszystkich możliwych punktów awarii.
Opracowanie wyczerpujących scenariuszy ich wystąpienia wspólnie z architektami, QA, projektantami i inżynierami ds. eksploatacji.
Uzgodnienie zachowań systemu z biznesem (na przykład, czy można opóźnić zamówienia, czy wymagane jest buforowanie operacji).
Wyraźna dokumentacja wszystkich rodzajów komunikatów o błędach i ścieżek obsługi.

Kluczowe cechy:

Obsługa nie tylko awarii krytycznych, ale również miękkich/płynnych (na przykład, tymczasowa niedostępność zewnętrznej usługi).
Włączenie scenariuszy degradacji UI i funkcjonalności.
Rozdzielenie błędów biznesowych i technicznych awarii na wszystkich etapach opracowywania wymagań.

Pytania z pułapką.

Jaka jest różnica między wyjątkiem na poziomie aplikacji a wyjątkiem na poziomie infrastruktury?

Bardzo często kandydaci mylą błędy biznesowe (na przykład, „użytkownik nie znaleziony”) z rzeczywistymi awariami (na przykład, „baza danych niedostępna”). Aplikacja zawsze powinna wyraźnie rozróżniać dwa typy wyjątków i zapewniać różne strategie obsługi (rollback, powiadomienia, alerty).

Jakie scenariusze awarii należy modelować dla wewnętrznego API, jeśli nie jest publiczne?

Scenariusze awarii są istotne dla wszystkich API: nawet jeśli API jest wewnętrzne, awarie są zawsze możliwe (nawet wewnątrz jednego konturu automatyzacji), i należy je wyraźnie modelować, aby sprawnie działać z niedokładnymi/nieobecnymi danymi.

Czy system powinien ukrywać wszystkie błędy przed użytkownikiem dla maksymalnego UX?

Nie, całkowite ukrywanie błędów prowadzi do dezinformacji użytkownika. Ważne jest, aby znaleźć równowagę między informacyjnością (aby użytkownik rozumiał, co robić dalej) a bezpieczeństwem (nie ujawniając szczegółów realizacji).

Typowe błędy i antywzorce

Niekonkretniona obsługa awarii (zostawione na „domyślnych” catchach).
Brak scenariuszy degradacji przy częściowych awariach (na przykład w przypadku mikroserwisów — niedziałająca koszyk całkowicie blokuje realizację zamówienia).
Ignorowanie nagromadzenia „milczących” awarii (brak alertingu/monitorowania w sytuacjach wyjątkowych).

Przykład z życia

Negatywny przypadek: W dużym projekcie e-commerce analityk systemowy pozostawił obsługę wszystkich błędów sieciowych na łasce architektury. Przy awaryjnych aktualizacjach i awarii usługi pocztowej system nie wysyłał powiadomień o zamówieniach, a użytkownicy nie rozumieli, czy ich zamówienia zostały utworzone.

Zalety:

Uproszczenie opisu wymagań.

Wady:

Utrata danych (nie można udowodnić utworzenia zamówienia).
Koszty wsparcia wzrosły po uruchomieniu produktu.

Pozytywny przypadek: Analityk systemowy wraz z architektem zaprojektował osobne scenariusze dla każdej krytycznej usługi: niedostępności kolejki e-mail, awarii bramek płatniczych, degradacji usługi wyszukiwania. Opracowano wiadomości przyjazne użytkownikom dla klientów.