Belajar Solution Architect - Resilience & DR Solutions

#Pendahuluan

Setelah di episode 14 kalian bisa menimbang container vs Kubernetes secara jujur dan mendesain platform yang ber-guardrail, kita hadapi dimensi yang diuji bukan oleh trafik, melainkan oleh musibah: resilience dan disaster recovery. Server mati, AZ tumbang, region gagal, manusia salah hapus database — pertanyaannya bukan apakah itu akan terjadi, melainkan seberapa cepat sistem pulih dan berapa data yang hilang saat itu terjadi.

Mengapa ini ranah SA? Karena RTO/RPO adalah keputusan bisnis yang dieksekusi lewat arsitektur — dan setiap level ambisinya punya harga yang berbeda jauh. Menjanjikan 99,99% tanpa merancang DR-nya sama saja dengan menulis cek tanpa saldo.

#HA vs DR: Dua Hal Berbeda

Dua istilah ini sering dicampur padahal menjawab kelas kegagalan berbeda:

Dimensi	High Availability (HA)	Disaster Recovery (DR)
Menjawab	Komponen gagal → layanan tetap jalan	Situs/datacenter hilang → layanan pulih
Cakupan	Multi-instance, multi-AZ dalam satu region	Lintas region / lintas site
Contoh insiden	Instance mati, deploy gagal, node rusak	Region outage, bencana alam, ransomware total
Mekanisme	Load balancer, replikasi, auto-healing	Backup, failover region, rencana BCP

Solusi tiket kita contohnya: HA berarti pod order-service di tiga AZ tetap melayani walau satu AZ gelap. DR berarti kalau region ap-southeast-3 seluruhnya tidak tersedia, kalian bisa melayani pembeli lagi dari region lain — dengan target waktu dan data-loss tertentu.

#RTO dan RPO: Kontrak yang Terukur

Dua angka ini adalah inti dari setiap desain resilience:

RTO (Recovery Time Objective) — berapa lama maksimal layanan boleh down sebelum pulih.
RPO (Recovery Point Objective) — berapa banyak data maksimal yang boleh hilang (jarak waktu ke snapshot/replikasi terakhir).

Contoh penetapan target studi kasus tiket

Komponen           RTO        RPO        Implikasi arsitektur
API & web          15 menit   0          stateless, IaC redeploy cepat
DB transaksional   30 menit   <= 5 menit cross-region replication async
Object storage     1 jam      <= 1 jam   cross-region replication bucket
Dashboard analitik 24 jam     24 jam     rebuild dari raw zone (episode 7)

Cara menetapkannya benar adalah dari kerugian bisnis: jika downtime satu jam saat window sale bernilai Rp 500 juta, maka biaya infrastruktur active-active Rp X juta/bulan langsung punya konteks. Tanpa angka kerugian, semua diskusi DR hanya perdebatan selera — persis pola penerjemahan episode 11.

Important

RTO/RPO tanpa pengujian adalah angka fiksi. Target resmi hanya lahir setelah drill failover nyata membuktikan bahwa angka itu dapat dicapai — dan drill itu harus masuk kalender operasional rutin.

#Empat Topologi DR

Industri mengenali empat tingkatan strategi DR, dari termurah term lambat sampai termahal tercepat:

Topologi	Cara Kerja	RTO/RPO Tipikal	Biaya Relatif
Backup & restore	Restore data + redeploy infra saat bencana	Jam-hari / jam	Paling murah
Pilot light	Data direplikasi; infra inti mati, dinyalakan saat perlu	±1 jam / menit	Rendah
Warm standby	Versi mini produksi hidup di region kedua	±menit / detik-menit	Sedang
Active-active	Trafik dilayani dua region aktif bersamaan	~nol / ~nol	Termahal

Panduan pemilihan yang pragmatis:

Sistem internal/admin → backup & restore sering sudah cukup.
Aplikasi bisnis utama → pilot light atau warm standby; titik manis biaya-manfaat untuk mayoritas kasus.
Layanan yang kehilangan satu transaksi = kerugian besar (payment) → active-active atau minimal warm standby dengan replikasi sinkron.

Untuk solusi tiket kita: warm standby untuk jalur checkout (replika DB cross-region + image siap), backup & restore untuk dashboard analitik. Tidak semua komponen butuh DR setara — tiering resilience seperti ini menghemat signifikan dibanding memaksakan active-active untuk semuanya.

#Strategi Backup yang Benar-Benar Berguna

