Jaringan Kantor Tiba-tiba Bermasalah — Checklist Diagnosa untuk Tim IT

Jam kerja sedang berlangsung. Tiba-tiba ada laporan: tidak bisa buka website. Lalu laporan masuk dari ruangan lain. Email tidak terkirim. Aplikasi internal timeout. Rapat online di-disconnect mendadak. Di momen seperti ini, tim IT butuh satu hal yang sering hilang saat panik: metode diagnosa yang sistematis, bukan trial and error yang membakar waktu. Artikel ini adalah checklist yang langsung bisa kamu jalankan saat incident — disusun pakai pendekatan OSI bottom-up dan dikalibrasi dari pengalaman menangani gangguan jaringan di lingkungan institusi besar (kampus, kantor multi-lantai, instansi pemerintah).

Prinsip Diagnosa: OSI Layer dari Bawah ke Atas

Pendekatan paling efisien adalah cek dari layer paling bawah dulu. Masalah di layer 1 (fisik) tidak akan terdiagnosa kalau kamu langsung loncat ke layer 7 (aplikasi). Aturan ini sederhana tapi sering dilanggar tim IT saat panik — orang langsung restart aplikasi, padahal masalahnya di kabel atau switch.

ARAH DIAGNOSA — BOTTOM-UP
══════════════════════════════════════

  Layer 7 — Aplikasi (HTTP, email, Telegram)
      ↑
  Layer 4 — Transport (TCP/UDP timeout, port)
      ↑
  Layer 3 — Network (routing, IP, DNS, ICMP)
      ↑
  Layer 2 — Data Link (ARP, MAC, switch)
      ↑
  Layer 1 — Fisik (kabel, port, listrik, ONT)  ← MULAI DARI SINI

  → Mayoritas incident root cause di layer 1-3.
  → Loncat ke layer 7 = buang waktu kalau kabel longgar.

Fase 1 — Triase Awal (5 Menit Pertama)

Sebelum sentuh apapun, kumpulkan informasi. Dua pertanyaan kunci yang harus dijawab: siapa yang terdampak (scope) dan pola gejalanya seperti apa (pattern). Jawaban dua pertanyaan ini menentukan 70% arah investigasi.

Pertanyaan Scope

Pertanyaan Pattern

Pertanyaan terakhir tentang hotspot HP adalah litmus test paling kuat untuk membedakan masalah internal vs eksternal. Kalau hotspot bisa, masalah di jaringan internal. Kalau hotspot juga tidak bisa, masalah di tujuan (website target down) atau ada filter regional.

Tabel Clue Berdasarkan Jawaban

Fase 2 — Cek Layer Fisik dan Link (Layer 1-2)

Cek Status Fisik Perangkat

Cek ARP Table Switch

ARP table penuh adalah salah satu penyebab paling sering luput dalam incident jaringan kantor besar. Sidik jari khasnya: masalah muncul tiba-tiba, restart switch langsung memperbaiki, tidak ada perubahan konfigurasi sebelumnya. Untuk deep dive penyebab dan solusi permanen, lihat ARP Table Switch Penuh — Diagnosa & Solusi.

# Cisco / Catalyst
show ip arp summary
show ip arp | count

# Ruijie RG (umum di kampus Indonesia)
show arp
show arp statistics

# MikroTik (router-as-switch)
/ip arp print count-only

# HP / Aruba
show arp
show ip arp

Jika count mendekati atau melebihi kapasitas hardware, clear dulu lalu monitor. Solusi cepat (membeli waktu, bukan permanen):

# Cisco / Ruijie
clear arp-cache

# MikroTik
/ip arp flush

# HP / Aruba
clear arp-cache

Cek Loop dan Broadcast Storm

Jika lampu switch berkedip sangat cepat di banyak port secara bersamaan, kemungkinan ada loop di jaringan — biasanya akibat kabel yang dicolok dua kali ke switch yang sama tanpa STP, atau hub murah yang nyangkut di antara dua switch managed. Cek apakah Spanning Tree Protocol (STP) aktif. Cabut kabel mencurigakan satu per satu sambil monitor — saat lampu kembali normal, kamu menemukan port pelakunya.

Fase 3 — Cek Layer Network (Layer 3)

3.1 Cek Koneksi Router ke ISP

