.. başlıq: Şəbəkə problemlərinin aradan qaldırılması metodologiyası - Sistematik yanaşma
.. şlak: şəbəkə problemlərinin aradan qaldırılması-metodologiyası
.. tarix: 2026-02-02 18:00:00 UTC
.. teqlər: şəbəkə, problemlərin aradan qaldırılması, metodologiya, diaqnostika
.. kateqoriya: məqalələr
.. keçid:
.. təsviri: Vaxt itkisinin və səhv düzəlişlərin qarşısını alan şəbəkə problemlərinin aradan qaldırılmasına sistemli, elmi yanaşma
.. növü: mətn
<style>
.article-container {
    max-width: 900px;
    margin: 0 auto;
    padding: 20px;
    font-family: 'Segoe UI', Tahoma, Geneva, Verdana, sans-serif;
    line-height: 1.8;
    color: #333;
}

h1 {
    color: #2c3e50;
    border-bottom: 3px solid #3498db;
    padding-bottom: 15px;
    margin-bottom: 30px;
}

h2 {
    color: #2c3e50;
    margin-top: 40px;
    margin-bottom: 20px;
    border-left: 5px solid #3498db;
    padding-left: 15px;
}

h3 {
    color: #34495e;
    margin-top: 30px;
    margin-bottom: 15px;
}

