Skip to content
My Docs

DevOps: Debugowanie krok po kroku

1. Najpierw ustal: co na pewno działa?

Section titled “1. Najpierw ustal: co na pewno działa?”

Ci smiga.

Jeśli kontekst jest niepełny, trzeba najpierw ustalić pewniki, bo inaczej wszystko dalej jest zgadywaniem.
To obejmuje:

  • Czy proces się uruchamia?
  • Czy kontener działa?
  • Czy port nasłuchuje?
  • Czy sieć działa?
  • Czy logi są generowane?
  • Czy baza żyje?
  • Czy endpoint odpowiada?

Eliminujesz nieznane.
Im więcej faktów ustalisz, tym mniej „mgły wojny”.

2. Wyjmij problem z kontekstu

Section titled “2. Wyjmij problem z kontekstu”

Jeśli coś nie działa: zminimalizuj środowisko do absolutnie najprostszej możliwej wersji.

Przykłady:

  • Docker → uruchamiasz samą bazę, bez aplikacji
  • Backend → testujesz połączenie bezpośrednio przez curl
  • Aplikacja → odpalasz ją lokalnie bez kontenerów
  • Sieć → sprawdzasz połączenie na ip:port zamiast przez DNS/hostname

Minimalizacja zabija 90% błędów.

3. Jeden ruch → jeden efekt

Section titled “3. Jeden ruch → jeden efekt”

Nigdy nie zmieniaj 5 rzeczy jednocześnie. Workflow:

  1. Zmieniasz jedną zmienną
  2. Restartujesz tylko powiązany element (np. tylko bazę)
  3. Obserwujesz logi
  4. Jeśli dalej źle — dopiero wtedy kolejna zmiana

To jest kluczowe, bo inaczej nie wiesz, co faktycznie naprawiło problem.

4. Od dołu do góry (warstwowe debugowanie)

Section titled “4. Od dołu do góry (warstwowe debugowanie)”

Każdy system ma warstwy. Diagnostyka od najniższej:

  • Warstwa 1 — Infrastruktura / OS

    • Czy masz dysk?
    • Czy są uprawnienia?
    • Czy firewall nie blokuje?
    • Czy jest RAM?
    • Czy CPU nie jest w 100%?

  • Warstwa 2 — Sieć

    • Ping działa?
    • Port jest otwarty?
    • Docker network działa?
    • DNS poprawny?

  • Warstwa 3 — Proces / Kontener

    • Kontener żyje?
    • Proces w środku działa (ps aux)?
    • Logi nie pokazują crasha?

  • Warstwa 4 — Baza / Usługa zależna

    • Da się połączyć lokalnie?
    • Da się połączyć z zewnątrz?
    • User istnieje?
    • Hasło pasuje?

  • Warstwa 5 — Aplikacja

    • Czy konfiguracja jest poprawnie wczytana?
    • Czy walidacja przechodzi?
    • Czy endpoint działa?

  • Warstwa 6 — Integracje / API / kolejki

    • Czy tokeny są poprawne?
    • Czy URL jest dostępny?
    • Czy są time-outy?

  • Warstwa 7 — UI / klient

    • Czy przeglądarka dostaje 200?
    • Czy są błędy JS?

Jeżeli warstwa niżej nie działa, warstwa wyżej nigdy nie zadziała.

5. Diagnoza zawsze zaczyna się od pytania: „czy mam połączenie?”

Section titled “5. Diagnoza zawsze zaczyna się od pytania: „czy mam połączenie?””

W 60–70% przypadków problemem jest brak połączenia:

  • Baza → psql -h ...
  • Redis → redis-cli -h ...
  • HTTP → curl -v ...
  • Sieć → nc -vz host port
  • Docker → docker logs, docker inspect

Jeśli połączenie nie działa → nie idziesz dalej.

6. Każdy błąd rozkładasz na: źródło → objaw → dowód

Section titled “6. Każdy błąd rozkładasz na: źródło → objaw → dowód”

Kiedy log jest niejednoznaczny:

  • Źródło — co miało być zrobione?
  • Objaw — co system faktycznie zrobił?
  • Dowód — co na to logi bez interpretacji?

Jeśli log nie wystarcza — zbieraj kolejne dane. Brakuje danych → zaznacz to i poproś o brakujący fragment.

7. Zanim naprawiasz — potwierdź, co jest faktycznym błędem

Section titled “7. Zanim naprawiasz — potwierdź, co jest faktycznym błędem”

Często w logach widać:

  • Błąd A (prawdziwy)
  • Błąd B (efekt A)
  • Błąd C (efekt B)
  • Błąd D (efekt C)

Filtruj:

  • Pierwszy błąd po starcie systemu
  • Powtarzające się błędy
  • Błędy oznaczone jako fatal
  • Błędy sieciowe

Reszta bywa szumem.

8. Cache, locki, wolumeny – „ciche zabójcy”

Section titled “8. Cache, locki, wolumeny – „ciche zabójcy””

Kiedy problem wygląda irracjonalnie:

  • Wyczyść cache
  • Usuń lock file
  • Usuń temp
  • Podnieś uprawnienia
  • Restart usług
  • Odbuduj kontener
  • Usuń wolumen jeśli to świeża instancja

To rozwiązuje absurdalnie dużo błędów.

9. Zawsze debugujesz jeden poziom niżej

Section titled “9. Zawsze debugujesz jeden poziom niżej”

Przykład:

  • Problem w backendzie? → sprawdzasz bazę
  • Problem w bazie? → sprawdzasz proces
  • Problem w procesie? → sprawdzasz OS
  • Problem w OS? → sprawdzasz sprzęt

To najpewniejszy sposób eliminacji.

10. Nie zgadujesz — weryfikujesz

Section titled “10. Nie zgadujesz — weryfikujesz”

Jeśli brakuje danych:

  • Jawnie mów „brakuje danych”
  • Proś o brakujące informacje
  • Dopiero potem wnioskuj

W ten sposób niczego nie przedstawiasz jako fakt, jeśli nie masz pewności.

11. „Twardy reset” robisz dopiero na końcu

Section titled “11. „Twardy reset” robisz dopiero na końcu”
  • Purge wolumenów
  • Purge konfiguracji
  • Reinstall obrazów
  • Clean build

Reset jest skuteczny, ale powinien być ostatnim krokiem, bo usuwa ślady błędu.

12. Po rozwiązaniu — nauka wzorca

Section titled “12. Po rozwiązaniu — nauka wzorca”

Za każdym razem, kiedy naprawisz błąd, dopisujesz sobie w głowie nowy „szablon”.

Z czasem:

  • 20% problemów znasz na pamięć
  • 60% przypomina coś, co już widziałeś
  • 20% jest naprawdę nowe

Masz workflow, który przeprowadzi Cię przez każdy problem.