Problem: Aplikacja bazy danych jest "wolna". Zespół sieci obwinia zespół serwerów. Serwery obwiniają sieć. Tymczasem użytkownicy są sfrustrowani, a godziny marnują się w kolistym debugowaniu.
Rozwiązanie: Systematyczne, naukowe podejście do rozwiązywania problemów, które wykorzystuje dowody, a nie założenia, do określenia przyczyn pierwotnych.
Koszt rozwiązywania problemów związanych z zagrożeniami: Stracony czas, nieprawidłowe poprawki, które maskują prawdziwe problemy, wskazując palcem między zespołami, i zdegradowane doświadczenie użytkownika.
Rozwiązywanie problemów sieci jest zasadniczo ćwiczeniem naukowym:
Artykuł ten stanowi ustrukturyzowane ramy rozwiązywania problemów sieciowych, które zapobiegają częstym pułapkom, takim jak:
Przed nurkowaniem w diagnostyce technicznej, odpowiedz na pięć krytycznych pytań, aby zawęzić zakres śledztwa:
Zmiana konfiguracji? Nowy sprzęt? Aktualizacje oprogramowania? Zmiany topologiczne?
Jeden użytkownik? Jeden budynek? Wszyscy? Wyłącznie specjalny wniosek?
Ciągle się to zdarza? Tylko w określonych godzinach? Przypadkowe zdarzenia?
Możesz uruchomić problem na żądanie?
Sprawdź oba końce połączenia
Model OSI zapewnia ustrukturyzowane ramy rozwiązywania problemów. Przer. od warstwy 1 (fizycznej) w górę lub od warstwy 7 (aplikacji) w dół, w zależności od objawów.
Kiedy stosować: Kompletna utrata łączności, brak światła lub fizycznych objawów warstw
show interfaces, ethtool eth0show mac address-table, show spanning-treeping, traceroute, show ip routetelnet host port, netstat -an, przechwytywanie pakietównslookup, dig, curl -vKiedy stosować: Problemy związane ze stosowaniem, w przypadku gdy istnieje podstawowa łączność
Start na warstwie 7 (Czy działa usługa SharePoint? DNS rozwiązuje błędy IP?) i pracuje tylko w razie potrzeby.
Użyj tego szybkiego drzewa diagnostycznego, aby określić, która warstwa nie działa:
Nie działa stos TCP / IP. Sprawdź usługi systemu operacyjnego, ponownie zainstaluj sterowniki sieciowe.
NIC wyłączone, zły kierowca, odłączony kabel. Sprawdź: ip link show lub menedżer urządzeń
Sprawdzanie: Kabel fizyczny, status portu przełącznika, przydział VLAN, tabela ARP
Sprawdź: Stół do jazdy, zasady firewalla, ADL. Stosowanie traceroute by znaleźć miejsce zatrzymania pakietów
Sprawdź: ustawienia serwera DNS, dostępność serwera DNS, port blokujący firewall 53
Sprawdź: Zasady Firewall, grupy ochrony, usługi słuchania na porcie
Problem tkwi w samej aplikacji, uwierzytelnianiu lub konfiguracji aplikacji
Jeśli masz hipotezę na temat przyczyny, użyj tych technik izolacji, aby ją potwierdzić lub odrzucić:
Przechwytywanie ruchu u źródła, punktów pośrednich i miejsca przeznaczenia w celu określenia, gdzie pakiety są wycofywane lub modyfikowane:
# Capture on client
tcpdump -i eth0 -w client.pcap host server.example.com
# Capture on server
tcpdump -i eth0 -w server.pcap host client.example.com
# Compare:
# - Do packets leave client? (check client.pcap)
# - Do packets arrive at server? (check server.pcap)
# - If yes/no: problem is in the path between
# - If yes/yes but server doesn't respond: server-side issue
Eliminacja zmiennych zewnętrznych poprzez testowanie połączeń w obrębie jednego urządzenia:
# Test TCP stack without network
ping 127.0.0.1
# Test application listening locally
telnet localhost 80
# Test loopback on network interface (if supported)
# Some NICs support physical loopback for Layer 1 testing
Porównaj konfigurację i zachowanie z systemem roboczym:
# Compare interface settings
diff <(ssh working-switch "show run int gi1/0/1") \
<(ssh broken-switch "show run int gi1/0/1")
# Compare routing tables
diff <(ssh router1 "show ip route") \
<(ssh router2 "show ip route")
Właściwa dokumentacja zapobiega debugowaniu w kole, gdzie próbujesz tego samego wielokrotnie, nie zdając sobie z tego sprawy.
Issue ID: TICKET-12345
Date/Time: 2026-02-02 14:30 UTC
Reported By: Jane Smith (jane.smith@company.com)
Affected Users: ~50 users in Building A, 3rd floor
Symptom: Cannot access file server \\fileserver01
Initial Observations:
- Issue started around 14:00 UTC
- Only affects Building A, 3rd floor
- Other buildings can access fileserver01
- Ping to fileserver01 (10.1.50.10) times out from affected users
- Ping to default gateway (10.1.30.1) succeeds
Tests Performed:
1. [14:35] Checked switch port status: gi1/0/15 is UP/UP
2. [14:38] Checked VLAN assignment: Port is in VLAN 30 (correct)
3. [14:42] Checked interface errors: 1,234 CRC errors on gi1/0/15
4. [14:45] Replaced patch cable - still seeing CRC errors
5. [14:50] Moved uplink to different port (gi1/0/16) - errors persist
6. [14:55] Checked fiber cleanliness - dirty connector found
Root Cause:
Dirty fiber connector on uplink between Building A floor switch
and distribution switch causing CRC errors and packet loss
Resolution:
Cleaned fiber connector with proper cleaning kit. CRC errors
dropped to zero. File server access restored.
Verification:
Users confirmed file server accessible. Monitored for 15 minutes
with no errors.
Time to Resolution: 25 minutes
Czas odpowiedzi aplikacji bazy danych zdegradowany z < 100ms do 5 + sekund. Zespół aplikacji obwiniał "Sieciową latencję".
Serwer baz danych bufory OS były zbyt małe dla produktów o dużej przepustowości × opóźnienie. Okno TCP wypełniłoby, zmuszając nadawcę do czekania.
# Increased TCP receive buffers on Linux database server
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sysctl -w net.core.rmem_max=16777216
Nie zakładaj: "Powolne" nie zawsze oznacza "opóźnienie sieci". Zawsze zbieraj dowody (ping za opóźnienie, przechwytywanie pakietów za zachowanie) przed wyciągnięciem pochopnych wniosków.
Połączenie z serwerem spadłoby losowo, szczególnie pod obciążeniem. Czasami działało dobrze, czasem zupełnie nie reaguje.
Auto- negocjacje zawiodły. Serwer wynegocjował full-duplex, przełącznik spadł do pół-duplex. Kolizje wystąpiły pod obciążeniem tylko wtedy, gdy obie strony próbowały transmitować jednocześnie.
! Cisco switch - force full duplex
interface GigabitEthernet1/0/10
speed 1000
duplex full
Sprawdź oba końce: Status interfejsu pokazuje wynegocjowane ustawienia. Niedopasowanie oznacza, że negocjacje nie powiodły się. Zawsze twarda prędkość kodu / duplex dla serwerów.
Użytkownicy mogą przeglądać niektóre strony internetowe (Google, Yahoo), ale nie inne (strona internetowa banku, portal firmy). Małe prośby HTTP działa, duże strony w czasie.
ping -M do -s 1472 sukces, ping -M do -s 1473 niepowodzenieTunel VPN zmniejszył MTU do 1400, ale firewall blokował wiadomości ICMP "Fragmentation Needed". Path MTU Discovery (PMTUD) nie mógł pracować, tworząc czarną dziurę MTU. Małe pakiety pasujące, duże pakiety z ustawionym bitem DF zostały po cichu upuszczone.
! Implemented TCP MSS clamping on router
interface Tunnel0
ip tcp adjust-mss 1360
! Alternative: Allow ICMP Type 3 Code 4 through firewall
access-list 101 permit icmp any any packet-too-big
Rozmiar ma znaczenie: Jeśli małe prośby działają, ale duże transfery zawodzą, podejrzewamy problemy z MTU / fragmentacji. Użyj ping z bitem DF do przetestowania ścieżki MTU.
Telefony głosowe były głośne, przerywane. Wystąpiło tylko w godzinach pracy (9- 5pm).
Polityka QoS istniała, ale przydział przepustowości był do tyłu: najlepszy wysiłek dostał 60%, głos dostał 5%. Podczas godzin pracy, gdy ruch danych wzrosła, pakiety głosowe zostały wycofane z powodu przepełnienia kolejki.
! Corrected QoS policy
policy-map WAN-QOS
class VOICE
priority percent 33
class VIDEO
bandwidth percent 25
class CRITICAL-DATA
bandwidth percent 20
class class-default
bandwidth percent 22
Kwestie czasowe = pojemność: Jeśli problemy pojawiają się tylko w godzinach pracy, nie jest to trudna porażka, ale problem pojemności / QoS. Sprawdź statystyki kolejki, nie tylko całkowitą przepustowość.
| Objawy | Warstwa | Polecenia do uruchomienia | Co szukać |
|---|---|---|---|
| Brak światła | Warstwa 1 | show interfaces |
Status: w dół, brak nośnika, odłączony kabel |
| Utrata pakietu | Warstwa 1 / 2 | show interfaces |
Błędy CRC, biegi, giganty, kolizje, późne kolizje |
| Nie można ping brama | Warstwa 2 | arp -a |
Brak wpisu ARP, MAC nie nauczył, STP blokowanie |
| Nie mogę dosięgnąć zdalnej podsieci | Warstwa 3 | traceroute |
Brakująca trasa, zły następny-hop, pętla routingu |
| Odmowa połączenia | Warstwa 4 | telnet host port |
Niesłuchanie usługi, blokada zapory, TCP RST |
| Powolne osiągi | Warstwa 4 + | ping (RTT) |
Wysoka latencja, limit przepustowości, retransmisje TCP, zero okien |
| Nie można rozwiązać nazwy komputera | Warstwa 7 | nslookup |
Serwer DNS nieosiągalny, zła konfiguracja DNS, NXDOMAIN |
| Krople przerywane | Layer 1/2 | ping -f (flood) |
Niedopasowanie Duplex, awaria kabla, powrót STP |
| Czasami działa, nie inne | Wiele | Extended ping |
Kwestia bilansowania obciążenia, asymetria ECMP, przepełnienie tabeli stanu |
Wiedzieć, kiedy eskalacja do TAC sprzedawcy lub starszych inżynierów. Eskalować, gdy:
Każda sesja jest okazją do nauki. Zbuduj osobistą bazę wiedzy:
# Example structure
~/troubleshooting-journal/
├── 2026-01-15-duplex-mismatch.md
├── 2026-01-22-mtu-black-hole.md
├── 2026-02-02-tcp-window-exhaustion.md
└── README.md # Index of all issues
# Each file contains:
# - Symptom
# - Diagnostic steps
# - Root cause
# - Resolution
# - Lessons learned
# - Related tickets/documentation
Zorganizuj często używane polecenia według scenariusza dla szybkiego odniesienia podczas rozwiązywania problemów.
Zmiana konfiguracji bez zrozumienia problemu często pogarsza sytuację lub maskuje prawdziwy problem.
Często "problemy sieciowe" to problemy aplikacji, serwera lub klienta. Zbierz dowody, zanim zaakceptujesz winę.
Stracisz czas na powtarzanie testów, które już zrobiłeś, albo nie będziesz w stanie wyjaśnić kolegom, czego próbowałeś.
Problemy okresowe są często wczesne objawy ostrzegawcze zbliżającej się awarii. Zbadaj je zanim staną się krytyczne.
Restartowanie urządzenia może przywrócić obsługę, ale jeśli nie dowiesz się, dlaczego potrzebne jest ponowne uruchomienie, problem się powtórzy.
Rozwiązywanie problemów sieciowych to nauka i sztuka. Nauka stosuje systematyczną metodologię, używając prawidłowo narzędzi diagnostycznych i protokołów zrozumienia. Sztuka jest wiedzieć, które testy najpierw na podstawie objawów, rozpoznawanie wzorców z doświadczenia, i wiedzieć, kiedy eskalacji.
Podążając za systematycznym podejściem opisanym w tym artykule - zadając właściwe pytania, pracując metodycznie za pośrednictwem modelu OSI, dokumentując swoje kroki i ucząc się z każdej kwestii - stajesz się bardziej skuteczny w rozwiązywaniu problemów i unikaniu wspólnych pułapek, które prowadzą do marnowania czasu i nieprawidłowych poprawek.
Pamiętaj: Celem nie jest tylko przywrócenie usługi, ale zrozumieć, dlaczego nie udało się, aby można było zapobiec to ponownie.
Ostatnia aktualizacja: 2 lutego 2026 r.