Metoda debugowania

Tutaj należy zawęzić jeden błąd za pomocą testu, porównać oczekiwany wynik z faktycznym oraz wybrać kolejne działanie. Metodę można zastosować do programu, kontenera lub usługi sieciowej. Wymagane jest znane działanie użytkownika, które powinno zadziałać, oraz dostęp do badania danego rozwiązania.

Zacznij od siedmiu kroków i „Porównanie oczekiwanego z faktycznym” oraz użyj ich w Zadaniu 1. Kolejność sieciowa stanowi wsparcie, gdy błąd dotyczy sieci. Tabela dla Linuksa/Proxmox to przykład, a nie polecenia, których musisz wykonać przy każdym błędzie. Samotest jest opcjonalnym ćwiczeniem.

Jeśli chcesz zobaczyć metodę zastosowaną do konkretnego błędu, przejdź do [[MetodadebugowaniaLevel2-Modelowedebugowanie_aplikacji|modelowego debugowania aplikacji]]. Tam uzasadniasz kolejny test przed otwarciem propozycji odpowiedzi.

Siedem kroków

1. Zmapuj okoliczności. Co się stało i kiedy to zaczęło się dziać?
2. Odtwórz błąd, gdy jest bezpiecznie go powtórzyć.
3. Zlokalizuj i ogranicz możliwe źródła błędu – który warstwa lub który komponent może być przyczyną?
4. Zebranie informacji – dzienniki zdarzeń, komunikaty o błędach, wyniki poleceń.
5. Określ możliwe rozwiązania na podstawie tego, co teraz wiesz.
6. Testuj jedno rozwiązanie lub hipotezę naraz. Jeśli zmienisz kilka rzeczy jednocześnie, nie będziesz wiedzieć, co faktycznie rozwiązało problem.
7. Udokumentuj błąd i jego rozwiązanie, abyś Ty (lub ktoś inny) mógł rozpoznać je następnym razem.

Kolejność rozwiązywania problemów z siecią i usługami

Gdy nie wiesz, gdzie występuje błąd sieciowy, ta kolejność stanowi punkt wyjścia. Jeśli masz już odpowiedni wynik testu, użyj go, aby wybrać zakres dalszej diagnostyki. Nie musisz uruchamiać wszystkich testów sieciowych dla błędu kodowego.

flowchart TD
    A[Fizyczne połączenie] --> B[Interfejs sieciowy]
    B --> C[Konfiguracja IP]
    C --> D[Sieć lokalna]
    D --> E[Brama i routingu]
    E --> F[DNS]
    F --> G[Usługa]

Wideo: Jak sprawdzić połączenie sieciowe za pomocą polecenia ping

Wideo pokazuje, jak można używać polecenia ping do sprawdzania dostępności urządzenia w sieci.

Dla każdego punktu powinieneś/powinnaś umieć:

• wyjaśnić, co dokładnie sprawdza punkt kontrolny
• znaleźć odpowiednie wartości przy użyciu właściwego polecenia (patrz 🌐 Protokoły sieciowe dla ping, nslookup i innych)
• odróżniać obserwację od założenia
• wybierać kolejny krok kontroli na podstawie wyniku poprzedniego kroku, a nie z przeczucia

Polecenia per warstwa w maszynie wirtualnej Linux w Proxmox

To jest zastosowanie metody na wypadek, gdy maszyna wirtualna z Linuksem nie może się połączyć z usługą. Uruchamiaj odpowiednie polecenia w Konsoli maszyny wirtualnej, a nie w powłoce (Shell) hosta Proxmox. W razie potrzeby zobacz 🧭 Nawiguj w Proxmox VE. Wybierz test dla tego, co badasz; tabela nie stanowi wymogu Zadania 1.