Backup adalah lapisan terakhir yang bekerja bahkan saat semua mekanisme replikasi ikut gagal (termasuk kasus ransomware). Prinsip-prinsipnya:

3-2-1 rule — 3 salinan data, 2 media berbeda, 1 salinan off-site/cross-region. Kelas cloud modern: primary DB + snapshot otomatis + salinan cross-region object storage dengan versioning.
Immutable/WORM — retensi yang tidak bisa dihapus aplikasi maupun admin (object lock). Ini penawar utama ransomware: penyerang tak bisa mengenkripsi apa yang tidak bisa ia ubah.
Terjadwal sesuai RPO — snapshot tiap 15 menit untuk RPO 5-15 menit; log-based point-in-time recovery untuk RPO lebih ketat.
Restore test berkala — restore ke environment terisolasi, verifikasi checksum dan aplikasi bisa boot. Kuarter tanpa restore test = backup belum terbukti ada.

Contoh audit kebijakan backup (AWS)

# Daftar snapshot DB dan umurnya
aws rds describe-db-snapshots \
  --db-instance-identifier ticket-db \
  --query 'sort_by(DBSnapshots,&SnapshotCreateTime)[].{id:DBSnapshotIdentifier,created:SnapshotCreateTime}'
 
# Verifikasi bucket backup punya versioning + object lock
aws s3api get-bucket-versioning --bucket ticket-backups
aws s3api get-object-lock-configuration --bucket ticket-backups

Perintah seperti ini masuk runbook audit bulanan — bukti governance bahwa kebijakan backup bukan sekadar klaim dokumen.

#Failover dan Uji Chaos

Rencana resilience baru sah setelah dipraktikkan:

Failover drill DB — promosikan replika di staging dan production terjadwal; ukur durasi nyata versus RTO target.
Chaos engineering bertahap — mulai dari terminasi instance acak di staging, lanjut kill pod, ganggu network partition antar-service. Alat standar: AWS Fault Injection Service, Chaos Mesh di K8s. Mulai dari lingkup kecil, selalu dengan blast radius terkendali dan abort condition.
Game day — simulasi insiden besar dengan tim on-call sungguhan: region "hilang", jalankan prosedur DR dari dokumen, ukur. Temuan umumnya selalu sama: dokumen DR yang belum pernah dipakai ternyata punya langkah usang.

Hasil tiap drill masuk sebagai update pada SDD bagian operabilitas (episode 10) — resilience adalah properti yang dirawat, bukan sertifikat sekali-cetak.

#Business Continuity di Luar Teknologi

DR teknis hanya separuh cerita. Pertanyaan continuity yang harus dijawab bersama bisnis:

Siapa yang memutuskan deklarasi disaster? (keputusan failover region mahal dan mengganggu — harus ada otoritas jelas)
Bagaimana komunikasi ke pelanggan saat degraded mode? (halaman status, template notifikasi)
Proses manual darurat apa yang disiapkan? (misal daftar penjualan offline saat POS down)
Kapan kondisi normal dikembalikan, dan bagaimana failback tanpa data loss?

Semua jawabannya masuk dokumen BCP ringkas yang dirujuk dari SDD — inilah yang membedakan SA yang berpikir end-to-end dari yang berhenti di diagram infrastruktur.

Tip

Mulailah setiap diskusi DR dengan satu tabel sederhana: komponen × RTO × RPO × topologi. Satu halaman itu memaksa keputusan eksplisit per komponen dan langsung menunjukkan biayanya — jauh lebih efektif daripada presentasi 30 slide tentang konsep bencana.

#Penutup

Inti yang harus dibawa pulang:

HA menjawab kegagalan komponen; DR menjawab kegagalan situs — keduanya wajib, tapi beda mekanisme dan biaya.
RTO/RPO ditetapkan dari kerugian bisnis, dieksekusi lewat arsitektur, dan divalidasi lewat drill — bukan ditebak lalu dicantumkan di slide.
Empat topologi DR (backup-restore, pilot light, warm standby, active-active); tier-kan per komponen agar biaya proporsional nilai bisnisnya.
Backup yang berguna: 3-2-1, immutable, terjadwal sesuai RPO, dan di-restorasi berkala.
Resilience diuji rutin via failover drill dan chaos engineering; business continuity mencakup keputusan, komunikasi, dan proses manual di luar teknologi.

Di episode 16 selanjutnya kita akan membahas performance solution design — capacity planning berbasis angka, menetapkan performance budget per endpoint, strategi caching dan scaling yang tepat sasaran, serta cara membuktikan target performa lewat load testing sebelum production. Sampai jumpa di episode 16!