Ping dari router ke gateway ISP. Jika packet loss tinggi atau timeout, masalah ada di koneksi ke ISP atau perangkat ISP (modem/ONT) — bukan di sisi internal kamu.

# MikroTik
/tool ping [IP gateway ISP] count=20

# Cisco
ping [IP gateway ISP] repeat 20

# Linux/Mac (kalau bisa SSH ke router/server)
ping -c 20 [IP gateway ISP]

3.2 Cek DNS Resolver

DNS yang stuck di cache stale adalah silent killer incident jaringan kantor — speed test normal, ping IP lancar, tapi browsing dan aplikasi banyak yang gagal. Perintah cek + flush:

# MikroTik — cek konfigurasi & cache
/ip dns print
/ip dns cache print

# Test resolve dari MikroTik
/tool dns-lookup google.com
/tool dns-lookup [domain yang bermasalah]

# Flush kalau DNS-related
/ip dns cache flush

Untuk verifikasi independen dari perspektif eksternal (apakah domain memang resolve dengan benar di internet luas), pakai DNS Lookup Tool cekipsaya.com dari komputer yang masih bisa akses internet (misalnya via hotspot HP).

3.3 Cek IP Publik Masuk Blacklist

Ini sering terlewat tapi dampaknya besar. Gejala khas: beberapa layanan tidak bisa diakses (email server, Telegram, website pemerintah, VoIP), tapi layanan lain masih normal. Speed test biasanya tetap kelihatan bagus karena server speed test tidak filter blacklist.

Atau lewat terminal:

# Cek IP publik dari MikroTik
/tool fetch url="https://api.ipify.org" output=user

# Dari komputer user
curl ifconfig.me
curl https://cekipsaya.com/api/ip

Jika IP publik masuk blacklist, untuk action steps lengkap (ganti IP, delisting per database, audit penyebab) lihat IP Publik Masuk Blacklist — Cek & Solusi. Untuk pemahaman dasar kenapa IP bisa kena blacklist, lihat Kenapa IP Masuk Blacklist.

3.4 Traceroute ke Destination yang Bermasalah

Traceroute menunjukkan di hop mana packet mulai timeout — ini menjawab "masalahnya di mana" dalam jalur routing.

# MikroTik
/tool traceroute [IP atau domain tujuan]

# Linux/Mac
traceroute -n [IP atau domain]
mtr -rwbzc 30 [IP atau domain]   # MTR — lebih kaya data

# Windows
tracert [IP atau domain]

Untuk traceroute dari server eksternal (sebagai pembanding sisi internal vs eksternal), pakai Traceroute Tool cekipsaya.com. Untuk interpretasi MTR (kapan jitter dianggap normal vs abnormal, threshold StDev/Wrst, kapan boleh komplain ke ISP) baca pillar lengkap: Threshold Normal MTR — Cara Baca StDev & Wrst.

Fase 4 — Cek Koneksi End-to-End (Layer 4-7)

4.1 Ping Bertahap untuk Isolasi

Pendekatan klasik tapi efektif — ping ke titik berbeda untuk mempersempit lokasi masalah:

# Dari komputer user
ping 192.168.1.1     # gateway lokal
ping 8.8.8.8         # IP publik (tanpa DNS)
ping 1.1.1.1         # IP publik alternatif
ping google.com      # test DNS + koneksi
ping cekipsaya.com   # test ke server Indonesia

Untuk ping dari server eksternal sebagai pembanding (apakah masalah benar-benar di sisi kamu atau di tujuan), pakai Ping Tool cekipsaya.com.

4.2 Cek Port Spesifik

Jika layanan tertentu tidak bisa diakses padahal ping ke domain-nya OK, masalahnya di layer port/aplikasi. Test port spesifik:

# Linux/Mac
nc -zv [domain] [port]
nc -zv smtp.gmail.com 587

# Windows (PowerShell)
Test-NetConnection -ComputerName [domain] -Port [port]

# Telnet (universal, kalau tersedia)
telnet [domain] [port]

Untuk verifikasi port dari sisi eksternal (apakah server target memang menerima koneksi di port itu), pakai Port Checker Tool cekipsaya.com. Catatan: kalau port 25 (SMTP) yang diblokir, biasanya karena ISP residensial memang block default — bukan masalah jaringan kamu.

Checklist Sebelum Hubungi ISP

