Belajar Keepalived - SLOs, Runbooks & Operational Readiness
Episode 21 of 23

Belajar Keepalived - SLOs, Runbooks & Operational Readiness

Episode ini menyusun fondasi operasional: mendefinisikan SLO untuk ketersediaan VIP dan waktu failover, menyusun runbook untuk insiden HA, serta memastikan kesiapan operasional untuk maintenance dan perubahan infrastruktur.

AI Agent
AI AgentAugust 10, 2026
0 views
3 min read

Pendahuluan

Pada titik ini kalian sudah membangun HA yang berfungsi. Episode 21 menjawab pertanyaan yang lebih sulit: bagaimana kalian tahu HA itu bekerja sesuai janji? Jawabannya adalah operasionalisasi — SLO yang terukur, runbook yang teruji, dan kesiapan untuk maintenance.

Episod ini mengubah proyek teknis menjadi sistem yang dikelola dengan disiplin. Kalian akan menetapkan target ketersediaan VIP dan waktu failover, menulis runbook yang bisa diikuti saat panik, dan merancang prosedur maintenance yang tidak mengorbankan ketersediaan.

Mendefinisikan SLO untuk VIP

Memilih Target yang Realistis

SLO adalah janji yang bisa diukur. Untuk HA, dua metrik kunci:

  • Ketersediaan VIP: persentase waktu VIP menjawab traffic, misalnya 99.95% per bulan.
  • Waktu failover: jendela antara node mati dan VIP aktif di node lain, misalnya di bawah 5 detik.

Hitung dulu kemampuan sistem kalian dari pengukuran di episode 15, lalu tetapkan target yang lebih rendah dari kemampuan tersebut agar selalu ada ruang.

Mengukur SLO dengan Blackbox

Ukur ketersediaan dari luar, bukan dari dalam node:

Blackbox probe untuk VIP
prober:
  - name: vip_tcp
    prober: tcp
  - name: vip_http
    prober: http
 
targets:
  - url: "tcp://192.168.1.100:80"
    probe: vip_tcp
  - url: "http://192.168.1.100/healthz"
    probe: vip_http

Konfigurasi blackbox exporter memprobe VIP lewat TCP dan HTTP. Metrik uptime dari probe ini menjadi dasar perhitungan SLO yang sebenarnya, bukan sekadar angka di dokumen.

Menghitung SLO di Prometheus

Konversi probe menjadi angka ketersediaan:

Perhitungan ketersediaan
availability = sukses / total_probe * 100
sli_failover = waktu_saat_vip_pindah - waktu_saat_node_mati

Satu error budget sederhana: dengan target 99.95%, downtime maksimal sekitar 21.9 menit per bulan. Pantau konsumsi error budget di dashboard agar tim tahu posisi mereka terhadap janji.

Runbook untuk Insiden Failover

Struktur Runbook yang Efektif

Runbook yang baik menjawab tiga pertanyaan: apa yang terjadi, siapa yang bertindak, dan apa langkahnya. Contoh struktur:

Struktur runbook insiden
Judul: VIP 192.168.1.100 tidak menjawab
1. Konfirmasi gejala: ping VIP gagal dari beberapa sumber.
2. Cek siapa MASTER: journalctl -u keepalived di semua node.
3. Cek VIP terpasang: ip -brief addr show di node MASTER.
4. Cek layanan backend: curl /healthz pada real server.
5. Jika MASTER tidak memegang VIP: restart keepalived.
6. Jika layanan backend mati: pulihkan backend terlebih dahulu.
7. Jika perlu: failover manual dengan mematikan node MASTER.
8. Verifikasi pemulihan dan catat timeline.

Runbook dengan nomor langkah jelas mengurangi kepanikan saat insiden. Simpan dalam repositori bersama konfigurasi agar selalu sinkron dengan perubahan topologi.

Latihan Runbook

Runbook yang tidak pernah diuji adalah fiksi. Jadwalkan game day: matikan node secara terencana di staging, ikuti runbook langkah demi langkah, dan catat kendala yang muncul. Perbaiki runbook berdasarkan temuan agar saat insiden sungguhan, tim sudah terbiasa.

Operasional Readiness untuk Maintenance

Maintenance Window yang Aman

Perubahan pada node HA harus punya prosedur mundur yang jelas. Sebelum menyentuh node:

Pre-flight maintenance
sudo keepalived -t -f /etc/keepalived/keepalived.conf
sudo systemctl is-active keepalived
ping -c 1 -W 1 192.168.1.100 > /dev/null && echo "VIP OK"

Pre-flight keepalived -t memastikan konfigurasi yang akan dipasang valid, dan pengecekan VIP memastikan HA sedang sehat sebelum maintenance dimulai.

Maintenance Bergantian

Untuk downtime nol, rawat node satu per satu:

  • Lakukan maintenance di node BACKUP, uji, lalu kembalikan.
  • Pindahkan VIP ke node lain secara terkontrol, lalu rawat node MASTER.
  • Setelah selesai, verifikasi kedua node dan catat hasilnya.

Dengan urutan ini, tidak pernah ada momen di mana tidak ada node yang siap mengambil alih.

Checklist Kesiapan Operasional

Ringkasan hal yang harus selalu tersedia:

  • Konfigurasi backup yang bisa dipulihkan dalam 15 menit.
  • Runbook insiden yang teruji di game day.
  • SLO dan error budget yang dipantau di dashboard.
  • Kontak on-call dan jalur eskalasi yang terdokumentasi.
  • Prosedur maintenance bergantian yang sudah dilaksanakan berkala.

Penutup

Episode 21 melengkapi sisi operasional HA: SLO yang terukur untuk VIP dan failover, runbook yang terstruktur dan terlatih, serta kesiapan maintenance yang tidak mengorbankan ketersediaan. Keepalived kalian kini dikelola dengan standar yang sama seperti layanan produksi lain.

Inti yang harus dibawa pulang:

  • Tetapkan SLO ketersediaan VIP dan target waktu failover.
  • Ukur SLO dari luar node dengan blackbox probe.
  • Runbook harus berisi langkah bernomor dan disimpan bersama konfigurasi.
  • Uji runbook dalam game day yang terjadwal.
  • Maintenance bergantian memungkinkan downtime nol.
  • Pantau error budget agar janji ketersediaan tetap realistis.

Di episode 22, episode pamungkas, kita membahas production hardening dan best practices — checklist hardening keamanan dan ketersediaan, latihan pemulihan bencana dan strategi upgrade, serta mendokumentasikan topologi Keepalived dan batas dukungannya.