Belajar Site Reliability Engineer - Multi-Region & Disaster Recovery

#Pendahuluan

Di episode 15 kalian membuat satu service menjadi cepat. Namun ada satu kelas kegagalan yang tidak terselesaikan oleh optimasi apa pun: bencana yang mematikan seluruh environment — satu region cloud mati, pelepasan sertifikat yang salah, atau kegagalan provider penyedia. Saat itu terjadi, pertanyaan paling menyakitkan bukan "berapa cepat sistem pulih", melainkan "apakah kita pulih sama sekali?".

Disaster Recovery (DR) adalah sistem, bukan dokumen. Episode 16 membahas arsitektur multi-region, dua metrik yang menggerakkan semua keputusan (RTO & RPO), strategi failover, dan cara berlatih semuanya dengan DR drill — karena recovery yang tidak pernah dilatih adalah harapan yang berpura-pura menjadi rencana.

#RTO dan RPO: Dua Angka yang Menentukan Segalanya

Setiap keputusan DR dimulai dari dua angka:

Metrik	Arti	Analogi
RTO (Recovery Time Objective)	Waktu maksimum yang diperbolehkan sampai service pulih	Berapa lama toko boleh tutup
RPO (Recovery Point Objective)	Data maksimum yang boleh hilang	Seberapa basi data cadangan yang boleh diakui

Hubungannya sederhana dan mahal: semakin ketat RTO dan RPO, semakin rumit dan mahal arsitekturnya. RTO 4 jam memungkinkan restore dari backup; RTO 1 menit menuntut replikasi sinkron aktif di region kedua. Inilah contoh klasik trade-off yang sudah kalian kenal dari episode 4 — hanya saja kali ini lawan dari kecepatan bukanlah fitur, melainkan biaya.

Important

RTO dan RPO adalah keputusan bisnis, bukan keputusan teknis — ditetapkan bersama manajemen dan dicatat sebagai angka yang disetujui, bukan asumsi tim ops. DR yang dibangun tanpa dua angka ini tidak punya garis selesai: apa pun yang kalian bangun, tidak ada yang bisa mengatakannya cukup atau berlebihan.

#Arsitektur Multi-Region

Dua pola utama, dengan satu pertanyaan penentu: apakah lalu lintas boleh dialihkan ke region kedua dalam kondisi normal?

#Active-Active

Kedua region melayani trafik secara bersamaan, biasanya lewat routing berbasis lokasi pengguna (geo-DNS atau anycast). Cocok untuk service stateless dan data yang bisa dipartisi.

#Active-Passive (Warm Standby)

Region kedua hidup, data terus direplikasi, tetapi trafik normal tetap di region utama. Saat region utama gagal, trafik dialihkan. Lebih murah, tetapi failover membawa cutover risk — region pasif jarang diuji dengan trafik nyata.

100%

Perhatikan dua keputusan tersembunyi dalam diagram ini: DNS TTL menentukan seberapa cepat trafik bisa berpindah (jika TTL 5 menit, failover tercepat tetap menunggu 5 menit untuk sebagian pengguna), dan mode replikasi menentukan RPO (sinkron = RPO mendekati nol tapi latency tulis naik; asinkron = tulis cepat tapi RPO bisa menit).

#Failover: Tiga Level Kesiapan

Manual runbook — manusia menjalankan langkah yang terdokumentasi. Paling lambat, paling berisiko salah, dan paling tidak menuntut. Titik awal yang jujur.
Orchestrated (scripted) — langkah-langkah sudah menjadi script yang teruji (pola episode 14). Mengubah DNS, mempromosikan DB replica, menaikkan autoscaling. Manusia tetap memutuskan kapan, sistem mengerjakan bagaimana.
Automatic — deteksi kegagalan memicu failover tanpa manusia. Tercepat, tetapi paling berbahaya: failover otomatis yang salah arah (misalnya karena network partition, bukan karena region mati) bisa membuat split-brain.

Aturan praktis SRE: mulai dari runbook, otomasi yang teruji, dan baru pertimbangkan otomasi penuh setelah failover berhasil berkali-kali tanpa manusia.

#DR Drill: Recovery yang Dilatih

Rencana yang tidak pernah dijalankan adalah fiksi. DR drill mengubah rencana menjadi otot:

Tentukan skenario nyata, bukan teoretis: "region utama mati total selama 2 jam".
Tentukan metrik sukses sebelum mulai: failover selesai dalam X menit, data hilang maksimal Y detik, aplikasi lolos smoke test.
Jalankan failover sungguhan ke region standby — termasuk trafik nyata, bukan sekadar memutar database.
Ukur, bukan bercerita: catat waktu tiap fase dan bandingkan dengan target RTO/RPO.
Failback — pulang ke region utama, yang seringkali lebih rumit daripada failover itu sendiri.
Postmortem ala episode 7: apa yang lebih cepat dari perkiraan, apa yang lebih lambat, apa yang harus diubah.

Hasil drill yang baik adalah daftar perbaikan konkret, bukan laporan "berhasil semua". Drill yang selalu berhasil mulus biasanya berarti skenarionya terlalu lembut.

#Praktik: Simulasi Failover Region

Untuk lab tanpa cloud penuh, simulasikan dengan dua container yang berperan sebagai dua region:

Setup: dua instance service checkout + dua instance database (misal PostgreSQL) dengan replikasi streaming antara keduanya.
Simulasikan bencana: matikan region "utama" (container pertama) secara total.
Failover: promosikan database region kedua menjadi primary, lalu alihkan koneksi aplikasi.
Ukur: berapa detik antara matinya region utama dan pertama kalinya request berhasil? Bandingkan dengan RTO yang kalian tetapkan.
Failback: hidupkan kembali region utama, sinkronkan data, kembalikan trafik.

Simulasi matinya region utama

docker stop region-a-db region-a-app
 
# di region B: promosikan replica jadi primary
docker exec region-b-db pg_ctl promote
 
# uji request kini melayani dari region B
curl -s http://localhost:8080/health

Tip

Mulailah DR drill dari yang berdurasi pendek dan melibatkan sedikit orang, lalu tingkatkan kesulitannya bertahap. Satu failover yang sukses memberi kepercayaan lebih dari sepuluh slide rencana DR yang tidak pernah dieksekusi — dan setiap drill berikutnya seharusnya lebih cepat dari yang sebelumnya.

#Penutup

Pada episode 16 ini, kalian telah belajar membuat kegagalan bencana menjadi peristiwa yang terlatih, bukan pertaruhan.

Inti yang harus dibawa pulang:

RTO & RPO adalah dua angka bisnis yang menentukan seluruh arsitektur DR.
Active-active untuk ketersediaan kontinu, active-passive untuk biaya terkendali — keduanya punya harga tersembunyi (DNS TTL, mode replikasi).
Failover berjalan tiga tingkat: runbook → orchestrated → automatic, dan hanya level berikutnya setelah yang sebelumnya terbukti.
DR drill dengan metrik sukses adalah satu-satunya cara membuat rencana recovery dapat dipercaya.

Di episode 17 selanjutnya, kita akan memegang lembar anggaran: cost-aware reliability — FinOps, right-sizing, dan trade-off biaya vs ketersediaan tanpa mengorbankan SLO. Sampai jumpa di episode 17!