Nocny incydent w produkcji: stabilizacja monolitu i koordynacja zespołu
Nocny pagerowy alarm „PROD: wszystko czerwone” wyrwał ze snu. Dotarcie do sali incydentów: SRE-motto — ustabilizować, przeanalizować, postmortem. Zespół rozdzielił role: koordynacja, komunikacja, baza danych, monitoring metryk i logów. Cel — znaleźć przyczynę główną pod warstwami legacy-kodu.
Stakeholderzy otrzymali pierwsze powiadomienie: „Serwis niedostępny. Zespół pracuje. Aktualizacja za 15 minut”. Monitoring pokazał wszystkie metryki na czerwono, poza jedną zieloną kropką. Logi pełne błędów timeout przy dostępie do monolitu, ochrzczonego „smokiem”.
Diagnostyka: od kolejek do bazy danych
Metryka kolejek wiadomości rosła wykładniczo, konsumenci padały z powodu timeoutów. Przyczyna — wolne zapytania do BD. Przykładowe problematyczne zapytanie:
SELECT * FROM users WHERE some_condition ORDER BY created_at LIMIT 1000;
-- Bez indeksu na some_condition i created_at, na 10M+ wierszach — katastrofa.DBA wykrył brak indeksów i problemy N+1 w nowym serwisie. Architekt legacy potwierdził: monolit trzyma globalny stan, nie nadaje się do równoległości bez refaktoryzacji.
Propozycję pilnej migracji na Kubernetes odrzucono: to doda złożoność w kryzysie, nie rozwiąże rdzenia problemu.
Inkwizycja bezpieczeństwa i kompromis
Żądanie tymczasowego dostępu do ograniczenia ruchu i roll backu funkcji zablokowane przez security. Model zagrożeń wymaga uzgodnienia ryzyk. Kompromis: godzinny dostęp z logowaniem i raportem.
Działania:
- Ograniczenie ruchu rate limitingiem.
- Rollback nowej funkcjonalności przez feature flag.
- Monitoring odzyskiwania: czerwone → różowe → szare → stabilne.
Stakeholderzy zaktualizowani: „Ustabilizowaliśmy. Analiza trwa. Aktualizacja za 30 minut”.
Lokalizacja i lekcje incydentu
Incydent zlokalizowany: kolejka zapchana, BD obciążona nieoptymalnymi zapytaniami z nowego serwisu. Monolit stabilny na uwięzi, ale wymaga systemowego podejścia.
Interwencja menedżera OKR: plany podwojenia release’ów, „wszystko przepisać” i Kubernetes. Ryzyko: skupienie na wielkich projektach zamiast inkrementalnych usprawnień.
Co ważne:
- Przyczyna główna w nieoptymalnych zapytaniach i kolejkach, a nie w monolit jako takim.
- Role w zespole incydentów kluczowe: koordynacja, komunikacja, ekspertyza.
- Kompromisy security możliwe z tymczasowymi środkami i audytem.
- Unikać pośpiesznych migracji w kryzysie; fokus na stabilizacji.
- Postmortem wskaże roadmapę: indeksy, feature flagi, gradualna refaktoryzacja.
Całkowity czas pracy zespołu — 2 godziny do stabilizacji. Kontynuacja: postmortem i plan.
— Editorial Team
Brak komentarzy.