Availability dan Reliability

Definisi

Availability

• Persentase waktu sistem bisa diakses dan berfungsi
• Diukur: (total waktu - downtime) / total waktu × 100%
• Contoh: 99.9% availability = maksimal 43.8 menit downtime per bulan

Reliability

• Kemampuan sistem untuk menjalankan fungsinya secara konsisten dan benar selama periode tertentu
• Lebih luas dari availability — sistem bisa "available" tapi tidak reliable jika hasilnya salah atau tidak konsisten
• Contoh: sistem yang merespons tapi memberikan data yang salah = available tapi tidak reliable

Fault Tolerance

• Kemampuan sistem untuk terus beroperasi meskipun ada komponen yang gagal
• Berbeda dari "tidak pernah gagal" — melainkan "tetap berjalan meski ada yang gagal"

Penyebab Downtime

• Hardware failure: server, storage, atau network yang rusak
• Software bugs: code yang menyebabkan crash atau infinite loop
• Deployment issues: deploy yang memperkenalkan regression
• External dependencies: API atau service pihak ketiga yang down
• Overload: traffic melebihi kapasitas sistem
• Human error: konfigurasi yang salah atau perintah yang tidak sengaja

Strategi Meningkatkan Availability

Redundancy

• Tidak ada single point of failure — setiap komponen kritis punya backup
• Active-Active: dua instance berjalan bersamaan, traffic dibagi
• Active-Passive: satu instance aktif, satu standby siap mengambil alih

Geographic Distribution

• Deploy di beberapa region untuk tahan terhadap bencana regional
• Multi-AZ (Availability Zone): protection terhadap data center failure
• Multi-region: protection terhadap kegagalan seluruh region

Health Checks dan Auto-healing

• Monitor status setiap instance secara otomatis
• Restart atau replace instance yang tidak sehat tanpa intervensi manual
• Kubernetes liveness dan readiness probes adalah contoh mekanisme ini

Circuit Breaker Pattern

• Mencegah cascade failure saat dependency eksternal gagal
• Jika dependency gagal X kali berturut-turut, "buka" circuit — stop kirim request ke sana
• Setelah cooldown period, coba lagi secara perlahan (half-open state)
• Mencegah sistem utama collapse karena menunggu dependency yang down

Graceful Degradation

• Sistem tetap berfungsi sebagian meski ada komponen yang gagal
• Contoh: rekomendasi produk gagal → tampilkan produk popular sebagai fallback
• Contoh: search lambat → kembalikan hasil yang sudah di-cache
• Desain dengan mempertimbangkan: "Jika komponen X gagal, apa yang masih bisa ditampilkan?"

Retry dengan Exponential Backoff

• Coba ulang request yang gagal dengan jeda yang semakin lama
• Mencegah thundering herd (semua retry bersamaan saat service recovery)
• Selalu tambahkan jitter (randomisasi) pada retry delay

Failure Modes yang Perlu Didesain

Timeout

• Selalu set timeout untuk semua external calls
• Tanpa timeout, satu dependency lambat bisa block seluruh sistem
• Set timeout yang realistis, bukan terlalu pendek atau terlalu panjang

Rate Limiting

• Batasi jumlah request yang bisa diterima dalam periode tertentu
• Mencegah satu user atau client menghabiskan seluruh kapasitas sistem
• Implementasikan di API gateway atau application layer

Bulkhead Pattern

• Isolasikan resource untuk komponen berbeda agar kegagalan tidak menyebar
• Contoh: connection pool terpisah untuk service A dan B
• Jika service A overload, tidak akan menghabiskan resource untuk service B

Measuring Reliability

MTBF (Mean Time Between Failures)

• Rata-rata waktu antara dua kegagalan
• Semakin tinggi = semakin reliable

MTTR (Mean Time to Recovery)

• Rata-rata waktu untuk memulihkan sistem setelah gagal
• Semakin rendah = semakin baik kemampuan recovery

Error Rate

• Persentase request yang gagal
• Biasanya diukur per endpoint atau per service

Praktik Terbaik

• Desain untuk failure — asumsikan setiap komponen akan gagal suatu saat
• Test failure scenarios secara aktif (chaos engineering, game day)
• Monitor availability dan reliability secara real-time
• Dokumentasikan runbook untuk setiap failure mode yang diketahui
• Recovery yang cepat sering lebih valuable dari prevention yang sempurna