Situs Lambat Hanya dari Jaringan Telkomsel Setelah Pindah CDN, Apa Isi Eskalasinya?

Situs baru saja dipindah ke CDN yang punya node edge di Indonesia. Hasilnya bagus dari kantor, dari IndiHome rumah, dan dari VPS monitoring. Tapi tiket mulai masuk dengan pola yang sama: lambat, dan hampir semua pelapornya pakai Telkomsel. Tim support tahu ini harus dieskalasi ke provider CDN, tapi bingung data apa yang perlu dikirim supaya tiketnya tidak dibalas "mohon lampirkan detail lebih lanjut". Kabar baiknya, data yang dibutuhkan provider CDN cukup spesifik dan bisa dikumpulkan dalam satu sesi dengan pelanggan. Kita telusuri dari gejala ke penyebab, sambil menyingkirkan hal-hal yang sering bikin salah arah.

Pastikan dulu ini memang masalah satu jaringan

Kalimat "lambat dari Telkomsel" itu masih asumsi. Bisa jadi kebetulan tiga pelapor pertama pakai Telkomsel, padahal masalahnya di halaman tertentu yang berat, atau di origin yang sedang sibuk di jam tertentu. Kalau belum memetakan pertanyaan dasar ke pelanggan, artikel pertanyaan pertama untuk keluhan lambat dari IndiHome atau Telkomsel membahas bagian itu, jadi di sini kita langsung ke pengumpulan data teknis. Yang perlu dibuktikan adalah identitas jaringan pelanggan, dan itu artinya ASN. ASN (Autonomous System Number) adalah nomor yang mengidentifikasi jaringan milik satu organisasi di internet. Provider CDN berpikir dalam satuan ASN, bukan nama merek. "Telkomsel" bagi mereka terlalu kabur, sedangkan nomor ASN langsung bisa dicocokkan dengan data peering dan pemetaan edge mereka. Perlu diingat, satu grup operator bisa punya beberapa ASN, misalnya untuk seluler dan untuk fixed broadband. Konteks yang sering beredar mengaitkan AS7713 dengan grup Telkom, tapi jangan dihafal. Cek dari IP pelanggan yang sebenarnya. Minta pelanggan membuka halaman pengecek IP publik apa saja dari perangkat yang mengalami lambat, lalu kirim IP-nya ke kita. Di jaringan seluler, IP ini sering berupa IP CGNAT yang dipakai bersama banyak pelanggan, dan itu tidak masalah. Yang kita butuhkan memang IP yang terlihat dari internet.

Resolver DNS menentukan edge mana yang didapat

Ini bagian yang paling sering terlewat, dan sering justru jadi penyebabnya. Banyak CDN memilih node edge berdasarkan lokasi resolver DNS yang bertanya, bukan lokasi pelanggan langsung. Kalau resolver operator terletak jauh dari pelanggan, atau CDN salah menebak lokasi resolver itu, pelanggan bisa diarahkan ke edge di kota atau negara lain. Sebagian resolver mengirim EDNS Client Subnet (potongan subnet pelanggan) supaya CDN bisa memilih lebih tepat, tapi tidak semua resolver melakukannya. Artinya ada tiga IP yang perlu kita catat dari sisi pelanggan: IP publik pelanggan, IP resolver yang benar-benar dipakai, dan IP edge yang dihasilkan DNS untuk domain kita. Kalau pelanggan pakai laptop yang di-tethering ke HP Telkomsel, perintah berikut bisa dijalankan dari situ:

BASH

# ASN dari IP publik pelanggan (ganti dengan IP yang dikirim pelanggan)
whois -h whois.cymru.com ' -v 203.0.113.10'

# IP resolver yang dipakai (yang terlihat dari sisi server otoritatif)
dig +short TXT o-o.myaddr.l.google.com

# IP edge yang didapat pelanggan untuk domain kita
dig +short www.example.com

IP resolver dari perintah kedua juga bisa dicek ASN-nya dengan perintah pertama. Kalau pelanggan di Indonesia tapi resolver-nya terlihat dari jaringan atau negara lain, itu temuan penting. Kalau pelanggan memakai resolver publik di HP-nya, catat juga, karena perilakunya bisa berbeda dengan resolver bawaan operator. Lalu bandingkan IP edge yang didapat pelanggan dengan IP edge yang kamu dapat dari jaringan yang normal. Kalau berbeda, berikutnya kita perlu tahu edge itu ada di mana.

Baca header respons edge dan pecah waktunya

Setiap respons dari CDN biasanya membawa header yang mengidentifikasi request tersebut: ID request, status cache (HIT, MISS, dan sejenisnya), dan sering juga kode lokasi PoP yang melayani. Nama headernya berbeda di tiap provider, jadi cek dokumentasi CDN yang dipakai. ID request dan kode PoP ini adalah dua hal paling berguna dalam eskalasi, karena tim CDN bisa langsung mencarinya di log internal mereka. Sekaligus, pecah waktu request supaya ketahuan lambatnya di tahap mana:

BASH

# Header respons dari edge
curl -sI https://www.example.com/

# Rincian waktu: DNS, koneksi TCP, TLS, byte pertama, total
curl -o /dev/null -s -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}
' https://www.example.com/

# Jalur ke edge, lewat TCP 443 supaya tidak tergantung ICMP (butuh root)
sudo mtr -rwzbc 100 -T -P 443 198.51.100.20

