This episode lays the operational foundation: defining SLOs for VIP availability and failover time, drafting runbooks for HA incidents, and ensuring operational readiness for maintenance and infrastructure changes.

At this point you've built an HA that works. Episode 21 answers the harder question: how do you know the HA is working as promised? The answer is operationalization — measurable SLOs, tested runbooks, and readiness for maintenance.
This episode turns a technical project into a system managed with discipline. You'll set targets for VIP availability and failover time, write runbooks that can be followed under panic, and design maintenance procedures that don't sacrifice availability.
An SLO is a promise that can be measured. For HA, two key metrics:
First calculate your system's capability from the measurements in episode 15, then set targets below that capability so there's always headroom.
Measure availability from the outside, not from inside the nodes:
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_httpThe blackbox exporter configuration probes the VIP over TCP and HTTP. Uptime metrics from these probes become the basis for real SLO calculation, not just numbers on a document.
Convert probes into availability numbers:
availability = sukses / total_probe * 100
sli_failover = waktu_saat_vip_pindah - waktu_saat_node_matiA simple error budget: with a 99.95% target, maximum downtime is about 21.9 minutes per month. Track error budget consumption on the dashboard so the team knows where they stand against the promise.
A good runbook answers three questions: what happened, who acts, and what are the steps. An example structure:
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.A runbook with clearly numbered steps reduces panic during an incident. Keep it in the same repository as the configuration so it always stays in sync with topology changes.
A runbook that was never tested is fiction. Schedule a game day: shut down a node deliberately in staging, follow the runbook step by step, and record the obstacles that appear. Improve the runbook based on the findings so that when a real incident happens, the team is already used to it.
Changes to HA nodes must have a clear rollback procedure. Before touching a 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"The pre-flight keepalived -t ensures the configuration to be installed is valid, and the VIP check ensures HA is healthy before maintenance starts.
For zero downtime, maintain nodes one at a time:
With this sequence, there is never a moment when no node is ready to take over.
A summary of what should always be available:
Episode 21 completes the operational side of HA: measurable SLOs for VIP and failover, structured and practiced runbooks, and maintenance readiness that doesn't sacrifice availability. Your Keepalived is now managed to the same standard as any other production service.
Key takeaways:
In episode 22, the final episode, we cover production hardening and best practices — security and availability hardening checklists, disaster recovery drills and upgrade strategies, and documenting the Keepalived topology and its support boundaries.