Kalkulator SLA & Uptime: Batas Downtime per Bulan
Ubah persentase SLA (99%, 99,9%, 99,99%) menjadi batas downtime per hari, bulan, dan tahun, hitung uptime dari downtime nyata, dan gabungkan SLA beberapa komponen sistem.
Apa itu SLA dan uptime?
SLA (Service Level Agreement) adalah janji tertulis tentang tingkat layanan, salah satunya persentase waktu sistem dapat dipakai (uptime). Angkanya terlihat mirip, 99% dan 99,9% hanya berbeda 0,9 poin, tetapi selisih batas downtime-nya sangat besar.
Batas downtime = (1 − SLA) × total waktu periode
Tabel batas downtime
| SLA | Per bulan (30 hari) | Per tahun (365 hari) |
|---|---|---|
| 99% | 7 jam 12 menit | 3 hari 15 jam 36 menit |
| 99,5% | 3 jam 36 menit | 1 hari 19 jam 48 menit |
| 99,9% | 43 menit 12 detik | 8 jam 45 menit 36 detik |
| 99,95% | 21 menit 36 detik | 4 jam 22 menit 48 detik |
| 99,99% | 4 menit 19 detik | 52 menit 34 detik |
Setiap tambahan angka "9" memangkas batas downtime menjadi sepersepuluhnya, dan biasanya menaikkan biaya infrastruktur secara signifikan: server cadangan, database replika, load balancer, dan tim yang siaga.
SLA komponen berantai
Aplikasi biasanya bergantung pada beberapa komponen sekaligus: server aplikasi, database, jaringan, dan layanan pihak ketiga. Jika komponen-komponen itu berantai (semuanya harus hidup agar aplikasi berjalan), SLA gabungannya adalah hasil kali semuanya:
SLA gabungan = SLA₁ × SLA₂ × SLA₃ × …
Contoh: server 99,95%, database 99,9%, dan jaringan 99,99%. SLA gabungannya 0,9995 × 0,999 × 0,9999 ≈ 99,84%, lebih rendah dari komponen terlemahnya. Artinya, Anda tidak bisa menjanjikan 99,9% kepada klien jika satu komponen saja hanya menjamin 99,9%.
Sebaliknya, komponen yang dipasang paralel (redundan) meningkatkan ketersediaan. Dua server 99% yang saling menggantikan secara teoretis memberi 1 − (0,01 × 0,01) = 99,99%, asalkan kegagalannya tidak terjadi bersamaan.
Tips menulis SLA untuk klien
- Definisikan "down" dengan jelas. Apakah aplikasi lambat termasuk down? Apakah satu fitur error termasuk down?
- Kecualikan pemeliharaan terjadwal yang sudah diumumkan, misalnya setiap Minggu dini hari.
- Tentukan cara pengukuran: alat monitoring apa yang dipakai, dan dari lokasi mana.
- Atur waktu respons dan waktu penyelesaian insiden, bukan hanya uptime.
- Untuk layanan kesehatan seperti SIMRS, perhatikan jam operasional. Downtime pada jam pelayanan poli jauh lebih merugikan daripada pada dini hari.
Praktik monitoring dan pencegahan downtime dibahas di artikel DevOps untuk tim kecil.
Terakhir diperbarui 24 September 2026