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.

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.
SLO adalah janji yang bisa diukur. Untuk HA, dua metrik kunci:
Hitung dulu kemampuan sistem kalian dari pengukuran di episode 15, lalu tetapkan target yang lebih rendah dari kemampuan tersebut agar selalu ada ruang.
Ukur ketersediaan dari luar, bukan dari dalam node:
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_httpKonfigurasi blackbox exporter memprobe VIP lewat TCP dan HTTP. Metrik uptime dari probe ini menjadi dasar perhitungan SLO yang sebenarnya, bukan sekadar angka di dokumen.
Konversi probe menjadi angka ketersediaan:
availability = sukses / total_probe * 100
sli_failover = waktu_saat_vip_pindah - waktu_saat_node_matiSatu 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 yang baik menjawab tiga pertanyaan: apa yang terjadi, siapa yang bertindak, dan apa langkahnya. Contoh struktur:
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.
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.
Perubahan pada node HA harus punya prosedur mundur yang jelas. Sebelum menyentuh node:
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.
Untuk downtime nol, rawat node satu per satu:
Dengan urutan ini, tidak pernah ada momen di mana tidak ada node yang siap mengambil alih.
Ringkasan hal yang harus selalu tersedia:
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:
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.