Jeśli brakuje trasy domyślnej, sprawdź, jak VM powinna docierać do celów poza własną siecią; niektóre cele mogą mieć osobne trasy. Niektóre sieci blokują ping, więc brak odpowiedzi sam w sobie nie dowodzi zerwania połączenia. Jeśli rozwiązanie nazw i źródła pakietów działają, masz konkretne wyniki do dalszego użycia. 🌐 IP, podsieć i bramka domyślna wyjaśnia adres, prefiks i trasę.

Oczekiwany wynik w porównaniu z faktycznym

Test debugowania jest przydatny tylko wtedy, gdy wiesz, czego się spodziewasz przed jego uruchomieniem. Zapisz:

Wymagania:    Czego ma być w stanie zrobić użytkownik?
Cel:          Jaki adres/usługę testujesz?
Oczekiwane:   Co powinno się stać, jeśli wszystko działa?
Rzeczywiste:  Co się stało?
Pokazuje:     Co to wynik dowodzi?
Nie pokazuje sam:  Czego ten wynik NIE dowodzi?

Zadanie 1 - Zastosuj metodę do rzeczywistego problemu

Weź problem, na który natknąłeś się w innym kursie z zakresu administracji systemami (Driftsstøtte) lub rozwoju oprogramowania (Utvikling): kontener, który nie uruchamia się, usługa, której nie można połączyć, skrypt zgłaszający błąd:

1. Przejdź przez siedem powyższych kroków, jeden po drugim.
2. Dla każdego testu zapisz „oczekiwane vs faktyczne”.
3. Zanotuj, która komponenta lub warstwa jest wyznaczana przez test. Używaj kolejności sieciowej tylko wtedy, gdy pasuje ona do problemu.
4. Wypróbuj jedno uzasadnione rozwiązanie w środowisku testowym, które masz uprawnienia modyfikować. Powtórz oryginalną czynność użytkownika i sprawdź, czy korekta rzeczywiście działa. Zachowaj ścieżkę powrotu do poprzedniej konfiguracji.

Jeśli nie masz dostępu do żadnego błędu, możesz przeanalizować ten przykład: Aplikacja zwraca oczekiwaną stronę dla /, ale HTTP 404 dla /status. Co pokazują te dwie odpowiedzi i co sprawdziłbyś jako pierwsze? Oba żądania otrzymały odpowiedź HTTP; pierwszą kontrolą jest to, czy /status naprawdę istnieje w aplikacji oraz czy klient używa poprawnej trasy. Przykład stanowi ćwiczenie analityczne, a nie dowód na to, że naprawiłeś własne rozwiązanie.

Punkt kontrolny: Błąd został wyizolowany i opanowany

Pokaż dziennik testów i wyjaśnij, która obserwacja poparła kolejny test lub poprawkę. Po wprowadzeniu poprawki oryginalna operacja powinna dać oczekiwany rezultat. Możesz to wytłumaczyć ustnie lub na piśmie, mając przed sobą polecenia i wyniki. Jeśli błąd nadal pozostaje otwarty, podaj, co zostało przetestowane, co wciąż jest niepewne oraz jeden dokładny następny test. Nie zapisuj domniemanego powodu jako potwierdzonego.

Przetestuj się

Opcjonalny samotest z informacją zwrotną. Odpowiedzi nie są przesyłane nauczycielowi. Użyj własnego dziennika testowego do przedstawienia faktycznej diagnostyki błędów; samotest nie zastępuje praktycznej kontroli.

Podsumowanie

• Rozwiązywanie problemów to metoda, a nie zgadywanie – siedem stałych kroków od identyfikacji po udokumentowanie
• Metoda podziału na pół pozwala zawęzić zakres problemu, gdy znasz elementy łańcucha używanego przez test
• W przypadku sieci: korzystaj z warstw, aby wybrać odpowiedni kolejny test na podstawie obserwacji
• Zawsze zapisuj oczekiwane w porównaniu z faktycznym przed wykonaniem testu i pamiętaj, że pojedynczy test rzadko dowodzi wszystkiego