Mayoritas incident (sekitar 70% dari pengamatan lapangan) ternyata bersumber dari sisi internal — bukan ISP. Menelpon ISP duluan tanpa data konkret = waktu terbuang menunggu balasan, padahal masalahnya di switch atau DNS sendiri. Lakukan 8 cek ini dulu sebelum kontak NOC ISP:

Kalau dari 8 item ini ada yang abnormal, fokus selesaikan dulu sebelum kontak ISP. Kalau semua 8 normal tapi internet tetap bermasalah, kamu punya bukti konkret untuk eskalasi ke ISP — sertakan hasil traceroute dan jam mulai incident saat membuka tiket NOC.

Fase 5 — Eskalasi dan Dokumentasi

Yang Disertakan Saat Hubungi NOC ISP

Quick Reference: Perintah Darurat

Simpan blok ini untuk referensi cepat saat incident — semua perintah yang sering dipakai dalam satu tempat.

# ════════ SWITCH ════════
clear arp-cache                  # Cisco / Ruijie / HP

# ════════ MIKROTIK ════════
/ip dns cache flush              # DNS resolver
/ip arp flush                    # ARP table
/tool ping 8.8.8.8 count=10      # internet check
/tool traceroute 8.8.8.8         # routing check
/tool dns-lookup google.com      # DNS resolve
/tool fetch url="https://api.ipify.org" output=user   # IP publik
/ip dns print                    # config DNS
/ip dns cache print              # isi cache

# ════════ WINDOWS (di komputer user) ════════
ipconfig /flushdns               # DNS cache
ipconfig /release && ipconfig /renew   # DHCP renew
curl ifconfig.me                 # IP publik
ping 8.8.8.8                     # internet
ping google.com                  # DNS + internet
tracert 8.8.8.8                  # routing

# ════════ LINUX/MAC (server, admin laptop) ════════
sudo systemd-resolve --flush-caches   # DNS cache (Linux)
sudo dscacheutil -flushcache          # macOS
curl https://cekipsaya.com/api/ip     # IP publik dari API kamu sendiri
mtr -rwbzc 30 [tujuan]                # MTR — kaya data jitter

Pelajaran dari Incident Nyata — Timeline Studi Kasus

Berikut timeline anonim dari incident nyata di institusi besar (kampus dengan ~3000 endpoint aktif). Bukan untuk dramatisasi — untuk menunjukkan bahwa incident besar sering melibatkan multiple root cause yang trigger satu sama lain, dan satu solusi saja tidak cukup.

Pelajaran utama dari timeline ini: kalau hanya selesaikan satu masalah, layanan tetap rusak. Ketiga root cause (IP blacklist, ARP overflow, DNS cache stale) saling memperkuat gejala. Tim IT yang stop diagnosa di root cause pertama akan mengira "sudah resolved" padahal masih banyak user terdampak. Pendekatan checklist sistematis menjamin tidak ada yang terlewat.

Template Laporan Incident untuk Manajemen

Setelah incident resolved, dokumentasi adalah fase paling sering di-skip — padahal nilainya tinggi. Laporan yang baik mempercepat resolve incident berikutnya, jadi bahan training tim baru, dan jadi argumen kuat saat minta budget untuk preventive measures (upgrade switch, monitoring tools, dst). Template di bawah siap-pakai — tinggal isi field-field-nya:

════════════════════════════════════════════
  LAPORAN INCIDENT JARINGAN — [INSTITUSI]
════════════════════════════════════════════

Ticket ID            : INC-2026-XXX
Kategori             : [Network Outage / Performance Degradation / Security]
Severity             : [P1 Critical / P2 High / P3 Medium / P4 Low]
Status               : [Resolved / Mitigated / In Progress]

──── TIMELINE ────
Waktu mulai          : [YYYY-MM-DD HH:MM WIB]
Waktu pertama lapor  : [YYYY-MM-DD HH:MM WIB]
Waktu pertama aksi   : [YYYY-MM-DD HH:MM WIB]
Waktu resolved       : [YYYY-MM-DD HH:MM WIB]
Durasi mitigasi      : [berapa menit]
Durasi total         : [berapa jam]

──── SCOPE ────
User terdampak       : [estimasi jumlah / persen]
Lokasi terdampak     : [gedung, lantai, ruangan]
Layanan terdampak    : [list konkret: email, web, internal app, dst]
Layanan tetap normal : [list — penting untuk pattern analysis]