.intro-box {
    background: linear-gradient(135deg, #667eea 0%, #764ba2 100%);
    color: white;
    padding: 30px;
    border-radius: 12px;
    margin-bottom: 30px;
}

.intro-box h2 {
    color: white;
    border: none;
    margin-top: 0;
}

.warning-box {
    background: #fff3cd;
    border-left: 5px solid #ffc107;
    padding: 20px;
    margin: 25px 0;
    border-radius: 6px;
}

.info-box {
    background: #d1ecf1;
    border-left: 5px solid #17a2b8;
    padding: 20px;
    margin: 25px 0;
    border-radius: 6px;
}

.success-box {
    background: #d4edda;
    border-left: 5px solid #28a745;
    padding: 20px;
    margin: 25px 0;
    border-radius: 6px;
}

.danger-box {
    background: #f8d7da;
    border-left: 5px solid #dc3545;
    padding: 20px;
    margin: 25px 0;
    border-radius: 6px;
}

.flowchart {
    background: #f8f9fa;
    padding: 30px;
    border-radius: 12px;
    margin: 30px 0;
    border: 2px solid #dee2e6;
}

.flowchart-step {
    background: white;
    border: 2px solid #3498db;
    padding: 20px;
    margin: 15px 0;
    border-radius: 8px;
    position: relative;
}

.flowchart-step.decision {
    border-color: #e74c3c;
    background: #fee;
}

.flowchart-step.success {
    border-color: #27ae60;
    background: #efe;
}

.flowchart-arrow {
    text-align: center;
    font-size: 24px;
    color: #3498db;
    margin: 10px 0;
}

.command-box {
    background: #2d2d2d;
    color: #f8f8f2;
    padding: 20px;
    border-radius: 8px;
    font-family: 'Courier New', monospace;
    overflow-x: auto;
    margin: 20px 0;
}

.command-box code {
    color: #f8f8f2;
}

table {
    width: 100%;
    border-collapse: collapse;
    margin: 25px 0;
}

th, td {
    padding: 12px;
    text-align: left;
    border: 1px solid #dee2e6;
}

th {
    background: linear-gradient(135deg, #667eea 0%, #764ba2 100%);
    color: white;
    font-weight: 600;
}

tr:nth-child(even) {
    background: #f8f9fa;
}

.case-study {
    background: #f8f9fa;
    border-radius: 12px;
    padding: 25px;
    margin: 30px 0;
    border-left: 5px solid #3498db;
}

.case-study h3 {
    color: #3498db;
    margin-top: 0;
}

.checklist {
    list-style: none;
    padding: 0;
}

.checklist li {
    padding: 10px 10px 10px 35px;
    margin: 8px 0;
    background: #f8f9fa;
    border-radius: 6px;
    position: relative;
}

.checklist li:before {
    content: '✓';
    position: absolute;
    left: 10px;
    color: #28a745;
    font-weight: bold;
    font-size: 18px;
}

.tip-box {
    background: #e7f3ff;
    border-left: 5px solid #2196F3;
    padding: 20px;
    margin: 25px 0;
    border-radius: 6px;
}

.tip-box strong {
    color: #2196F3;
}
</style>
<div class="article-container">
<h1>Şəbəkə problemlərinin aradan qaldırılması metodologiyası: sistematik yanaşma</h1>
<div class="intro-box">
<h2>Metodologiya niyə vacibdir</h2>
<p><strong>Problem:</strong>Verilənlər bazası proqramı "yavaşdır". Şəbəkə komandası günahı server qrupunda görür. Server komandası şəbəkəni günahlandırır. Bu vaxt, istifadəçilər məyus olur və dairəvi sazlamada saatlar sərf olunur.</p>
<p><strong>Həlli:</strong>Kök səbəbləri müəyyən etmək üçün fərziyyələrdən deyil, sübutlardan istifadə edən problemlərin həllinə sistemli, elmi yanaşma.</p>
<p><strong>Təsadüfi problemlərin aradan qaldırılmasının dəyəri:</strong>Vaxt itkisi, real problemləri maskalayan səhv düzəlişlər, komandalar arasında barmaq işarəsi və pis istifadəçi təcrübəsi.</p>
</div>
<h2>Giriş: Şəbəkəyə Tətbiq olunan Elmi Metod</h2>
<p>Şəbəkə problemlərinin aradan qaldırılması elmi metodda əsaslı bir məşqdir:</p>
<ol>
<li><strong>müşahidə edin</strong>simptomlar və məlumat toplamaq</li>
<li><strong>Hipotez yaratmaq</strong>kök səbəb haqqında</li>
<li><strong>Hipotezi yoxlayın</strong>diaqnostik vasitələrlə</li>
<li><strong>Nəticələri təhlil edin</strong>və hipotezi təsdiq və ya rədd edin</li>
<li><strong>Düzəliş həyata keçirin</strong>təsdiqlənmiş əsas səbəbə əsaslanır</li>
<li><strong>Doğrulayın</strong>problem həll olunur</li>
</ol>
<p>Bu məqalə aşağıdakı kimi ümumi tələlərin qarşısını alan şəbəkə problemlərinin həlli üçün strukturlaşdırılmış çərçivə təqdim edir:</p>
<ul>
<li>Təsdiq qərəzi (yalnız ilkin təxmininizi dəstəkləyən sübut axtarır)</li>
<li>Diaqnoz olmadan təsadüfi dəyişikliklər (“püskürt və dua et” yanaşması)</li>
<li>Kök səbəbləri əvəzinə simptomları düzəltmək</li>
<li>Nəyin sınandığını sənədləşdirmədən dairəvi sazlama</li>
</ul>
<h2>Beş Əsas Sual</h2>
<p>Texniki diaqnostikaya başlamazdan əvvəl araşdırma əhatənizi daraltmaq üçün bu beş kritik suala cavab verin:</p>
<div class="flowchart">
<div class="flowchart-step decision">
<strong>Sual 1: Bu yaxınlarda nə dəyişdi?</strong>
<p>Konfiqurasiya dəyişir? Yeni avadanlıq? Proqram təminatı yeniləmələri? Topologiya dəyişiklikləri?</p>
<ul>
<li>Dəyişikliklərin idarə edilməsi qeydlərini yoxlayın</li>
<li>Konfiqurasiya idarəetmə sistemlərində son öhdəlikləri nəzərdən keçirin</li>
<li>Soruşun: "Dünən işləyirdi?"</li>
</ul>
</div>
<div class="flowchart-arrow">↓</div>
<div class="flowchart-step decision">
<strong>Sual 2: Kim təsirlənir?</strong>
<p>Bir istifadəçi? Bir bina? Hamı? Yalnız xüsusi tətbiq?</p>
<ul>
<li><strong>Bir cihaz:</strong>Çox güman ki, yerli problem (NIC, kabel, konfiqurasiya)</li>
<li><strong>Bir alt şəbəkə:</strong>Şlüz, DHCP və ya keçid problemi</li>
<li><strong>Hər kəs:</strong>Əsas infrastruktur, ISP və ya geniş yayılmış problem</li>
<li><strong>Xüsusi proqram:</strong>Tətbiq serveri, təhlükəsizlik duvarı qaydası və ya DNS</li>
</ul>
</div>
<div class="flowchart-arrow">↓</div>
<div class="flowchart-step decision">
<strong>Sual 3: Daimidir, yoxsa Fasiləlidir?</strong>
<p>Hər zaman olur? Yalnız müəyyən saatlarda? Təsadüfi hadisələr?</p>
<ul>
<li><strong>Daimi:</strong>Sərt nasazlıq (kabel kəsilməsi, yanlış konfiqurasiya, aşağı xidmət)</li>
<li><strong>Zamana əsaslanan:</strong>İş saatlarında tıxac, planlaşdırılan proseslər</li>
<li><strong>Fasiləli/Təsadüfi:</strong>Dupleks uyğunsuzluğu, uğursuz avadanlıq, aralıq əlaqə</li>
</ul>
</div>
<div class="flowchart-arrow">↓</div>
<div class="flowchart-step decision">
<strong>Sual 4: Siz onu çoxalda bilərsinizmi?</strong>
<p>Problemi istəyə görə işə sala bilərsinizmi?</p>
<ul>
<li><strong>Bəli:</strong>Diaqnoz qoymaq daha asandır (fərziyyələri sınaqdan keçirə bilər)</li>
<li><strong>Xeyr:</strong>Monitorinqi/girişi qurun və təkrarlanmanı gözləyin</li>
</ul>
</div>
<div class="flowchart-arrow">↓</div>
<div class="flowchart-step decision">
<strong>Sual 5: Qarşı tərəf nə görür?</strong>
<p>Bağlantının hər iki ucunu yoxlayın</p>
<ul>
<li>Müştəri perspektivi və server perspektivi</li>
<li>Mənbədə və təyinatda paket tutma</li>
<li>Asimmetrik marşrutlaşdırma? Göndərmək və qəbul etmək üçün müxtəlif yollar?</li>
</ul>
</div>
</div>
<h2>ACİ Model əsaslı diaqnostik yanaşma</h2>
<p>OSI modeli problemlərin aradan qaldırılması üçün strukturlaşdırılmış çərçivə təmin edir. Simptomlardan asılı olaraq 1-ci Layerdən (Fiziki) yuxarıya və ya Layer 7-dən (Tətbiq) aşağıya doğru işləyin.</p>
<h3>Aşağıdan yuxarıya yanaşma (Layer 1 → Layer 7)</h3>
<p><strong>Nə vaxt istifadə etməli:</strong>Tam əlaqə itkisi, heç bir keçid işığı və ya fiziki təbəqə simptomları</p>
<div class="flowchart">
<div class="flowchart-step">
<strong>1-ci səviyyə: Fiziki</strong>
<ul>
<li>Yoxlayın: Kabel qoşulub? Link işıqları yandırılır? Fiber təmiz?</li>
<li>Əmrlər:<code>show interfaces</code>, <code>ethtool eth0</code></li>
<li>Axtarın: CRC səhvləri, toqquşmalar, gec toqquşmalar, qaçışlar, nəhənglər</li>
</ul>
</div>
<div class="flowchart-arrow">↓</div>
<div class="flowchart-step">
<strong>Layer 2: Data Link</strong>
<ul>
<li>Yoxlayın: Düzgün VLAN? Port aktivdir? STP bloklanır?</li>
<li>Əmrlər:<code>show mac address-table</code>, <code>show spanning-tree</code></li>
<li>Axtarın: MAC flapping, STP topologiyası dəyişiklikləri, VLAN uyğunsuzluqları</li>
</ul>
</div>
<div class="flowchart-arrow">↓</div>
<div class="flowchart-step">
<strong>Layer 3: Şəbəkə</strong>
<ul>
<li>Yoxlayın: Ping defolt şlüz ola bilərmi? Marşrut cədvəli düzgündür?</li>
<li>Əmrlər:<code>ping</code>, <code>traceroute</code>, <code>show ip route</code></li>
<li>Axtarın: Çatışmayan marşrutlar, yanlış növbəti keçid, marşrutlaşdırma döngələri</li>
</ul>
</div>
<div class="flowchart-arrow">↓</div>
<div class="flowchart-step">
<strong>4-cü səviyyə: Nəqliyyat</strong>
<ul>
<li>Yoxlayın: TCP bağlantısı qura bilərsinizmi? Firewall bloklama portu?</li>
<li>Əmrlər:<code>telnet host port</code>, <code>netstat -an</code>, paket tutma</li>
<li>Axtarın: TCP təkrar ötürülmələri, sıfır pəncərələr, RST paketləri</li>
</ul>
</div>
<div class="flowchart-arrow">↓</div>
<div class="flowchart-step">
<strong>Layer 5-7: Sessiya/Təqdimat/Tətbiq</strong>
<ul>
<li>Yoxlayın: DNS həll olunur? Tətbiq cavab verir? Doğrulama işləyir?</li>
<li>Əmrlər:<code>nslookup</code>, <code>dig</code>, <code>curl -v</code></li>
<li>Axtarın: DNS xətaları, tətbiq xətaları, fasilə problemləri</li>
</ul>
</div>
</div>
<h3>Yuxarıdan Aşağıya yanaşma (Layer 7 → Layer 1)</h3>
<p><strong>Nə vaxt istifadə etməli:</strong>Əsas əlaqənin mövcud olduğu proqrama xas problemlər</p>
<div class="info-box">
<strong>Misal:</strong>"Mən internetə baxa bilərəm, lakin şirkətin SharePoint saytına daxil ola bilmirəm."<p>Layer 7-dən başlayın (SharePoint xidməti işləyirmi? DNS IP-ni düzəltmək üçün həll edir?) və yalnız lazım olduqda işləyin.</p>
</div>
<h2>Qərar ağacı: qat 1, 2 və ya 3-dür?</h2>
<p>Hansı təbəqənin uğursuz olduğunu müəyyən etmək üçün bu sürətli diaqnostika ağacından istifadə edin:</p>
<div class="flowchart">
<div class="flowchart-step decision">
<strong>Localhost-a (127.0.0.1) ping edə bilərsinizmi?</strong>
</div>
<div class="flowchart-arrow">↓ NO</div>
<div class="flowchart-step danger">
<strong>Problem: Əməliyyat sistemi / proqram təminatı problemi</strong>
<p>TCP/IP yığını işləmir. OS xidmətlərini yoxlayın, şəbəkə sürücülərini yenidən quraşdırın.</p>
</div>
<div class="flowchart-arrow">↓ BƏLİ</div>
<div class="flowchart-step decision">
<strong>Öz IP ünvanınıza ping göndərə bilərsinizmi?</strong>
</div>
<div class="flowchart-arrow">↓ NO</div>
<div class="flowchart-step danger">
<strong>Problem: Layer 1/2 - Yerli Şəbəkə İnterfeysi</strong>
<p>NIC deaktiv edilib, səhv sürücü, kabel ayrılıb. Yoxlayın:<code>ip link show</code>və ya Cihaz meneceri</p>
</div>
<div class="flowchart-arrow">↓ BƏLİ</div>
<div class="flowchart-step decision">
<strong>Defolt şlüzdən ping edə bilərsinizmi?</strong>
</div>
<div class="flowchart-arrow">↓ NO</div>
<div class="flowchart-step danger">
<strong>Problem: Layer 1/2 - Yerli Şəbəkə</strong>
<p>Yoxlayın: Fiziki kabel, keçid portunun vəziyyəti, VLAN təyinatı, ARP cədvəli</p>
</div>
<div class="flowchart-arrow">↓ BƏLİ</div>
<div class="flowchart-step decision">
<strong>Siz IP ünvanı ilə uzaq hosta ping göndərə bilərsinizmi?</strong>
</div>
<div class="flowchart-arrow">↓ NO</div>
<div class="flowchart-step danger">
<strong>Problem: Layer 3 - Marşrutlaşdırma</strong>
<p>Yoxlayın: Marşrutlaşdırma cədvəli, firewall qaydaları, ACL. istifadə edin<code>traceroute</code>paketlərin harada dayandığını tapmaq üçün</p>
</div>
<div class="flowchart-arrow">↓ BƏLİ</div>
<div class="flowchart-step decision">
<strong>DNS (nslookup hostname) həll edə bilərsinizmi?</strong>
</div>
<div class="flowchart-arrow">↓ NO</div>
<div class="flowchart-step danger">
<strong>Problem: DNS konfiqurasiyası</strong>
<p>Yoxlayın: DNS server parametrləri, DNS serverinin mövcudluğu, firewall bloklama portu 53</p>
</div>
<div class="flowchart-arrow">↓ BƏLİ</div>
<div class="flowchart-step decision">
<strong>Tətbiq portuna (telnet host portu) çata bilərsinizmi?</strong>
</div>
<div class="flowchart-arrow">↓ NO</div>
<div class="flowchart-step danger">
<strong>Problem: Firewall / Port Bloklanması</strong>
<p>Yoxlayın: Firewall qaydaları, təhlükəsizlik qrupları, portda xidmət dinləmə</p>
</div>
<div class="flowchart-arrow">↓ BƏLİ</div>
<div class="flowchart-step success">
<strong>Şəbəkə qaydasındadır - Tətbiq Layeri Problemi</strong>
<p>Problem proqramın özündə, autentifikasiyada və ya proqram konfiqurasiyasındadır</p>
</div>
</div>
<h2>İzolyasiya üsulları</h2>
<p>Kök səbəb haqqında fərziyyəniz olduqda, onu təsdiqləmək və ya rədd etmək üçün bu izolyasiya üsullarından istifadə edin:</p>
<h3>1. Komponentləri sistematik şəkildə dəyişdirin</h3>
<div class="tip-box">
<strong>İpucu:</strong>Eyni anda BİR dəyişəni dəyişdirin. Həm kabeli, həm də keçid portunu dəyişdirsəniz, hansının onu düzəltdiyini bilməyəcəksiniz.</div>
<ul class="checklist">
<li>Yamaq kabelini yaxşı tanınan kabellə dəyişdirin</li>
<li>Fərqli keçid portunda test edin</li>
<li>Fərqli NIC (və ya USB şəbəkə adapteri) sınayın</li>
<li>Fərqli müştəri cihazından test edin</li>
<li>Fərqli VLAN/alt şəbəkəyə keçin</li>
</ul>
<h3>2. Çox Nöqtələrdə Paket Tutmaları</h3>
<p>Paketlərin harada atıldığını və ya dəyişdirildiyini müəyyən etmək üçün mənbədə, ara nöqtələrdə və təyinat yerində trafiki çəkin:</p>
<div class="command-box">
<code># 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
</code>
</div>
<h3>3. Geri Döngü Testi</h3>
<p>Bir cihaz daxilində əlaqəni sınamaqla xarici dəyişənləri aradan qaldırın:</p>
<div class="command-box">
<code># 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
</code>
</div>
<h3>4. Məlum-Yaxşı Əsas Müqayisələr</h3>
<p>Konfiqurasiya və davranışı işləyən sistemlə müqayisə edin:</p>
<div class="command-box">
<code># Compare interface settings
diff &lt;(ssh working-switch "show run int gi1/0/1") \
     &lt;(ssh broken-switch "show run int gi1/0/1")

# Compare routing tables
diff &lt;(ssh router1 "show ip route") \
     &lt;(ssh router2 "show ip route")
</code>
</div>
<h2>Problemlərin aradan qaldırılması zamanı sənədləşdirmə</h2>
<p>Düzgün sənədlər, fərqinə varmadan eyni şeyi dəfələrlə sınadığınız zaman dairəvi sazlamanın qarşısını alır.</p>
<h3>Problemlərin aradan qaldırılması şablonu</h3>
<div class="command-box">
<code><strong>Problem ID:</strong> TICKET-12345
<strong>Tarix/Saat:</strong> 2026-02-02 14:30 UTC
<strong>Xəbər verən:</strong> Jane Smith (jane.smith@company.com)
<strong>Təsirə məruz qalan istifadəçilər:</strong> ~50 users in Building A, 3rd floor
<strong>Simptom:</strong> Cannot access file server \\fileserver01

<strong>İlkin müşahidələr:</strong>
- 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

<strong>Görülən Testlər:</strong>
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

<strong>Kök Səbəb:</strong>
Dirty fiber connector on uplink between Building A floor switch
and distribution switch causing CRC errors and packet loss

<strong>Qətnamə:</strong>
Cleaned fiber connector with proper cleaning kit. CRC errors
dropped to zero. File server access restored.

<strong>Doğrulama:</strong>
Users confirmed file server accessible. Monitored for 15 minutes
with no errors.

<strong>Həll etmə vaxtı:</strong> 25 minutes
</code>
</div>
<div class="warning-box">
<strong>Niyə sənədləşmə vacibdir:</strong>Bu qeyd olmadan, növbəti dəfə kimsə həmin keçiddə CRC xətalarını görəndə, lif təmizliyini dərhal yoxlamaq əvəzinə kabelləri dəyişdirməyə və portları sınaqdan keçirməyə vaxt itirə bilər.</div>
<h2>Real-Dünya Case Studies</h2>
<h3>Case Study 1: "Şəbəkə Yavaşdır" (Əslində: TCP pəncərəsinin tükənməsi)</h3>
<div class="case-study">
<h3>Simptom</h3>
<p>Verilənlər bazası tətbiqinin cavab müddəti &lt;100ms-dən 5+ saniyəyə qədər azaldı. Tətbiq qrupu "şəbəkə gecikməsini" günahlandırdı.</p>
<h3>İlkin Fərziyyələr (Yanlış)</h3>
<ul>
<li>Şəbəkə sıxlığı</li>
<li>WAN linki doymuşdur</li>
<li>Firewall darboğazı</li>
</ul>
<h3>Diaqnostik Proses</h3>
<ol>
<li><strong>Ping testi:</strong>RTT = 2ms (əla, Layer 3 gecikməsini istisna edir)</li>
<li><strong>Bant genişliyi testi (iperf):</strong>1 Gbps keçiddə 950 Mbps (tıxac yoxdur)</li>
<li><strong>Paket tutma:</strong>Verilənlər bazası serverindən aşkar edilmiş TCP Sıfır Pəncərə paketləri</li>
<li><strong>Server yoxlaması:</strong>Verilənlər bazası server buferləri qəbul edir = 64KB (kiçik!)</li>
</ol>
<h3>Kök Səbəb</h3>
<p>Database server OS buferləri yüksək bant genişliyi × gecikmə məhsulu üçün çox kiçik idi. TCP pəncərəsi doldurularaq göndəricini gözləməyə məcbur edir.</p>
<h3>Qətnamə</h3>
<div class="command-box">
<code># Increased TCP receive buffers on Linux database server
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sysctl -w net.core.rmem_max=16777216
</code>
</div>
<h3>Öyrənilən Dərs</h3>
<p><strong>Güman etmə:</strong>"Yavaş" həmişə "şəbəkə gecikməsi" demək deyil. Nəticələrə keçməzdən əvvəl həmişə sübut toplayın (gecikmə üçün ping, davranış üçün paket tutma).</p>
</div>
<h3>Case Study 2: Fasiləli Bağlantı (Əslində: Dupleks Uyğunsuzluq)</h3>
<div class="case-study">
<h3>Simptom</h3>
<p>Xüsusilə yük altında server bağlantısı təsadüfi olaraq düşərdi. Bəzən yaxşı işləyir, bəzən tamamilə cavab vermir.</p>
<h3>İlkin Fərziyyələr (Yanlış)</h3>
<ul>
<li>Uğursuz NIC</li>
<li>Səhv kabel</li>
<li>Avadanlıq problemini dəyişdirin</li>
</ul>
<h3>Diaqnostik Proses</h3>
<ol>
<li><strong>İnterfeys yoxlaması:</strong>Server NIC = 1000/Tam, keçid portu = 1000/Yarım (uyğunsuzluq!)</li>
<li><strong>Səhv sayğacları:</strong>Switch portunda kütləvi toqquşma sayı</li>
<li><strong>Gec toqquşmalar:</strong>Dupleks uyğunsuzluğunun göstəricisi</li>
</ol>
<h3>Kök Səbəb</h3>
<p>Avtomatik danışıqlar uğursuz oldu. Server tam dupleksə razılaşdı, keçid yarım dupleksə geri döndü. Toqquşmalar yalnız hər iki tərəf eyni vaxtda ötürməyə cəhd etdikdə yük altında baş verdi.</p>
<h3>Qətnamə</h3>
<div class="command-box">
<code>! Cisco switch - force full duplex
interface GigabitEthernet1/0/10
 speed 1000
 duplex full
</code>
</div>
<h3>Öyrənilən Dərs</h3>
<p><strong>Hər iki ucunu yoxlayın:</strong>İnterfeys statusu razılaşdırılmış parametrləri göstərir. Uyğunsuzluq avtomatik danışıqların uğursuz olması deməkdir. Serverlər üçün həmişə sabit kod sürəti/dupleks.</p>
</div>
<h3>Case Study 3: "Müəyyən veb saytlara daxil ola bilməz" (Əslində: MTU/PMTUD Qara Dəlik)</h3>
<div class="case-study">
<h3>Simptom</h3>
<p>İstifadəçilər bəzi vebsaytlara (Google, Yahoo) baxa bilər, digərlərinə isə yox (bank veb-saytı, şirkət portalı). Kiçik HTTP sorğuları işlədi, böyük səhifələrin vaxtı bitdi.</p>
<h3>İlkin Fərziyyələr (Yanlış)</h3>
<ul>
<li>DNS problemi</li>
<li>Firewall xüsusi saytları bloklayır</li>
<li>ISP marşrutlaşdırma problemi</li>
</ul>
<h3>Diaqnostik Proses</h3>
<ol>
<li><strong>DNS həlli:</strong>Bütün saytlar üçün yaxşı işləyir</li>
<li><strong>Ping testi:</strong>"Əlçatmaz" saytlara ping göndərə bilər</li>
<li><strong>Kiçik HTTP sorğusu (qıvrılma):</strong>Kiçik səhifələr üçün işləyir</li>
<li><strong>Böyük yükləmə:</strong>TCP əl sıxmasından sonra dayanır</li>
<li><strong>MTU testi:</strong> <code>ping -M do -s 1472</code>uğur qazanır,<code>ping -M do -s 1473</code>uğursuz olur</li>
<li><strong>ICMP monitorinqi:</strong>"Fraqmentasiyaya ehtiyac yoxdur" (Tip 3 Kod 4) mesajı alınmadı</li>
</ol>
<h3>Kök Səbəb</h3>
<p>VPN tuneli MTU-nu 1400-ə endirdi, lakin firewall ICMP "Fragmentation Needed" mesajlarını bloklayırdı. Path MTU Discovery (PMTUD) işləyə bilmədi və MTU qara dəliyi yaratdı. Kiçik paketlər uyğun gəlir, DF bit dəsti olan böyük paketlər səssizcə atılır.</p>
<h3>Qətnamə</h3>
<div class="command-box">
<code>! 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
</code>
</div>
<h3>Öyrənilən Dərs</h3>
<p><strong>Ölçü vacibdir:</strong>Kiçik sorğular işləyirsə, lakin böyük köçürmələr uğursuz olarsa, MTU/parçalanma problemlərindən şübhələnirsiniz. MTU yolunu sınamaq üçün DF biti ilə pingdən istifadə edin.</p>
</div>
<h3>Case Study 4: VoIP Keyfiyyət Problemləri (Əslində: QoS Yanlış Konfiqurasiyası)</h3>
<div class="case-study">
<h3>Simptom</h3>
<p>Səsli zənglərin səsi kəsildi, fasilələrlə kəsildi. Yalnız iş saatlarında (9: 00-17: 00) baş verdi.</p>
<h3>İlkin Fərziyyələr (Yanlış)</h3>
<ul>
<li>Qeyri-kafi bant genişliyi</li>
<li>VoIP server həddən artıq yüklənib</li>
<li>ISP əlaqə keyfiyyəti</li>
</ul>
<h3>Diaqnostik Proses</h3>
<ol>
<li><strong>Bant genişliyi testi:</strong>Link yalnız 40% məşğul saatda istifadə olunur</li>
<li><strong>QoS yoxlaması:</strong>Səs trafiki DSCP EF (46) ilə düzgün qeyd edilmişdir</li>
<li><strong>Növbə yoxlaması:</strong>Səs növbəsi yalnız 5% bant genişliyinə malik idi (33% olmalıdır)</li>
<li><strong>Paket tutma:</strong>Sıxlıq zamanı səs paketləri atılır</li>
</ol>
<h3>Kök Səbəb</h3>
<p>QoS siyasəti mövcud idi, lakin bant genişliyi bölgüsü geri idi: ən yaxşı səy 60%, səs 5% aldı. Məlumat trafikinin artdığı iş saatlarında növbənin daşması səbəbindən səs paketləri kəsildi.</p>
<h3>Qətnamə</h3>
<div class="command-box">
<code>! 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
</code>
</div>
<h3>Öyrənilən Dərs</h3>
<p><strong>Zamana əsaslanan məsələlər = tutum:</strong>Problemlər yalnız məşğul saatlarda baş verirsə, bu, çətin bir uğursuzluq deyil, tutum/QoS problemidir. Yalnız ümumi bant genişliyini deyil, növbə statistikasını yoxlayın.</p>
</div>
<h2>Simptomla əmr istinadı</h2>
<table>
<thead>
<tr>
<th>Simptom</th>
<th>Qat</th>
<th>Run əmrləri</th>
<th>Nə axtarmaq lazımdır</th>
</tr>
</thead>
<tbody>
<tr>
<td>Bağlantı işığı yoxdur</td>
<td>Qat 1</td>
<td><code>show interfaces<br/>ethtool eth0</code></td>
<td>Vəziyyəti: aşağı, operator yoxdur, kabel ayrılıb</td>
</tr>
<tr>
<td>Paket itkisi</td>
<td>Qat 1/2</td>
<td><code>show interfaces<br/>show interfaces counters errors</code></td>
<td>CRC səhvləri, qaçışlar, nəhənglər, toqquşmalar, gec toqquşmalar</td>
</tr>
<tr>
<td>Gateway ping etmək mümkün deyil</td>
<td>Qat 2</td>
<td><code>arp -a<br/>show mac address-table<br/>show spanning-tree</code></td>
<td>ARP girişi yoxdur, MAC öyrənilməyib, STP bloklanması</td>
</tr>
<tr>
<td>Uzaq alt şəbəkəyə daxil olmaq mümkün deyil</td>
<td>Qat 3</td>
<td><code>traceroute<br/>show ip route<br/>show ip route summary</code></td>
<td>Çatışmayan marşrut, səhv növbəti keçid, marşrutlaşdırma dövrəsi</td>
</tr>
<tr>
<td>Bağlantı rədd edildi</td>
<td>Qat 4</td>
<td><code>telnet host port<br/>netstat -an<br/>tcpdump</code></td>
<td>Xidmət dinlənmir, firewall bloku, TCP RST</td>
</tr>
<tr>
<td>Yavaş performans</td>
<td>Qat 4+</td>
<td><code>ping (RTT)<br/>iperf3<br/>tcpdump<br/>show interfaces</code></td>
<td>Yüksək gecikmə, bant genişliyi limiti, TCP təkrar ötürülməsi, sıfır pəncərə</td>
</tr>
<tr>
<td>Host adını həll etmək mümkün deyil</td>
<td>Qat 7</td>
<td><code>nslookup<br/>dig<br/>cat /etc/resolv.conf</code></td>
<td>DNS server əlçatmaz, səhv DNS konfiqurasiyası, NXDOMAIN</td>
</tr>
<tr>
<td>Fasiləli enişlər</td>
<td>Qat 1/2</td>
<td><code>ping -f (flood)<br/>show logging<br/>show interfaces</code></td>
<td>Dupleks uyğunsuzluğu, uğursuz kabel, STP rekonvergensiyası</td>
</tr>
<tr>
<td>Bəzən işləyir, başqaları deyil</td>
<td>Çoxsaylı</td>
<td><code>Extended ping<br/>Packet capture<br/>Interface statistics</code></td>
<td>Yük balansı problemi, ECMP asimmetriyası, vəziyyət cədvəlinin daşması</td>
</tr>
</tbody>
</table>
<h2>Nə vaxt artırılmalıdır</h2>
<p>Təchizatçı TAC və ya yüksək səviyyəli mühəndislərə nə vaxt yüksəldəcəyinizi bilin. Zaman artır:</p>
<ul class="checklist">
<li>Siz bilik bazanızda bütün problemlərin aradan qaldırılması addımlarını tamamladınız</li>
<li>Problem sizdə olmayan giriş/icazə tələb edir</li>
<li>Problem satıcının proqram təminatı səhvi və ya aparat çatışmazlığı ilə bağlıdır</li>
<li>Biznesə təsir kritik və zamana həssasdır</li>
<li>Birdən çox komanda əməkdaşlıq etməlidir (tətbiq + şəbəkə + server)</li>
</ul>
<div class="tip-box">
<strong>Artırmadan əvvəl:</strong>Sınadığınız hər şeyi sənədləşdirin. TAC mühəndislərinə addımlarınızı təkrarlamamaq üçün bu məlumat lazımdır. Daxil edin:<ul>
<li>Semptomun tam təsviri</li>
<li>Problemin başlandığı zaman qrafiki</li>
<li>Diaqnostik əmrlər işləyir və onların çıxışı</li>
<li>Konfiqurasiya ehtiyat nüsxələri</li>
<li>Paket çəkilişləri (əgər uyğundursa)</li>
<li>Artıq sınadığınız şey</li>
</ul>
</div>
<h2>Şəxsi Bilik Bazanızın Yaradılması</h2>
<p>Problemlərin aradan qaldırılması üçün hər bir sessiya öyrənmə fürsətidir. Şəxsi bilik bazası yaradın:</p>
<h3>1. Problemlərin aradan qaldırılması jurnalı yaradın</h3>
<div class="command-box">
<code># 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
</code>
</div>
<h3>2. Command Cheat Sheet qurun</h3>
<p>Problemlərin aradan qaldırılması zamanı tez istinad üçün tez-tez istifadə olunan əmrləri ssenari üzrə təşkil edin.</p>
<h3>3. Şəbəkənizi Sənədləşdirin</h3>
<ul>
<li>Topologiya diaqramları (Layer 2 və Layer 3)</li>
<li>IP ünvan sxemi sənədləri</li>
<li>VLAN tapşırıqları</li>
<li>Standart konfiqurasiyalar (şablonlar)</li>
<li>Məlum olan yaxşı əsaslar (problemlərdən əvvəl interfeys statistikası)</li>
</ul>
<h2>Qarşısının alınması üçün ümumi anti-naxışlar</h2>
<div class="danger-box">
<h3>❌ ETMƏYİN: Diaqnoz qoymadan təsadüfi dəyişikliklər edin</h3>
<p>Problemi anlamadan konfiqurasiyaların dəyişdirilməsi çox vaxt işləri daha da pisləşdirir və ya əsl problemi maskalayır.</p>
</div>
<div class="danger-box">
<h3>❌ ETMƏYİN: Şəbəkənin həmişə günahkar olduğunu düşün</h3>
<p>Çox vaxt "şəbəkə problemləri" tətbiq, server və ya müştəri tərəfi problemləridir. Günahı qəbul etməzdən əvvəl sübut toplayın.</p>
</div>
<div class="danger-box">
<h3>❌ ETMƏYİN: Problemlərin həlli addımlarınızı sənədləşdirməyə keçin</h3>
<p>Artıq etdiyiniz testləri təkrarlamaqla vaxt itirəcəksiniz və ya həmkarlarınıza nə sınadığınızı izah edə bilməyəcəksiniz.</p>
</div>
<div class="danger-box">
<h3>❌ ETMƏYİN: Fasiləvi problemlərə məhəl qoymayın</h3>
<p>Fasiləli problemlər tez-tez yaxınlaşan uğursuzluğun erkən xəbərdarlıq əlamətləridir. Tənqidi olmamışdan əvvəl onları araşdırın.</p>
</div>
<div class="danger-box">
<h3>❌ ETMƏYİN: Kök səbəblər əvəzinə simptomları aradan qaldırın</h3>
<p>Cihazı yenidən yükləmək xidməti bərpa edə bilər, lakin siz NİYƏ onu yenidən yükləməyə ehtiyac olduğunu öyrənməsəniz, problem təkrarlanacaq.</p>
</div>
<h2>Xülasə: Sistemli Problemlərin aradan qaldırılması Yoxlama Siyahısı</h2>
<div class="success-box">
<h3>✓ Başlamazdan əvvəl</h3>
<ul class="checklist">
<li>Beş əsas suala cavab verin (Nə dəyişdi? Kim təsirləndi? Daimi və ya fasiləli? Təkrarlana bilir? Qarşı tərəf nə görür?)</li>
<li>İlkin simptomları və istifadəçi hesabatlarını toplayın</li>
<li>Son dəyişiklikləri və ya təmiri yoxlayın</li>
</ul>
<h3>✓ Problemlərin aradan qaldırılması zamanı</h3>
<ul class="checklist">
<li>OSI təbəqələri ilə metodik şəkildə işləyin (aşağıdan yuxarıya və ya yuxarıdan aşağıya)</li>
<li>Test edərkən BİR dəyişəni dəyişdirin</li>
<li>Hər testi və onun nəticəsini sənədləşdirin</li>
<li>Həqiqi trafik davranışını görmək üçün paket çəkilişlərindən istifadə edin</li>
<li>Bilinən yaxşı əsaslarla müqayisə edin</li>
</ul>
<h3>✓ Həll edildikdən sonra</h3>
<ul class="checklist">
<li>Düzəlişin həqiqətən problemi həll etdiyini yoxlayın</li>
<li>Əsas səbəb və həlli sənədləşdirin</li>
<li>Bilik bazanızı yeniləyin</li>
<li>Konfiqurasiya dəyişdirilərsə, sənədləri yeniləyin</li>
<li>Düşünün: Monitorinq bunu daha əvvəl tuta bilərdimi?</li>
</ul>
</div>
<h2>Nəticə</h2>
<p>Şəbəkə problemlərinin həlli həm elm, həm də sənətdir. Elm sistematik metodologiyaya riayət edir, diaqnostika vasitələrindən düzgün istifadə edir və protokolları başa düşür. İncəsənət, simptomlara əsaslanaraq ilk olaraq hansı testlərin keçiriləcəyini bilmək, təcrübədən nümunələri tanımaq və nə vaxt artırılacağını bilməkdir.</p>
<p>Bu məqalədə göstərilən sistematik yanaşmaya əməl etməklə – düzgün suallar vermək, OSI modeli ilə metodik işləmək, addımlarınızı sənədləşdirmək və hər bir problemdən öyrənmək – siz problemlərin aradan qaldırılmasında daha səmərəli olacaq və vaxt itkisinə və səhv düzəlişlərə səbəb olan ümumi tələlərdən qaçacaqsınız.</p>
<p><strong>Unutmayın:</strong>Məqsəd sadəcə xidməti bərpa etmək deyil, NİYƏ uğursuz olduğunu başa düşməkdir ki, siz onun yenidən baş verməsinin qarşısını ala biləsiniz.</p>
<hr style="margin-top: 40px;"/>
<p style="text-align: center; color: #6c757d;">
<em>Son yeniləmə: 2 fevral 2026 | Müəllif: Baud9600 Texniki Komandası</em>
</p>
</div>