3:17 w nocy. Telefon wibruje. Monitor uptime'u — serwis, który co kilka minut pinguje twoją stronę i alarmuje, gdy przestaje odpowiadać — mówi, że twoja aplikacja nie żyje. Żadnego zespołu. Żadnego dyżuru. Żadnego SRE (site reliability engineer, czyli człowieka, którego cała robota to pilnowanie, żeby usługi działały). Tylko ty, twój laptop i adrenalina.

To nie jest scenariusz z głowy. 1 marca AWS miał kaskadową awarię, która zaczęła się w regionie ZEA i rozlała po US-EAST-1, kładąc 38 usług i zostawiając solo founderów wpatrzonych w dashboardy z błędami bez nikogo do zadzwonienia. Potem 27 marca Cloudflare Pages przez kilka godzin miał problemy z zarządzaniem własnymi domenami — founderzy, którzy postawili swoje strony marketingowe na Pages, patrzyli, jak ich domeny znikają z internetu w środku dnia roboczego.

Byłem tam. Więcej razy, niż kapibara powinna przyznać. Pierwsze kilka incydentów — panika i pogarszanie sytuacji. Teraz mam playbook. Wyrzuca panikę z równania i zastępuje ją krokami. Oto cała procedura. 📋

Krok 0: Jeszcze niczego nie naprawiaj

Brzmi absurdalnie. Aplikacja leży. Każda sekunda kosztuje pieniądze, reputację albo jedno i drugie. Instynkt krzyczy: napraw to natychmiast.

Ale najniebezpieczniejsza rzecz, jaką możesz zrobić podczas incydentu, to działać bez zrozumienia, co się popsuło.

Widziałem, jak solo founderzy o 3 w nocy wchodzą przez SSH — zdalne połączenie z serwerem przez bezpieczny terminal — na produkcję, odpalają komendę z pamięci i kładą bazę danych razem z aplikacją. Jeden problem zamienił się w dwa. Oryginalna naprawa zajęłaby 20 minut. Odzyskiwanie bazy — 6 godzin.

Reguła zero: zanim czegokolwiek dotkniesz, poświęć 2 minuty na zrozumienie sytuacji. Nie 20 minut. Dwie. Przeczytaj błąd. Sprawdź logi. Postaw hipotezę. Dopiero wtedy działaj.

Krok 1: Triage — 2 minuty

Zadaj trzy pytania:

Usługa leży całkowicie czy częściowo? Walnij w health endpoint — specjalny URL, który raportuje, czy kluczowe systemy aplikacji działają, taki wbudowany puls. Jeśli strona się ładuje, ale wywołania API (zapytania z frontendu do backendu) padają, to częściowa degradacja. Jeśli nie ładuje się nic, to pełna awaria. To określa pilność.

Czy użytkownicy są teraz dotknięci? Sprawdź analitykę. Jeśli jest 3 w nocy w twojej strefie czasowej i twoi użytkownicy są w tej samej strefie, może pięć osób to zauważyło. Jeśli twoi użytkownicy są globalni, setki mogą właśnie patrzeć na stronę z błędem.

Kiedy to się zaczęło? Sprawdź dashboard monitoringu. Jeśli popsuło się 5 minut temu, prawdopodobnie jest to powiązane z ostatnią zmianą. Jeśli usługa kuśtykała od 3 godzin, a ty dopiero teraz dostałeś alert, twój monitoring ma lukę, którą musisz załatać jutro.

Zapisz odpowiedzi. Notatnik, wiadomość do siebie, plik tekstowy. To jest twój incident log — pojedynczy dokument śledzący wszystko o tej awarii. Rano podziękujesz sobie za to.

Krok 2: Komunikacja — 1 minuta

Nawet jeśli nikt nie jest na nogach, opublikuj status. Twoja strona statusowa, social media, Discord — gdziekolwiek użytkownicy sprawdzają. Jedno zdanie:

"Wiemy o problemie dotyczącym [usługi]. Badamy sprawę. Aktualizacja w ciągu 30 minut."

Cisza jest straszniejsza niż znana awaria. Użytkownicy, którzy widzą "badamy sprawę", czekają cierpliwie. Użytkownicy, którzy nie widzą nic, zakładają najgorsze i zaczynają o tym pisać. Jedna minuta komunikacji kupuje ci 30 minut spokojnego śledztwa. ⚙️

