Skip to content
My Docs

Debugowanie krok po kroku

1. Zmieniaj tylko jedną rzecz naraz

Section titled “1. Zmieniaj tylko jedną rzecz naraz”

Jeśli poprawisz 5 rzeczy na raz:

  • nie wiesz, która coś naprawiła
  • nie wiesz, która coś zepsuła
  • cofasz o kilka minut, nie dni
  • werbalizuj co robisz, rozmawiaj ze sobą - nawet jeśli uważasz że to głupie

Dlatego:

Zrób zmianę → sprawdź → logi → dopiero następna zmiana.

2. Najpierw sprawdź rzeczy podstawowe, nie zaawansowane

Section titled “2. Najpierw sprawdź rzeczy podstawowe, nie zaawansowane”

Bardzo często źródłem problemu jest:

  • literówka
  • zła ścieżka
  • brak uprawnień
  • brak wolumenu
  • config w złym miejscu
  • proces nie działa

Pierwsze pytania:

  • Czy to w ogóle działa?
  • Czy proces żyje?
  • Czy port jest nasłuchiwany?
  • Czy ścieżka istnieje?
  • Czy plik jest tam, gdzie myślę?

3. Izoluj problem: “kto właściwie nie działa?”

Section titled “3. Izoluj problem: “kto właściwie nie działa?””

Zawsze ustal:

  • czy problem jest po stronie A (np. GitLab)
  • czy po stronie B (np. Runner)
  • czy na połączeniu między nimi

Przykłady:

  • Runner → API żyje?
  • API → Rails padł?
  • Rails → PG nie odpowiada?
  • PG → autoryzacja padła?
  • PG działa → może tylko konfiguracja niedostępna?

Wyznacz granicę błędu.

4. Nie zakładaj — sprawdzaj

Section titled “4. Nie zakładaj — sprawdzaj”

Jeśli wydaje Ci się, że:

  • „baza działa”
  • „config się załadował”
  • „proces jest uruchomiony”
  • „połączenie jest dobre”
  • „runner ma poprawny token”

…to nie zakładaj tego. Udowodnij prostymi testami:

Terminal window
psql -U user -h host -d db
docker exec container cat /etc/gitlab-runner/config.toml
curl -I http://gitlab/api/v4

5. Patrz zawsze w logi — nie w GUI

Section titled “5. Patrz zawsze w logi — nie w GUI”

GUI często kłamie lub jest opóźnione. Logi nie. Kiedy jest błąd — logi są jedyną prawdą.

###6. Najpierw zrozum, potem naprawiaj Nigdy nie rób zmian na oślep, np.:

restart

reinstall

„może to, może tamto”

Najpierw ustal:

co właściwie się zepsuło

kiedy się zepsuło

dlaczego się zepsuło

Dopiero potem działaj.

7. Mierz, czy system reaguje na zmianę

Section titled “7. Mierz, czy system reaguje na zmianę”

Zmieniłeś config → czy GitLab go widzi?

czy logi pokazują reconfigure?

czy nowy parametr wszedł?

czy runner zmienił status?

Jeśli nie ma reakcji, to wiesz, że:

nie działa reconfigure

config nie jest wczytywany

albo zmieniłeś niewłaściwy plik

###8. Nigdy nie poprawiaj dwóch warstw naraz Np. nie rób:

zmian w docker-compose i

zmian w configu i

restartów i

reconfigure i

edycji bazy

Najpierw jedna warstwa. Potem sprawdzenie. Dopiero następna.

9. “Wyzerowanie” zmiennych często rozwiązuje problem

Section titled “9. “Wyzerowanie” zmiennych często rozwiązuje problem”

Usunięcie:

cache

starych wolumenów

starego configu

starego tokenu

starego runnera

…rozwiązuje więcej problemów, niż byś pomyślał. Bo systemy często trzymają śmieci.

10. Zakładaj, że problem jest prosty, dopóki nie udowodnisz, że jest skomplikowany

Section titled “10. Zakładaj, że problem jest prosty, dopóki nie udowodnisz, że jest skomplikowany”
Najczęściej winny jest:

jeden brakujący plik

jedna linijka

jeden zły user

jeden port

jeden błąd w configu

Skomplikowane problemy są rzadkie.

11. Zawsze sprawdzaj: “czy to na pewno ten kontener/plik/proces?”

Section titled “11. Zawsze sprawdzaj: “czy to na pewno ten kontener/plik/proces?””
Nagle okazuje się, że:

edytujesz config w złym wolumenie

restartujesz niewłaściwy kontener

patrzysz w logi nie tej usługi

edytujesz TOML, który nie jest mountowany

patrzysz w ścieżkę hosta, a nie kontenera

To klasyk.

12. Ostateczne rozwiązanie: zacznij od czystego stanu

Section titled “12. Ostateczne rozwiązanie: zacznij od czystego stanu”

Jeśli debugowanie trwa ZA długo, to reset jest szybszy niż kopanie:

Terminal window
docker compose down -v

Od nowa konfiguracja, od nowa runner. Systemy typu GitLab są deterministyczne — jeśli dasz im czysty stan, działają poprawnie.