Produkcja leży w tworzeniu aplikacji — co to jest, przyczyny i algorytm działania

Co znaczy „produkcja leży” i jakie są rodzaje awarii

Wyrażenie „produkcja leży” (production is on fire, everything is down) opisuje sytuację, w której środowisko produkcyjne działa nieprawidłowo i dotknęło to użytkowników. Awarie mogą objawiać się jako całkowita niedostępność aplikacji (blank screen, błąd 502), częściowa niedostępność (nie działa moduł płatności, ale pozostałe funkcje są dostępne) lub degradacja wydajności (ekstremalnie długie ładowanie). Severity incydentu określa się procentem dotkniętych użytkowników i czasem trwania awarii.

Według Atlassian Statuspage (2025), średni czas przestoju dla aplikacji mobilnych w 2024 roku wyniósł 27 minut na incydent. Najczęstsze przyczyny: regresja kodu po wdrożeniu (34%), awaria dostawcy chmury (22%), problemy z bazą danych (18%), błędy konfiguracji (15%) i ataki DDoS (11%). Key takeaway: większość awarii jest związana ze zmianami, które zespół sam wprowadził, a nie z czynnikami zewnętrznymi.

Ważne jest rozróżnienie crasha (awarii aplikacji po stronie klienta) i backend outage (niedostępności serwera). Crash zwykle naprawia się hotfixem kodu klienckiego, a backend outage — przez zmiany infrastrukturalne lub redeploy serwisu. Metryki śledzenia: dla klienta — crash-free rate, dla serwera — error rate 5xx i p95 latency. APM (Application Performance Monitoring) — Sentry, New Relic, Datadog — pomaga szybko określić typ awarii.

Poziomy severity incydentów: P0, P1, P2 i kryteria klasyfikacji

Jednolita klasyfikacja severity to podstawa szybkiej reakcji. Bez niej zespół traci czas na dyskusję, „jak pilne to jest”, zamiast działać. Klasyczna skala: P0 (critical) — aplikacja całkowicie niedostępna lub wyciekają dane użytkowników, czas reakcji — natychmiast; P1 (high) — krytyczna funkcjonalność nie działa u 50%+ użytkowników, czas reakcji — 15 minut; P2 (medium) — niekrytyczna funkcjonalność niedostępna u części użytkowników, czas reakcji — 1 godzina.

P0 wymaga natychmiastowej eskalacji: dyżurny inżynier przerywa każdą bieżącą pracę i przełącza się na incydent. Jeśli po 10 minutach problem nie jest rozwiązany — dołącza tech lead. Jeśli po 30 minutach — eskalacja do engineering managera. Dla incydentów P0 dopuszczalne jest naruszanie wszelkich procesów: robienie hotfixa bez pełnego code review, wdrażanie bezpośrednio na produkcję, ignorowanie reguł ochrony gałęzi. Emergency override powinien być wcześniej uzgodniony na poziomie zespołu.

Tabela severity

Niezwykle ważne jest, aby nie pomylić severity w dół. P0 + P1 sklasyfikowane jako P2 prowadzą do opóźnionej reakcji i wydłużenia czasu przestoju. Zasada: jeśli masz wątpliwości — ustaw P0. Over-classification jest lepsza niż under-classification: lepiej zwołać zbędne spotkanie niż stracić godzinę na odtwarzanie.

Pierwsze 10 minut: algorytm działania przy awarii

Timer starts: od momentu, gdy przyszedł alert lub wiadomość od użytkownika. Pierwsze 10 minut — najważniejsze. Algorytm: 1) confirm the issue — upewnij się, że problem jest realny (nie fałszywy alarm); 2) stop the bleeding — natychmiast zmniejsz impact (rollback, feature toggle, blokada endpointu); 3) communicate — napisz na ogólny kanał #incident status: co się stało, severity, co jest robione. Pierwszych 10 minut nie traci się na analizę pierwotnej przyczyny.

Równolegle z zatrzymywaniem krwawienia jeden inżynier rozpoczyna diagnostykę, drugi — komunikację. Kanały komunikacji: Slack #incident channel (dla zespołu), strona statusowa (dla użytkowników), email/SMS eskalacji (dla kierownictwa). Co 15 minut — status update z informacją: co wiadomo, co jest robione, szacowany czas odtworzenia. Status page (StatuPage, Statuspal) wyświetla uptime i historię incydentów dla zewnętrznych użytkowników.

Jak zatrzymać krwawienie: rollback, feature toggle i hotfix

Pierwsza i najważniejsza zasada: nie próbuj naprawiać problemu na produkcji. Jeśli nowa wersja spowodowała awarię — rollback do poprzedniej stabilnej wersji. Jeśli awaria jest spowodowana konkretną funkcją wyłączoną przez feature toggle — po prostu wyłącz toggle. Jeśli ani rollback, ani toggle nie są dostępne — hotfix z minimalnym diffem. Rollback — najbezpieczniejsza opcja, ponieważ wracamy do stanu, który już działał.

