Problemo: Uzanta datumbazon estas "malrapida". La retteamo kulpigas la servilteamon. La servila teamo kulpigas la reton. Dume, uzantoj estas seniluziigitaj, kaj horoj estas malŝparitaj en cirkla malkonstruado.
La solvo: Sistema, scienca aliro al perturboj kiuj utiligas indicon, ne supozojn, por identigi radikkialojn.
La kosto de Haphazard Troubleshooting: Farita tempo, malĝustaj fiksas tiun maskon realaj problemoj, fingro-punkta inter teamoj, kaj degenerinta uzantsperto.
Reta perturbado estas principe praktikado en la scienca metodo:
Tiu artikolo disponigas strukturitan kadron por sendostaciaj perturboj kiuj malhelpas oftajn faltruojn kiel:
Antaŭ plonĝado en teknikajn testojn, respondas tiujn kvin kritikajn demandojn por malvastigi vian enketoskopon:
Ĉu la ŝanĝoj? Ĉu nova aparataro? Ĉu komputiloj ĝisdatigas? Topologio modifoj?
Unu uzanto? Ĉu unu konstruaĵo? Ĉiu? Specifa aplikaĵo nur?
Ĉu okazas la tutan tempon? Ĉu nur dum kelkaj horoj? Ĉu hazardaj okazoj?
Ĉu vi povas ekigi la problemon sur postulo?
Kontrolu ambaŭ finoj de la ligo
La OSI-modelo disponigas strukturitan kadron por maltrankviliĝoj. Laboro de Layer 1 (Physical) supren, aŭ de Layer 7 (Application) malsupren, depende de simptomoj.
Kiam oni uzas: Kompleta konektebleco perdo, neniu ligolumo, aŭ fizika tavolo simptomoj
show interfaces, ethtool eth0show mac address-table, show spanning-treeping, traceroute, show ip routetelnet host port, netstat -anpakaĵeto kaptasnslookup, dig, curl -vKiam oni uzas: Apliko-specifaj problemoj kie baza konektebleco ekzistas
Komencu ĉe Layer 7 (Estas SharePoint-servo kuranta? DNS-solvo por korekti IP?) kaj labori malsupren nur se bezonite.
Uzu tiun rapidan diagnozan arbon por identigi kiu tavolo malsukcesas:
TCP/IP-stako ne funkcias. Kontrolu OS-servojn, reinstalu retŝoforojn.
NIC handikapita, malĝusta ŝoforo, kablo malligita. Kontrolu: ip link show aŭ Device Manager
Vidu: Fizika kablo, ŝalti havenstatuson, VLAN-taskojn, ARP-tablon
Vidu: Routing Table, firewall reguloj, ACLoj. Uzo de uzo traceroute Por trovi kie pakaĵetoj ĉesas
Vidu: DNS-servilvaloroj, DNS-servilhavebleco, fajromuro blokanta havenon 53
Vidu: Firewall-reguloj, sekurecaj grupoj, servo aŭskultanta sur haveno
Problemo estas kun la aplikiĝo mem, konfirmo, aŭ aplikiĝkonfiguracio
Kiam vi havas hipotezon pri la radika kaŭzo, uzu tiujn izolajn teknikojn por konfirmi aŭ malakcepti ĝin:
Kapti trafikon ĉe fonto, mezaj punktoj, kaj celloko identigi kie pakaĵetoj estas faligitaj aŭ modifitaj:
# 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
Elimini eksterajn variablojn testante konekteblecon ene de ununura aparato:
# 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
Komparita konfiguracio kaj konduto kontraŭ laborsistemo:
# 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")
Properdokumentaro malhelpas cirklan malkonstruadon kie vi provas la saman aĵon multoblaj tempoj sen realigado de ĝi.
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
Datumbazo-aplikaĵo tempoj degradis de <100ms ĝis 5+ sekundoj. Aplikiĝteamo kulpigis "netlaborlatentecon."
Datumaĵservilo Os bufroj estis tro malgrandaj por alt-bandwidth × prokrastprodukto. TCP-fenestro plenigus, devigante senditon atendi.
# Increased TCP receive buffers on Linux database server
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sysctl -w net.core.rmem_max=16777216
Ne supozu: "Malrapida" ne ĉiam signifas "reto-latentecon". Ĉiam kolektas indicon (ping por latenteco, pakaĵasimilado por konduto) antaŭ saltado al konkludoj.
Servilligo falus hazarde, precipe sub ŝarĝo. Foje li laboris bone, foje tute ne respondema.
Aŭto-traktado malsukcesis. Servilo negocis plen-dupleksan, ŝanĝon falis reen al duon-dupleksa. Kolizioj nur okazis sub ŝarĝo kiam ambaŭ flankoj provis elsendi samtempe.
! Cisco switch - force full duplex
interface GigabitEthernet1/0/10
speed 1000
duplex full
Kontrolu ambaŭ finoj: Interfa statuso montras la negocitajn valorojn. Misagordo signifas aŭto-traktado malsukcesis. Ĉiam malmola-kodrapideco/dupleksa por serviloj.
Uzantoj povis foliumi kelkajn retejojn (Google, Yahoo) sed ne aliajn (bankretejo, firmaoportalo). Malgrandaj HTTP-petoj laboris, grandaj paĝoj tempigis.
ping -M do -s 1472 sukcesis, ping -M do -s 1473 malsukcesasVPN-tunelo reduktis MTU al 1400, sed fajromuro blokis ICMP "Fragmentation Needed" mesaĝojn. Path MTU Discovery (PMTUD) ne povis labori, kreante MTU nigran truon. Malgrandaj pakaĵetoj konvenas, grandaj pakaĵetoj kun DF peceto metita estis silente faligitaj.
! 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
Konsideri aferojn: Se malgrandaj petoj laboras sed grandaj translokigoj malsukcesas, suspektu MTU/frakto-temojn. Uzu ping kun DF-peco por testi padon MTU.
Voĉvokoj havis koluzian aŭdion, intermitajn gutojn. Nur okazis dum komercaj horoj (9am-5pm).
QoS-politiko ekzistis sed bendolarĝsigno estis malantaŭen: plej bona-fort ricevis 60%, voĉo ricevis 5%. Dum komerchoroj kiam datentrafiko pliiĝis, voĉpakaĵetoj estis faligitaj pro atendofluo.
! 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
Tempo-bazitaj temoj = kapacito: Se problemoj nur okazas dum okupataj horoj, ĝi ne estas malmola fiasko sed kapacito/QoS-temo. Kontrolu atendostatistikon, ne nur totalan bendolarĝon.
| Simbolo | Layer | Komandoj al Run | Kion serĉi |
|---|---|---|---|
| Neniu ligilo | 1 Layer | show interfaces |
Statuso: malsupren, neniu aviad-kompanio, kablo neligita |
| Plenkreda perdo | Layer 1/2 | show interfaces |
CRC-eraroj, runoj, gigantoj, kolizioj, malfruaj kolizioj |
| ne povas trovi enirejon | 2 Layer | arp -a |
Neniu ARP-eniro, MAC ne lernis, STP blokanta |
| ne povas atingi malproksiman subreton | 3 Layer | traceroute |
Mankanta itinero, malĝusta venont-hopo, routing buklo |
| Ligo rifuzis | 4 Layer | telnet host port |
Servo ne aŭskultante, fajromuro bloko, TCP RST |
| Malrapida efikeco | 4 + | ping (RTT) |
Alta latenteco, bendolarĝlimo, TCP redissendoj, nul fenestroj |
| Ne povas solvi mastron | 7 Layer | nslookup |
DNS-servilo neatingebla, malĝusta DNS konfig, NXDOMAIN |
| Intermetaj gutoj | Layer 1/2 | ping -f (flood) |
Dupleksa misagordo, malsukcesante kablon, STP-rekonverĝon |
| Kelkfoje, ne aliaj | Multoblaj | Extended ping |
Load balancanta temon, ECMP-simetrion, ŝtattablon superfluaĵo |
Konata kiam al escalate al vendisto TAC aŭ altrangaj inĝenieroj. Ekrano kiam:
Ĉiu malfeliĉa sesio estas lerna ŝanco. Konstrui personan sciobazon:
# 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
Organizi ofte-uzitajn komandojn per scenaro por rapida referenco dum krevigado.
Ŝanĝante konfiguraciojn sen komprenado de la problemo ofte faras aĵojn pli malbonaj aŭ maskas la realan temon.
Ofte "ret temoj" estas apliko, servilo, aŭ kliento-flankaj problemoj. Gatero indico antaŭ akceptado de kulpigo.
Vi perdos tempon ripetantan testojn kiujn vi jam faris, aŭ estos nekapabla klarigi al kolegoj kion vi provis.
Intermittaj problemoj ofte estas fruaj avertantaj signoj de urĝa fiasko. Enketis ilin antaŭ ol ili iĝas kritikaj.
Rebatante aparaton eble restarigos servon, sed se vi ne trovas WHY ĝi bezonis restartigadon, la problemo ripetiĝos.
Reta perturbado estas kaj scienco kaj arto. La scienco sekvas sisteman metodaron, uzante diagnozajn ilojn ĝuste, kaj komprenante protokolojn. La arto scias kiu testas kuri unue surbaze de simptomoj, rekonante padronojn de sperto, kaj sciante kiam al escalate.
Per sekvado de la sistema aliro skizita en tiu artikolo - rigardante la ĝustajn demandojn, laborante medie tra la OSI-modelo, dokumentante viajn ŝtupojn, kaj lernadon de ĉiu temo - vi iĝos pli efika ĉe perturboj kaj eviti la komunajn faltruojn kiuj kondukas al malŝparita tempo kaj malĝustaj fiksaj fiksaĵoj.
Memoru: La celo ne estas ĵus reestigi servon, sed kompreni WHY kiun ĝi malsukcesis tiel vi povas malhelpi ĝin okazi denove.
Last Updated: februaro 2, 2026 | Verkinto: Baud9600 Technical Team