Krok 3: Sprawdź oczywiste — 5 minut

80% incydentów w małych firmach sprowadza się do jednej z pięciu przyczyn:

1. Pełny dysk. Odpal df -h (pokazuje miejsce na dysku w czytelnym formacie). Jeśli jakikolwiek system plików pokazuje 100%, masz winowajcę. Szybka naprawa: znajdź i usuń rozrośnięte logi. du -sh /var/log/* ujawnia sprawców.

2. Brak pamięci. Odpal free -h (pokazuje zużycie RAM-u). Jeśli dostępna pamięć jest bliska zeru, coś ją pożera. ps aux --sort=-%mem | head -10 listuje największych konsumentów pamięci — cyfrowy odpowiednik szukania, kto zostawił wszystkie światła włączone. Ubij rozdęty proces, zrestartuj usługę.

3. Proces się wysypał. Odpal systemctl status twoja-aplikacja — systemctl to menedżer usług Linuksa, narzędzie do uruchamiania, zatrzymywania i monitorowania twoich aplikacji. Jeśli mówi "inactive (dead)" albo "failed", zrestartuj: systemctl restart twoja-aplikacja. Potem sprawdź, dlaczego się wysypało: journalctl -u twoja-aplikacja --since "1 hour ago" (journalctl czyta dziennik zdarzeń systemu).

4. Wygasł certyfikat SSL. SSL (Secure Sockets Layer) to ikona kłódki w przeglądarce — oznacza, że połączenie jest szyfrowane. Te certyfikaty wygasają. Certyfikaty Let's Encrypt działają 90 dni. Jeśli zapomniałeś o automatycznym odnawianiu, to problem na 3 w nocy czekający, aż się wydarzy. Naprawa: certbot renew && systemctl reload nginx. Skonfiguruj automatyczne odnawianie Certbota w ten weekend, żeby to nigdy się nie powtórzyło.

5. Problem z DNS. DNS (Domain Name System) to książka telefoniczna internetu — zamienia "twojastrona.pl" na adres serwera, który komputery potrafią znaleźć. Odpal dig twojastrona.pl, żeby sprawdzić. Jeśli nie rozwiązuje nazwy, twój dostawca DNS może mieć problemy. Albo twoja domena wygasła. Tak, domeny wygasają. Widziałem to u startupów po rundzie finansowania.

Jeśli żadna z tych pięciu przyczyn nie pasuje, jesteś w tych 20%, które wymagają prawdziwego debugowania. Przejdź do kroku 4.

Krok 4: Audyt ostatnich zmian — 5 minut

Coś się zmieniło. Usługi nie psują się spontanicznie — jak hydraulika, padają, bo coś się przesunęło. Zapytaj:

  • Czy ostatnio robiłem deploy? Deploy to wrzucenie nowego kodu na serwer produkcyjny. Sprawdź git log --since="24 hours ago", żeby zobaczyć ostatnie zmiany w kodzie.
  • Czy zmieniałem konfigurację? Sprawdź znaczniki czasu modyfikacji plików konfiguracyjnych.
  • Czy zaktualizowała się jakaś zależność? Zależność to czyjś kod, na którym opiera się twoja aplikacja — biblioteka, framework. Sprawdź lock file paczek pod kątem ostatnich zmian.
  • Czy dostawca hostingu miał problem? Sprawdź ich stronę statusową.

Najczęstsza odpowiedź: zrobiłeś deploy. Naprawa: rollback — powrót do poprzedniej działającej wersji. Nie debugowanie. Rollback. Postaw usługę, debuguj jutro.

# Jeśli tagujesz releasy (etykiety wersji jak v1.2.3):
git checkout v1.2.3
bash deploy.sh

# Jeśli jeszcze nie tagujesz wersji (zacznij od dziś):
git revert HEAD
bash deploy.sh

Rollback wydaje się jak poddanie. Nie jest. To najbardziej profesjonalna reakcja: priorytet uptime'u nad ego. Napraw kod jutro przy kawie i świetle dziennym. 🍵

Krok 5: Reguła 30 minut

Jeśli w ciągu 30 minut nie znalazłeś root cause — faktycznej przyczyny, dla której coś się popsuło, a nie tylko objawu — eskaluj. "Ale jestem solo founderem. Do kogo eskalować?"

  • Support dostawcy hostingu. Jeśli płacisz za managed hosting, korzystaj z niego. Dosłownie do tego służy.
  • Kontraktor na retainerze. Nawet 800 zł miesięcznie za "mogę ci napisać o 3 w nocy dwa razy w roku" jest tego warte.
  • Twoja społeczność. Odpowiedni serwer Discord, grupa na Slacku, forum. Wrzuć błąd, logi, co sprawdziłeś. Dobre społeczności odpowiadają szybko.
  • Asystent AI. Wklej błąd do Claude albo ChatGPT: "Oto mój log błędów serwera. Usługa padła o 3:17 w nocy. Oto, co sprawdziłem: [lista]. Co jeszcze powinienem zbadać?" Nie wejdzie ci na serwer przez SSH, ale może podrzucić kroki diagnostyczne, które przegapiłeś.

Reguła 30 minut istnieje, bo po pół godzinie samotnego debugowania o 3 w nocy twój osąd się pogarsza. Zaczynasz próbować losowych rzeczy. Losowe zmiany na serwerze produkcyjnym o 3 w nocy — tak właśnie dane znikają bezpowrotnie.

Krok 6: Poranek po incydencie

Przeżyłeś kryzys. Wracaj spać. Serio. Postmortem — ustrukturyzowana analiza tego, co poszło nie tak i jak temu zapobiec — odbywa się jutro. Przy kawie. Na trzeźwo. 🛁

Jutrzejsza checklista:

  1. Co się popsuło? Jedno zdanie.
  2. Jaka była przyczyna źródłowa? Nie "serwer się wysypał", ale "Źle skonfigurowana rotacja logów zapełniła dysk do 100%."
  3. Jaki był wpływ? Czas trwania, liczba dotkniętych użytkowników, utracone przychody, jeśli da się zmierzyć.
  4. Co utrudniło szybsze wykrycie? Załataj tę lukę w monitoringu.
  5. Co utrudniło szybsze przywrócenie? Dodaj ten krok do playbooka.
  6. Co zapobiegnie powtórce? Wdróż to w tym tygodniu. Nie "kiedyś". W tym tygodniu.

Zapisz to w pliku. incidents/2026-03-27.md. Budujesz wiedzę instytucjonalną — przeszukiwalną historię tego, co się wcześniej zepsuło i co to naprawiło. Kiedy uderzy następny incydent, ty-z-przeszłości już zostawił notatki.

Setup na przed-incydent

Najlepsza reakcja na incydent dzieje się przed incydentem. Oto, co skonfigurować w ten weekend:

  • Monitoring uptime'u. UptimeRobot ma darmowy tier: 50 monitorów, interwały co 5 minut. Pinguje twoją stronę i wysyła SMS-a, gdy padnie. Ustawiasz raz, zapominasz. ✅
  • Rotacja logów. Skonfiguruj logrotate — narzędzie Linuksa, które automatycznie kompresuje i usuwa stare pliki logów — dla każdego loga, który produkuje twoja aplikacja. Dyski się nie zapełniają, gdy logi są ogarnięte.
  • Automatyczne odnawianie SSL. Certbot z cronem (zaplanowane zadanie uruchamiane automatycznie na timerze). Nigdy więcej ręcznego odnawiania certyfikatów.
  • Automatyczne backupy. Dump bazy danych na S3 (chmurowy storage Amazona) albo dowolny object storage, co 6 godzin. Przetestuj proces przywracania przynajmniej raz. Backup, którego nigdy nie przywracałeś, to nadzieja, nie backup.
  • Skrypt rollbacku. Jedna komenda, żeby wrócić do poprzedniej wersji. Zero myślenia o 3 w nocy.

Całość: mniej więcej 3 godziny w spokojną sobotę po południu. Te 3 godziny chronią twój biznes następnym razem, gdy coś się posypie w ciemnościach.

Najspokojniejsi founderzy, jakich znam, nie są spokojni dlatego, że nic się nie psuje. U wszystkich się psuje. Są spokojni, bo mają playbook. Przeszli przez to wcześniej. Wiedzą, co robić dalej. I wiedzą — głęboko, z doświadczenia — że panika jeszcze nigdy, ani razu, nie naprawiła serwera. 🫶

incident-response, devops, automation, solo-founder, infrastructure