Cara membaca hasil curl kedua cukup sederhana karena nilainya kumulatif. Kalau connect sudah besar, masalahnya di jalur jaringan ke edge, entah edge-nya jauh atau rutenya muter. Kalau connect kecil tapi selisih ke ttfb besar, edge-nya dekat tapi lama menunggu respons, biasanya karena cache MISS dan edge harus mengambil dari origin. Jalankan beberapa kali, dan catat jamnya. Keluhan yang hanya muncul di jam ramai punya arti berbeda dengan yang lambat sepanjang hari. Untuk pelanggan Windows yang tidak punya mtr, tracert atau pathping masih lebih baik daripada tidak ada sama sekali. Hasilnya tidak selengkap mtr, tapi tetap menunjukkan jalurnya lewat mana.

Red herring yang sering bikin salah arah

Ada beberapa hal yang kelihatan seperti penyebab tapi biasanya bukan. Pertama, packet loss di hop tengah mtr. Banyak router membatasi balasan ICMP ke dirinya sendiri, jadi hop di tengah bisa terlihat loss tinggi padahal paket yang lewat aman. Yang dihitung adalah loss yang berlanjut sampai hop terakhir. Kalau hop terakhir bersih, loss di tengah tadi hampir pasti bukan masalah. Ini juga alasan kenapa mode TCP ke port 443 lebih bisa dipercaya untuk kasus web. Kedua, origin yang lambat. Kalau origin memang berat, semua jaringan akan merasakan saat cache MISS, bukan cuma Telkomsel. Uji origin langsung dengan curl --resolve ke IP origin dari jaringan normal. Kalau origin cepat dan dari jaringan lain juga cepat, origin bisa dicoret. Ketiga, cache yang dingin. Edge yang baru menerima traffic dari satu wilayah belum punya cache untuk banyak URL, jadi request awal pasti MISS. Ini biasanya membaik sendiri. Kalau status cache dari jaringan Telkomsel terus-terusan MISS untuk URL yang sama sementara dari jaringan lain HIT, itu tanda pelanggan diarahkan ke edge yang berbeda, dan kembali ke soal pemetaan tadi. Kalau gejalanya konten lama yang muncul dari satu ISP, bukan lambat, itu kasus lain yang dibahas di artikel konten lama dari satu ISP, purge atau eskalasi. Setelah tiga hal ini disingkirkan, penyebabnya biasanya mengerucut ke salah satu dari dua: pelanggan diarahkan ke edge yang salah (masalah pemetaan, sering terkait resolver), atau edge-nya benar tapi rute dari operator ke edge itu tidak optimal (masalah peering atau routing). Dua-duanya hanya bisa diperbaiki provider CDN, dan sering perlu koordinasi mereka dengan operator. Tugas kita adalah membuktikan yang mana.

Susun eskalasinya jadi satu paket

Eskalasi yang bisa langsung ditindaklanjuti berisi pembanding. Satu set data dari jaringan yang lambat dan satu set dari jaringan yang normal, ke URL yang sama, di jam yang berdekatan. Tanpa pembanding, tim CDN hanya melihat angka tanpa konteks. Format berikut bisa dipakai sebagai kerangka. Isinya contoh format, bukan data insiden nyata:

TEXT

Subjek: Latensi tinggi dari ASN <nomor> ke domain www.example.com

Domain/URL     : https://www.example.com/ (dan URL lain yang terdampak)
Waktu kejadian : <tanggal dan jam, dalam UTC>, berulang/terus-menerus

Sisi lambat (jaringan operator seluler)
  IP publik klien : <IP>  ASN: <nomor>
  IP resolver     : <IP>  ASN: <nomor>
  IP edge didapat : <IP>
  Header edge     : <ID request>, <kode PoP>, <status cache>
  Timing curl     : dns=.. connect=.. tls=.. ttfb=.. total=..
  mtr             : terlampir (TCP 443, 100 paket)

Sisi normal (jaringan pembanding)
  (isi field yang sama)

Yang sudah dicek
  - Origin diuji langsung dengan curl --resolve, respons normal
  - Loss di mtr hanya di hop tengah / berlanjut sampai hop akhir
  - Status cache dari sisi lambat: selalu MISS / campuran

Pertanyaan
  - Apakah ASN/resolver ini dipetakan ke PoP yang benar?
  - Apakah ada masalah rute atau peering dari ASN ini ke PoP tersebut?

Sertakan jam dalam UTC. Pelanggan sering menyebut jam lokal tanpa zona waktu, dan provider CDN akan mencocokkan dengan log mereka yang hampir pasti memakai UTC. Lampirkan output mtr dan curl utuh sebagai teks, bukan screenshot, supaya bisa dicari dan disalin. Satu hal kecil yang membantu: tulis kolom "yang sudah dicek" dengan jujur. Kalau origin belum diuji, bilang belum. Tim CDN akan lebih cepat bergerak kalau mereka tahu mana yang sudah dicoret dan tidak perlu mengulang dari nol.

Memastikan masalahnya benar-benar beres

Ketika provider CDN membalas bahwa pemetaan atau rute sudah diperbaiki, jangan langsung tutup tiket. Minta pelanggan yang sama mengulang tiga perintah DNS dan dua perintah curl tadi. Yang dicari adalah perubahan yang konkret: IP edge yang didapat berubah, kode PoP di header berubah ke lokasi yang lebih dekat, atau connect di timing curl turun jelas dibanding sebelumnya. Kalau perbaikannya di sisi DNS, ingat ada TTL, jadi hasil lama bisa masih tersimpan di resolver beberapa saat. Pola kerjanya sebenarnya sederhana. Ubah "lambat dari Telkomsel" jadi ASN, IP resolver, IP edge, header edge, timing, dan mtr, lalu letakkan bersebelahan dengan data dari jaringan yang normal. Simpan kerangka eskalasi tadi di catatan tim, supaya saat keluhan serupa datang lagi, L1 bisa langsung mengumpulkan data yang benar di percakapan pertama, tanpa harus bolak-balik ke pelanggan.