──── DIAGNOSA ────
Gejala utama         : [deskripsi konkret apa yang user alami]
Pattern              : [intermittent / total down / spesifik layanan]
Fase deteksi tercepat: [Fase X — apa yang trigger awareness]
Tools yang dipakai   : [traceroute, mtr, blacklist checker, dst]

──── ROOT CAUSE ────
Root cause primer    : [satu hal yang paling fundamental]
Root cause sekunder  : [trigger atau aggravating factors]
Kenapa lolos monitoring sebelumnya: [analisis blind spot]

──── SOLUSI ────
Mitigasi cepat       : [apa yang membuat layanan kembali]
Fix permanen         : [apa yang dilakukan setelah resolve untuk cegah berulang]
Waktu deploy fix     : [kapan]

──── PREVENTIF ────
Monitoring tambahan  : [alert / dashboard yang akan dipasang]
Audit berkala        : [jadwal cek ARP / blacklist / DNS]
Upgrade infrastruktur: [kalau perlu — argumen budget]
Training tim         : [knowledge gap yang ditemukan]

──── LESSONS LEARNED ────
Apa yang berjalan baik    : [proses yang efektif]
Apa yang bisa lebih cepat : [hambatan, eskalasi yg lambat]
Knowledge gap             : [topik yang tim belum kuasai]
Dokumentasi yang dibuat   : [link ke runbook / KB internal]

──── DAMPAK BISNIS ────
Produktivitas       : [estimasi jam-orang yang hilang]
Layanan eksternal   : [client/mahasiswa/customer yang affected]
Reputasi            : [keluhan eksternal, public-facing impact]

Dibuat oleh         : [nama, jabatan]
Reviewed oleh       : [kepala unit IT]
Distribusi          : [manajemen, tim IT, arsip]

Tip praktis: simpan template ini sebagai file incident-template.md di repo internal tim IT (Git, Confluence, atau drive bersama). Saat incident terjadi, copy file ini ke folder incidents/2026/ dengan timestamp dan langsung mulai isi sambil incident berlangsung — jangan tunggu selesai. Memori detail menghilang dengan cepat setelah resolve.

Tiga Musuh yang Sering Muncul Bersamaan

Pengamatan dari incident di lingkungan kampus & kantor besar: tiga masalah berikut sering muncul bersamaan dalam satu incident, saling memperkuat. Selalu cek ketiganya, jangan cuma satu:

Mindset: Sistematis Lebih Cepat dari "Cepat-cepatan"

Saat incident, kepala penuh tekanan dari user dan manajemen. Insting alami adalah lompat ke aksi — restart ini, ganti itu. Tapi dari pengamatan: tim yang resolve lebih cepat justru tim yang mulai dengan 5 menit triase tenang. Aksi tanpa data malah memperburuk (restart switch yang salah, flush DNS yang sebenarnya tidak masalah, hubungi ISP padahal masalah internal).

Checklist ini bukan tentang kelambatan — ini tentang tidak buang waktu. Setiap fase dijalankan cepat (10-15 menit per fase untuk skenario sedang) tapi thorough. Mayoritas incident resolve di Fase 2-3. Yang lolos sampai Fase 4-5 biasanya kompleks dan butuh eskalasi vendor.

FAQ — Pertanyaan yang Sering Ditanyakan

Kesimpulan

Saat jaringan kantor tiba-tiba bermasalah, satu hal membedakan tim IT yang resolve cepat dari yang panik berjam-jam: metode. Pendekatan OSI bottom-up (layer 1 → 7) eliminasi blind spot. Triase 5 menit awal jawab "scope siapa terdampak" dan "pattern gejalanya apa" — ini menentukan 70% arah investigasi. Sebelum telepon ISP, lakukan checklist 8 item internal dulu — mayoritas incident ternyata di sisi sendiri. Tiga musuh yang sering muncul bersamaan dalam incident besar: IP publik masuk blacklist, ARP table switch penuh, dan DNS cache stale di MikroTik — atasi semuanya, bukan satu saja, untuk resolusi penuh. Setelah resolve, isi template laporan incident agar pelajaran tersimpan dan tim bisa lebih cepat di kejadian berikutnya.