Belajar Site Reliability Engineer - Network Reliability

#Pendahuluan

Ketika insiden terjadi, kalian sudah bisa memeriksa aplikasi, database, dan kapasitas. Tetapi ada satu lapisan yang sering terlupakan sampai ia benar-benar jatuh: jaringan. DNS yang tidak bisa resolve, sertifikat TLS yang kedaluwarsa di hari H, atau load balancer yang distribusinya miring — semuanya mematikan layanan tanpa ada satu baris kode pun yang berubah.

Jaringan adalah sistem terdistribusi terbesar yang kalian operasikan: ia terbentang dari resolver DNS, CDN, load balancer, hingga koneksi antar-pod. Episode 18 membahas keandalan lapisan-lapisan tersebut dan cara mengukurnya sebagai SLO — karena komponen yang tidak terukur adalah komponen yang tidak terkelola.

#DNS: Fondasi yang Paling Sering Diremehkan

DNS adalah bagian yang paling sulit dipulihkan karena kacaunya justru sering menyebar ke cache resolver pengguna. Beberapa prinsip keandalan DNS:

• Redundansi server nama di penyedia berbeda (dua penyedia, bukan dua zona di satu penyedia).
• TTL yang disengaja: TTL 30-60 detik untuk record yang harus cepat dipindah (failover, episode 16); TTL panjang untuk record stabil. TTL yang terlalu besar adalah kunci pas yang dikunci di dalam kotak — kalian tidak akan bisa menguncinya lagi dengan cepat saat darurat.
• Pantau dari luar, bukan dari dalam: ukur resolusi DNS dari beberapa lokasi geografis dan penyedia resolver, bukan hanya dari VPC kalian sendiri.
• DNSSEC untuk mencegah spoofing, dengan pemahaman bahwa salah konfigurasi DNSSEC bisa mematikan resolusi total.

#TLS: Sertifikat sebagai Beban Operasional

Insiden "certificate expired" adalah salah satu yang paling memalukan karena sepenuhnya bisa dicegah. Keandalan TLS adalah disiplin lifecycle:

1. Otomasi penuh — Let's Encrypt / cert-manager (episode 10) memperbarui sebelum kedaluwarsa; tidak ada sertifikat manual di server produksi.
2. Sertifikat internal juga — mesh dan internal TLS sering dilupakan karena tidak terlihat dari luar.
3. Alert sebelum kedaluwarsa — alert dengan jarak jauh sebelum hari-H: 30 hari, 7 hari, 1 hari.
4. Monitoring cipher & handshake — latensi handshake, kegagalan negotiasi, dan versi protocol.

cert-manager: sertifikat dengan auto-renew

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: api-example-tls
spec:
  secretName: api-example-tls
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer
  dnsNames:
    - api.example.com
    - www.example.com

#CDN & Load Balancer: Mendistribusikan Beban dan Latensi

CDN memindahkan konten dekat ke pengguna — mengubah latensi jaringan (yang tidak bisa dioptimasi di server) menjadi latensi yang sudah dijawab dari edge. Load balancer menjadi titik masuk yang membagi trafik ke banyak instance.

Keduanya punya satu bahaya umum: menjadi single point of failure dan titik buta observability. Jika semua request lewat satu entitas, kegagalan entitas itu menelan seluruh layanan — dan jika kalian hanya mengukur metrik di belakangnya, kalian tidak akan melihat kegagalan di depannya. Dua perbaikan wajib:

• Pantau dari sisi klien: ukur koneksi, status code, dan latensi dari titik sebelum masuk ke balancer (synthetic check), sehingga kalian tahu kapan entitas itu sendiri yang rusak.
• Redundansi lintas availability zone: balancer dan CDN penyedia yang sama punya zona kegagalan yang berbeda dari zona aplikasi — pahami di mana letaknya.

#Service Mesh: Reliabilitas Jaringan Sebagai Fitur Platform

Ketika jaringan internal tumbuh menjadi ratusan service, pola retry, timeout, circuit breaker (episode 21), dan mTLS yang ditulis manual di tiap aplikasi menjadi tidak terkendali. Service mesh (Istio, Linkerd) memindahkan pola-pola ini keluar dari aplikasi ke data plane proxy yang menyertainya.

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: checkout-vs
spec:
  hosts:
    - checkout
  http:
    - route:
        - destination:
            host: checkout
      timeout: 2s
      retries:
        attempts: 3
        retryOn: 5xx

Kekuatan mesh bukan pada fitur tunggalnya, tetapi pada sentralisasi kebijakan jaringan — kebijakan diubah satu kali untuk seluruh fleet, bukan diedit di seratus service. Kekurangannya adalah kompleksitas operasional dan biaya CPU setiap proxy; jangan pasang mesh sebelum kebutuhan nyata ada.

#Mengukur SLO Jaringan

SLO jaringan (episode 3) biasanya didefinisikan pada tiga lapisan:

Ukur dengan synthetic monitoring dari titik-titik nyata pengguna, ditambah metrik dari balancer dan mesh:

# SLI latensi p95 dari synthetic probes (contoh PromQL)
histogram_quantile(0.95,
  sum(rate(synthetic_probe_duration_seconds_bucket{probe="edge"}[5m]))
    by (le))

#Praktik: Mengamankan & Mengukur SLO Jaringan

1. Audit DNS: catat TTL semua record kritis; kecilkan TTL yang kemungkinan dipindah cepat saat failover.
2. Pasang alert kedaluwarsa TLS di semua domain dan sertifikat internal.
3. Tambahkan synthetic probe dari luar infrastruktur (misal Uptime Kuma yang sudah ada di setup episode 0) untuk DNS resolve + TLS handshake + HTTP status.
4. Tetapkan SLO jaringan untuk availability dan latency edge — misal availability 99.9%, p95 time-to-first-byte di bawah 300 ms.
5. Uji kegagalan balancer (dengan pola chaos episode 13) dan amati apakah traffic berpindah tanpa insiden.

#Penutup

Pada episode 18 ini, kalian telah belajar memperlakukan jaringan sebagai sistem yang dioperasikan, bukan kabel yang tak terlihat.

Inti yang harus dibawa pulang:

• DNS butuh redundansi antar-penyedia dan TTL kecil sejak awal.
• TLS adalah disiplin lifecycle: otomasi, alert awal, dan pemantauan dari luar.
• CDN & load balancer punya zona kegagalan sendiri yang harus diukur dari sisi klien.
• Service mesh menyentralkan kebijakan jaringan internal dengan harga kompleksitas yang harus dibayar sadar.
• Jaringan punya SLO-nya sendiri: availability, latency, dan correctness — diukur dari titik nyata.

Di episode 19 selanjutnya, kita akan menembus pertahanan: security & compliance ops — security monitoring, threat detection, dan audit kepatuhan dalam operasi. Sampai jumpa di episode 19!