Probleem: Andmebaasirakendus on "aeglane". Võrgumeeskond süüdistab serverimeeskonda. Serverimeeskond süüdistab võrku. Vahepeal on kasutajad pettunud ja tunde raisatakse ringikujulise silumisega.
Lahendus: Süstemaatiline, teaduslik lähenemine tõrkeotsingule, mis kasutab algpõhjuste tuvastamiseks tõendeid, mitte eeldusi.
Haphazardi tõrkeotsingu maksumus: Raisatud aeg, valed parandused, mis varjavad tegelikke probleeme, näpuga näitamine meeskondade vahel ja halvenenud kasutajakogemus.
Võrgu tõrkeotsing on põhimõtteliselt teadusliku meetodi harjutus:
See artikkel pakub struktureeritud raamistikku võrgu tõrkeotsinguks, mis takistab ühiseid lõkse, nagu:
Enne tehnilise diagnostika sukeldumist vastake neile viiele kriitilisele küsimusele, et kitsendada oma uurimise ulatust:
Konfiguratsiooni muutused? Uus riistvara? Tarkvarauuendused? Topoloogia modifikatsioonid?
Üks kasutaja? Üks hoone? Kõik? Ainult konkreetne rakendus?
Juhtub kogu aeg? Ainult teatud tundidel? Juhuslikud juhtumid?
Kas saate probleemi nõudmisel käivitada?
Ühenduse mõlema otsa kontrollimine
OSI mudel annab struktureeritud raamistiku tõrkeotsinguks. Töö 1. kihist (füüsiline) ülespoole või 7. kihist (rakendus) allapoole, sõltuvalt sümptomitest.
Millal kasutada: Täielik ühenduvuse kadu, ühendusvalguse puudumine või füüsilise kihi sümptomid
show interfaces, ethtool eth0show mac address-table, show spanning-treeping, traceroute, show ip routetelnet host port, netstat -an, pakettide jäädvustaminenslookup, dig, curl -vMillal kasutada: Rakenduspõhised probleemid, kui on olemas põhiühenduvus
Alustage 7. kihist (Kas SharePointi teenus töötab?) DNS lahendab IP? ja töötab ainult vajaduse korral.
Kasutage seda kiirdiagnostikapuud, et tuvastada, milline kiht ebaõnnestub:
TCP/IP pinu ei tööta. Kontrollige operatsioonisüsteemi teenuseid, installige võrgudraiverid uuesti.
NIC keelatud, vale juht, kaabel lahti ühendatud. Kontroll: ip link show või seadmehaldur
Kontrolli: füüsiline kaabel, pordi olek, VLAN-i määramine, ARP-tabel
Kontroll: marsruutimislaud, tulemüüri reeglid, ACL-id. Kasuta traceroute leida, kus paketid peatuvad
Kontrolli: DNS serveri seaded, DNS serveri kättesaadavus, tulemüüri blokeeriv port 53
Kontrolli: tulemüüri reeglid, turvagrupid, teenindus kuulamine sadamas
Probleem on rakenduse enda, autentimise või rakenduse konfiguratsiooniga
Kui teil on hüpotees algpõhjuse kohta, kasutage neid isoleerimismeetodeid selle kinnitamiseks või tagasilükkamiseks:
Koguge liiklust tekkekohas, vahepunktides ja sihtkohas, et tuvastada, kus pakette kukutatakse või muudetakse:
# 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
Väliste muutujate kõrvaldamine, testides ühenduvust ühes seadmes:
# 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
Konfiguratsiooni ja käitumise võrdlemine töötava süsteemiga:
# 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")
Nõuetekohane dokumentatsioon takistab ringikujulist silumist, kus proovite sama asja mitu korda, ilma seda mõistmata.
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
Andmebaasirakenduste reageerimisajad on vähenenud <100 ms kuni 5+ sekundit. Rakendusmeeskond süüdistas "võrgu latentsust".
Andmebaasiserveri operatsioonisüsteemi puhvrid olid liiga väikesed suure ribalaiusega x viivitustoote jaoks. TCP aken täidaks, sundides saatjat ootama.
# Increased TCP receive buffers on Linux database server
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sysctl -w net.core.rmem_max=16777216
Ära eelda: "Aeglane" ei tähenda alati "võrgu latentsust". Alati koguda tõendeid (ping latentsus, paketi püüdmine käitumist) enne hüpped järeldused.
Serveriühendus langeb juhuslikult, eriti koormuse all. Mõnikord töötas hästi, mõnikord täiesti reageerimata.
Automaatläbirääkimised nurjusid. Server pidas läbirääkimisi täisdupleksiga, lüliti langes tagasi pooldupleksile. Kokkupõrge toimus koormuse all ainult siis, kui mõlemad pooled püüdsid samaaegselt edastada.
! Cisco switch - force full duplex
interface GigabitEthernet1/0/10
speed 1000
duplex full
Kontrolli mõlemat otsa: Liidese olek näitab läbiräägitud seadistusi. Ebakõla tähendab, et automaatsed läbirääkimised nurjusid. Serverite jaoks on alati kõvakoodi kiirus/dupleks.
Kasutajad said sirvida mõningaid veebisaite (Google, Yahoo), kuid mitte teisi (panga veebisait, ettevõtte portaal). Väikesed HTTP-taotlused töötasid, suured leheküljed aegusid.
ping -M do -s 1472 õnnestub, ping -M do -s 1473 ebaõnnestubVPN-tunnel vähendas MTU-d 1400-ni, kuid tulemüür blokeeris ICMP "Fragmentation Needed" sõnumeid. Path MTU Discovery (PMTUD) ei saanud töötada, luues MTU musta augu. Väikesed paketid sobivad, suured paketid, millel on DF-bitid, langesid vaikselt.
! 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
Suurus loeb: Kui väikesed taotlused töötavad, kuid suured ülekanded ebaõnnestuvad, kahtlustage MTU / fragmenteerimise probleeme. Tee MTU testimiseks kasutage pingit DF bitiga.
Häälkõnedel oli segane heli, vahelduvad väljalangemised. See toimus ainult tööajal (9:00-5:00).
QoS-poliitika oli olemas, kuid ribalaiuse jaotamine oli tagurpidi: parim pingutus sai 60%, hääl 5%. Töötundidel, mil andmeliiklus suurenes, langesid häälepaketid järjekordade ülevoolu tõttu.
! 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
Ajapõhised küsimused = suutlikkus: Kui probleemid tekivad ainult hõivatud tundidel, ei ole see raske ebaõnnestumine, vaid võimsuse / QoS probleem. Kontrollige järjekorra statistikat, mitte ainult ribalaiust.
| Sümptom | Layer | Käivitatavad käsud | Mida otsida |
|---|---|---|---|
| Lülituli puudub | 1. kiht | show interfaces |
Olek: maas, kandurita, kaabel lahti ühendatud |
| Paketikaotus | Kihi 1/2 | show interfaces |
CRC vead, äpardused, hiiglased, kokkupõrked, hilised kokkupõrked |
| Ei saa väravat pingida | kiht 2 | arp -a |
ARP kirje puudub, MACi ei õpita, STP blokeerimine |
| Võrgu alamvõrku ei pääse | 3. kiht | traceroute |
Puuduv marsruut, vale järgmine hüpe, marsruutimissilmus |
| Ühendusest keelduti | 4. kiht | telnet host port |
Teenus ei kuula, tulemüüriplokk, TCP RST |
| Aeglane jõudlus | Kihi 4+ | ping (RTT) |
Kõrge latentsusaeg, ribalaiuse piir, TCP taasedastamine, nullaknad |
| Masinanime ei saa lahendada | Kihi 7 | nslookup |
DNS serveri kättesaamatus, vale DNS seadistus, NXDOMAIN |
| Vahelduvad tilgad | Layer 1/2 | ping -f (flood) |
Dupleksi mittevastavus, kaabli rike, STP taasühinemine |
| Mõnikord töötab, mitte teised | Mitmekordne | Extended ping |
Koormuse tasakaalustamise probleem, ECMP asümmeetria, olekutabeli ülevool |
Tea, millal eskaleeruda müüjale TAC või kõrgematele inseneridele. Eskaleerimine, kui:
Iga tõrkeotsingu seanss on õppimisvõimalus. Luua isiklik teadmistebaas:
# 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
Korraldage sageli kasutatavad käsud stsenaariumi järgi, et tõrkeotsingu ajal kiiresti viidata.
Konfiguratsioonide muutmine probleemi mõistmata muudab sageli asju halvemaks või maskeerib tegelikku probleemi.
Sageli on "võrguprobleemid" rakenduse, serveri või kliendipoolsed probleemid. Koguge tõendeid enne, kui süüdistate.
Te raiskate aega juba tehtud testide kordamisele või ei suuda kolleegidele selgitada, mida olete proovinud.
Vahelduvad probleemid on sageli varajased hoiatusmärgid eelseisva ebaõnnestumise kohta. Uurige neid enne, kui nad muutuvad kriitiliseks.
Seadme taaskäivitamine võib teenuse taastada, kuid kui te ei saa teada, miks see vajas taaskäivitamist, tekib probleem uuesti.
Võrgu tõrkeotsing on nii teadus kui ka kunst. Teadus järgib süstemaatilist metoodikat, kasutades diagnostikavahendeid õigesti ja mõistes protokolle. Kunst on teadmine, millised testid kõigepealt sümptomite põhjal läbi viia, kogemustest mustrite äratundmine ja teadmine, millal eskaleeruda.
Järgides käesolevas artiklis kirjeldatud süstemaatilist lähenemist - küsides õigeid küsimusi, töötades metoodiliselt läbi OSI mudeli, dokumenteerides oma samme ja õppides igast probleemist - saate tõrkeotsingul tõhusamaks ja vältida ühiseid lõkse, mis põhjustavad raisatud aega ja valesid parandusi.
Pea meeles: Eesmärk ei ole lihtsalt teenuse taastamine, vaid mõista, miks see ebaõnnestus, et saaksite vältida selle kordumist.
Viimati uuendatud: 2. veebruar 2026 | Autor: Baud9600 Tehniline Meeskond