# Najlepsze praktyki reagowania na incydenty dla solo devów URL: https://whatshouldibuildnext.com/pl/journal/najlepsze-praktyki-reagowania-na-incydenty Type: blog Locale: pl Published: 2026-08-29 Updated: 2026-08-31 --- > Jak zbudować kompletny system reagowania na incydenty jako solo dev: alerting bez fałszywych alarmów, runbooki na 3:00 w nocy, strona statusu za $0 i post-mortemy, które faktycznie coś dają. ## Najlepsze praktyki reagowania na incydenty dla solo devów Najlepsze praktyki reagowania na incydenty są zwykle pisane z myślą o zespołach enterprise, nie o solo devach. Shippujesz projekt, zdobywa użytkowników, i pewnego ranka ktoś tweetuje, że strona nie działa od trzech godzin. Nie wiedziałeś. Żadnego alertingu. Żadnego runbooka. Żadnej strony statusu. To wzorzec awarii dla 90% projektów budowanych solo. Nie breach, nie katastrofalne zdarzenie infrastrukturalne - po prostu: nikt ci nie powiedział, że coś jest zepsute, nie miałeś planu, a twoi użytkownicy dowiedzieli się przed tobą. Trzy rzeczy wystarczą: wiedzieć kiedy coś pękło, wiedzieć co z tym zrobić, i komunikować status tym, którym zależy. Ten przewodnik omawia każdą z nich z perspektywy buildera - co budować samemu, a co spinać z gotowych narzędzi. Nie potrzebujesz ani 40-stronicowego playbooka, ani drogiego enterprise toolstacka. Potrzebujesz 90 minut skupionego okablowania i kilku plików, do których sięgniesz o 3:00 w nocy. ## Co psuje się jako pierwsze, gdy jesteś solo i on-call Przy pierwszym incydencie, którym zarządzasz sam, spędzisz 12 minut na szukaniu gdzie co jest, zanim poświęcisz 4 minuty na faktyczną naprawę. To jest prawdziwy koszt. Nie downtime. Narzut koordynacyjny jednoosobowego zespołu, który nic nie zapisał. Gdzie są zmienne środowiskowe? Który serwis tak naprawdę pada? Czy to dotyczy wszystkich użytkowników, czy tylko jednego klienta? W krytycznym oknie incydentu szukasz odpowiedzi, które powinieneś przygotować wcześniej. Rozwiązaniem nie jest skomplikowane oprzyrządowanie. To po prostu odpowiedź na te pytania zanim nadejdzie 3:00 w nocy. Jest użyteczny test: wyobraź sobie, że produkcyjne API pada teraz. Masz 10 minut. Czy możesz znaleźć odpowiednie logi, zidentyfikować wadliwy komponent i zrobić rollback lub hotfix, nie otwierając więcej niż dwóch zakładek, których jeszcze nie masz otwartych? Jeśli odpowiedź brzmi "nie" - to jest dokładnie to, co rozwiązuje incident response. ![Solo developer przy biurku późną nocą z telefonem pokazującym wiele powiadomień o alertach i monitoringiem serwera na ekranie laptopa](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/whatshouldibuildnext/2026-08/2586d5-inline1.webp) ## Trzy rzeczy, których naprawdę potrzebujesz w indie incident response Zanim cokolwiek zbudujesz, nazwij, co system ma robić: - **Wykryj problem** zanim użytkownik napisze do ciebie DM - **Powiedz ci, co zrobić** gdy jesteś na wpół śpiący i masz tylko kontekst z alertu - **Poinformuj twoich użytkowników** co się dzieje, nie pogarszając sytuacji Każde narzędzie incident response, od PagerDuty po twój własny cron job, mapuje się na jedno z tych trzech zadań. Zbuduj najprostszą wersję, która robi wszystkie trzy, i zatrzymaj się. Pokusa jest budować w stronę wersji enterprise: harmonogramy on-call, polityki eskalacji, poziomy severity P0-P5, szablony post-mortemów. To ma sens przy 20 inżynierach i 500 000 użytkownikach. Przy jednym devie i 500 użytkownikach te abstrakcje pożrą twoje weekendy i zostaną nieużywane. Minimalna wersja jest osiągalna w ten weekend. Zacznij od niej. ## Budowanie warstwy alertingu: problem fałszywych alarmów Każdy dev, który budował własny alerting, ma tę samą historię: pierwsza reguła była błędna i wyłączył pager po dwóch tygodniach szumu. Zacznij od jednego sprawdzenia, które ma znaczenie. Failing health check endpoint wystarczy. `# Prosty endpoint health check (Express/Node) app.get('/health', (req, res) => { res.json({ status: 'ok', timestamp: Date.now() }); });`Następnie podepnij cron job pingujący go co 60 sekund. Jeśli zawiedzie trzy kolejne razy, dostajesz wiadomość. To twoja pierwsza warstwa alertingu. Wyłapuje 80% incydentów, które dotykają użytkowników. Wskaźnik fałszywych alarmów w tym setupie jest bliski zeru. Dostajesz powiadomienie gdy serwis faktycznie nie działa, nie gdy skok CPU wyzwolił próg, który nigdy nie był skalibrowany. To najtrudniejsza rzecz do prawidłowego ustawienia w alertingu: alert musi być prawdziwy za każdym razem, albo nauczysz się go ignorować. Alerting oparty na logach przychodzi po tym, gdy monitor uptime działa i jest zaufany. Dla self-hosted stacków Grafana radzi sobie z tym dobrze przy niższych kosztach. Datadog zaczyna mieć sens, gdy zarządzasz więcej niż dwoma lub trzema serwisami i chcesz zunifikowany widok z łatwą integracją z pipeline deploymentowym. ## Runbooki - dokument, który piszesz o 23:00 i czytasz o 3:00 w nocy Runbook to nie dokumentacja. Dokumentacja wyjaśnia, jak coś działa. Runbook mówi przyszłej wersji ciebie - zestresowanej, ledwo przytomnej, pod presją - dokładnie co zrobić teraz. Format, który działa dla solo projektów: - **Co jest zepsute?** Jedno zdanie, tylko objawy - **Czy to pilne?** Czy dotyka teraz płacących klientów? - **Co robię?** Trzy do pięciu ponumerowanych kroków, zaczynając od najszybszej rzeczy do wypróbowania Tyle. Pisz go gdy nie jesteś w incydencie. Przeglądaj i aktualizuj po incydencie, żeby sprawdzić czy był faktycznie użyteczny. Jeśli podczas incydentu musiałeś szukać informacji, których runbook nie zawierał, wróć i go uzupełnij. Gdzie przechowujesz runbooki, ma mniejsze znaczenie niż nawyk ich pisania. Strona w Notion, plik Markdown w repo, współdzielony dokument. Test: czy możesz to otworzyć na telefonie w 30 sekund, na wpół rozbudzony, o 3:00 w nocy? Praktyczny argument za Notion zamiast pliku w repo to dostęp mobilny. Jeśli śpisz obok telefonu, bo masz ruch produkcyjny i złe przeczucie co do deployu, który właśnie wysłałeś - to ma znaczenie. GitBook to kolejna solidna opcja, jeśli wolisz coś bardziej ustrukturyzowanego, co może też służyć jako publiczna dokumentacja deweloperska. ![Biurko developera z otwartym notatnikiem pokazującym schemat decyzji incident response, terminal na laptopie i karteczki z diagramami](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/whatshouldibuildnext/2026-08/4f1cbf-inline2.webp) ## Publiczna strona statusu: czego użytkownicy naprawdę chcą, gdy coś pada Twoi użytkownicy nie potrzebują dashboardu obserwowalności w czasie rzeczywistym. Potrzebują wiedzieć dwie rzeczy: czy psuje się u wszystkich i czy jesteś tego świadomy? Minimalna strona statusu ma trzy elementy: - Wskaźnik statusu z maksymalnie trzema stanami: działa, zdegradowane, nie działa - Znacznik czasu, kiedy bieżący stan był ostatnio aktualizowany - Jedno zdanie prostym językiem gdy coś jest nie tak Użytkownicy sprawdzający stronę statusu podczas incydentu nie czytają diagramów architektury. Chcą przestać debugować swój własny setup, bo teraz wiedzą, że to nie po ich stronie. Zbudowanie tego zajmuje mniej niż cztery godziny: - Statyczna strona HTML ze snippetem JavaScript, który pobiera status z endpointu - Tabela w Supabase z dwoma polami: status (enum) i message (text) - Cron job aktualizujący status na podstawie wyniku health check - Admin endpoint za authorizacją do ręcznego wpisania wiadomości gdy trzeba Trudna część to nie build. To nawyk aktualizowania strony podczas incydentu zamiast rzucania się od razu na naprawę. Aktualizacja zajmuje 30 sekund i oszczędza 15 maili do supportu. Drugi argument za zbudowaniem tego samemu: komercyjne narzędzia do stron statusu kosztują od $30 do $100 miesięcznie za to, co w zasadzie jest endpointem JSON i statyczną stroną HTML. Zbuduj raz, miej na własność. Twoi użytkownicy nie potrzebują Statuspage.io. Potrzebują URL-a, który nadal działa gdy twoja główna domena pada. ![Dashboard strony statusu pokazujący wskaźniki kondycji serwisów z zielonymi i bursztynowymi kropkami statusu i wykresem uptime na ciemnym UI](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/whatshouldibuildnext/2026-08/dd8fe9-inline3.webp) ## Post-mortemy, gdy sam jesteś odpowiedzialny Post-mortemy w enterprise dotyczą tego, żeby nie winić nikogo i identyfikować błędy systemowe. Solo - ty jesteś systemem. Psychologia jest inna, ale praktyka nadal ma znaczenie. Powód pisania post-mortemów samemu: bez tego rozwiążesz ten sam typ problemu dwa razy. Trzy miesiące później będziesz patrzył na zapytanie do bazy danych, które się zablokowało z powodu indexu, którego nie dodałeś, i będziesz miał mglisty wspomnienie naprawiania czegoś podobnego, ale nie pamiętasz co. Pięciominutowy format, który trzyma się w całości: - Co się stało (jeden akapit, tylko fakty, bez języka winy) - Co zrobiłeś żeby to naprawić - Jedna rzecz do zmiany w systemie - Jedna rzecz do zmiany w procesie Pisz w tym samym miejscu co runbooki. Staje się wejściem dla następnej aktualizacji runbooka. Przez sześć miesięcy tworzy to lekki rejestr trybów awarii twojego systemu, którego żadne enterprise narzędzie do post-mortemów nie replikuje dla solo buildera. Post-mortem pisany w dniu incydentu, gdy wszystko jest jeszcze świeże, jest wart dziesięć razy więcej niż ten pisany tydzień później z pamięci. Nawyk jest ważniejszy niż format. ## Budować czy sklejać z gotowych narzędzi? Uczciwa odpowiedź zależy od tego, gdzie jesteś. Jeśli nie masz żadnych płacących klientów: buduj wszystko sam. Health check cron, strona statusu, runbooki w Notion. To właściwy projekt do nauki wzorców. Shippujesz go w weekend. Uczy cię, czego faktycznie wymaga incident response. I jeśli zdecydujesz się później go zbudować i sprzedać jako produkt, masz wymagania zwalidowane na sobie. Jeśli masz płacących klientów, którzy zależą od uptime już teraz: zacznij od gotowych narzędzi. Podepnij Grafana Cloud free tier, skonfiguruj monitor uptime i otwórz stronę runbooków w Notion tego popołudnia. Potrzebujesz pokrycia teraz, nie po trzech weekendach budowania. Rzecz warta zbudowania samemu niezależnie od etapu: strona statusu. Miej ją na własność, hostuj na osobnej domenie, zbuduj ją w ten weekend. Wszystko inne możesz sklejać z istniejących free tierów, dopóki złożoność nie uzasadni budowania własnego. ## Luka, o której żaden poradnik incident response nie mówi Problem nie jest z toolingiem. Jest z 48 godzinami między "powinienem skonfigurować alerting" a "faktycznie skonfigurowałem alerting". Większość solo dev stacków ma wystarczająco dużo prymitywów obserwowalności, żeby zbudować pierwszą warstwę incident response w jeden dzień. Endpoint health check gdzieś istnieje. Logi są gdzieś. Pipeline deploymentowy ma jakiś error handling. Brakuje 90 minut skupionego okablowania: health check do monitora uptime, monitor uptime do SMS lub alertu na Telegramie, jedna strona w Notion z trzema runbookami, statyczna strona z endpointem statusu w Supabase. To nie jest projekt, który shippujesz użytkownikom. To projekt, który shippujesz dla siebie. To projekt, który sprawia, że budujesz z pewniejszą ręką. Zbuduj go w ten weekend. Pierwszy raz gdy coś padnie o 3:00 w nocy i spędzisz 4 minuty na naprawieniu zamiast 40 minut na szukaniu - zrozumiesz, dlaczego najlepsze praktyki reagowania na incydenty w ogóle istnieją. Nie dlatego, że enterprise tego wymaga. Dlatego, że alternatywa jest gorsza. A gorsza alternatywa ma na imię: użytkownik, który odkrył awarię przed tobą i już nie wrócił. ## FAQ ### Czym są najlepsze praktyki reagowania na incydenty dla solo devów? To zestaw prostych zasad i narzędzi, które pozwalają szybko wykryć awarię, wiedzieć co z nią zrobić i informować użytkowników - bez enterprise toolstacka. Dla solo deva liczy się szybkość reakcji i przygotowanie z góry odpowiedzi na pytania, które pojawią się o 3:00 w nocy: gdzie są logi, który serwis pada, czy dotyka to wszystkich użytkowników. ### Od czego zacząć z alertingiem, jeśli prowadzę projekt solo? Zacznij od jednego health check endpointu pingowanego co 60 sekund przez cron job. Jeśli zawiedzie trzy razy z rzędu - SMS lub wiadomość na Telegramie. To wyłapuje 80% incydentów przy niemal zerowym wskaźniku fałszywych alarmów. Nie buduj bardziej złożonego systemu, dopóki ten nie działa niezawodnie i jest zaufany. ### Ile czasu zajmuje zbudowanie podstawowego systemu reagowania na incydenty? Realistycznie - jeden weekend. Health check z alertingiem: kilka godzin. Pierwsza wersja strony statusu: mniej niż 4 godziny. Trzy runbooki: 30-45 minut każdy. Razem możesz mieć działający system już w niedzielę wieczór, bez zewnętrznych subskrypcji. ### Czy powinienem pisać post-mortemy, gdy jestem sam? Tak. Nie po to, żeby kogoś winić, ale żeby nie rozwiązywać tego samego problemu dwa razy. Pięciominutowy format (co się stało, co zrobiłem, co zmienić w systemie, co zmienić w procesie) przez sześć miesięcy buduje rejestr trybów awarii, który jest bezcenny dla każdego solo buildera. ### Kiedy warto używać gotowych narzędzi zamiast budować własne? Jeśli masz płacących klientów, którzy zależą od uptime już dziś: Grafana Cloud free tier i monitor uptime konfiguruj teraz. Jeśli dopiero budujesz i uczysz się wzorców: buduj od zera - to świetny projekt na weekend. Strona statusu jest warta zbudowania samemu niezależnie od etapu. ### Ile kosztuje zbudowanie własnej strony statusu? Praktycznie nic: statyczna strona HTML, tabela w Supabase (free tier), cron job. W porównaniu z $30 do $100 miesięcznie za komercyjne narzędzia, własna strona zwraca się po pierwszym miesiącu. Jedyny prawdziwy koszt to mniej niż 4 godziny pracy raz. ### Co to jest runbook i po co go pisać jako solo dev? Runbook to nie dokumentacja - to instrukcja dla przyszłej wersji siebie, który jest zestresowany i ledwo przytomny o 3:00 w nocy. Mówi dokładnie co zrobić teraz: co jest zepsute, czy to pilne i trzy do pięciu kroków od najszybszego rozwiązania. Piszesz go gdy nie ma incydentu; czytasz gdy on jest.