Feature toggle (aka feature flag) — potężne narzędzie do stop-the-bleeding bez wdrażania. Jeśli moduł płatności padł, ale jest wyłączony przez toggle — użytkownicy po prostu nie widzą przycisku płatności, a nie dostają ekranu błędu. Toggle nie wymaga budowania bilda, nie wymaga review sklepu, działa w sekundy. Każda krytyczna funkcja powinna być pod feature toggle z możliwością wyłączenia na poziomie serwera (remote config). Feature flag — pierwsza linia obrony.

Jeśli rollback jest niemożliwy (np. z powodu nieodwracalnej migracji BD) i toggle nie jest przewidziany — ostateczność: hotfix z minimalną poprawką. Hotfix tworzy się od ostatniego tagu wydania, zawiera tylko linie niezbędne do usunięcia awarii i przechodzi fast-track wdrożenia (patrz artykuł „Hotfix — pilne poprawki”). Golden rule: po stabilizacji zawsze wykonuj root cause analysis, nawet jeśli wydaje się, że przyczyna jest oczywista.

Diagnostyka przyczyn: logi, metryki i alarmy

Po zatrzymaniu krwawienia (lub równolegle, jeśli pozwala na to liczba inżynierów) rozpoczyna się diagnostyka. Pierwsze źródło — logi. Scentralizowane logowanie (ELK, Grafana Loki, Datadog Logs) pozwala znaleźć błąd po timestampie, ID użytkownika lub ID żądania. Ważne: logi powinny być strukturyzowane (JSON), aby grep działał szybko. Structured logging — obowiązkowy wymóg dla wszystkich serwisów.

Drugie źródło — metryki. Grafana, Datadog, New Relic pokazują, kiedy nastąpił spike błędów, na jakich endpointach, z jakimi kodami statusu. Porównanie metryk przed i po wdrożeniu pomaga zlokalizować problem do konkretnego serwisu lub endpointu. RED metrics (Rate, Errors, Duration) — standard monitorowania mikroserwisów.

Trzecie źródło — distributed tracing. Jaeger, Zipkin, Datadog APM pokazują ścieżkę żądania przez mikroserwisy i identyfikują, gdzie dokładnie wystąpiło opóźnienie lub błąd. Tracing jest szczególnie przydatny przy kaskadowych awariach, gdy błąd w jednym serwisie powoduje błędy we wszystkich zależnych. Trace ID powinien być przekazywany od klienta do wszystkich serwisów backendowych.

# Szybki przykład diagnostyki za pomocą kubectl i logów
# Listuj pody z błędami
kubectl get pods --field-selector=status.phase!=Running

# Sprawdź logi padniętego poda
kubectl logs --previous pod/auth-service-7f4b9c5d6-abc12

# Szukaj błędów w serwisie z ostatnich 30 minut
kubectl logs deployment/api-gateway --since=30m
  | grep "5[0-9][0-9]" | head -50

Ważne: nie próbuj diagnozować przyczyny przed zatrzymaniem krwawienia. Jeśli 50% użytkowników widzi crash — najpierw rollback, potem analiza. Wyjątek: jeśli rollback zająłby więcej czasu niż bezpośredni hotfix (np. przy niezgodności danych). W takim przypadku hotfix stosuje się natychmiast, a post-mortem przeprowadza się po stabilizacji. Diagnosis before fix — niebezpieczny wzorzec wydłużający czas przestoju.

Post-mortem: jak analizować incydenty bez szukania winnych

Post-mortem (zwany również incident review) — strukturyzowana analiza incydentu przeprowadzana 24-72 godziny po jego rozwiązaniu. Cel: zrozumieć, dlaczego doszło do awarii, dlaczego monitoring i testy nie wychwyciły jej przed produkcją i co zmienić w procesach, aby zapobiec powtórce. Blameless culture — fundamentalna zasada: post-mortem omawia procesy, narzędzia i komunikację, a nie błędy konkretnych osób.

Struktura dokumentu post-mortem: timeline (chronologia zdarzeń z timestampami), impact (dotknięci użytkownicy, czas trwania, straty finansowe), root cause (techniczna przyczyna źródłowa), detection (jak wykryto, dlaczego nie wychwycono wcześniej), response (co zrobiono, co można było zrobić szybciej), action items (konkretne zadania z osobami odpowiedzialnymi i terminami). Action items powinny być S.M.A.R.T.: specific, measurable, assignable, realistic, time-bound.

Typowe action items po awarii produkcyjnej: dodać monitoring i alert na metrykę, która milczała; rozszerzyć pokrycie testowe na pominięty przypadek; dodać stronę w runbooku z algorytmem krok po kroku dla podobnej sytuacji; przeprowadzić szkolenie zespołu z narzędzia, które było używane nieprawidłowo. Każdy action item to konkretna zmiana zmniejszająca prawdopodobieństwo powtórki incydentu.