Memahami SLA Hosting: Arti Uptime 99,9% dan Kompensasinya
Arti SLA hosting dan uptime 99%, 99,9%, hingga 99,99% dalam menit downtime, pengecualian umum, cara klaim kompensasi, dan cara memantau uptime sendiri.
Daftar isi
Hampir setiap penyedia hosting mencantumkan angka uptime seperti 99,9%, tetapi angka itu baru bermakna jika Anda tahu berapa lama downtime yang masih dianggap wajar dan apa yang Anda dapatkan ketika janji tersebut dilanggar. Semua itu diatur dalam SLA. Artikel ini menjelaskan cara membaca SLA hosting, menghitung arti persentase uptime, mengajukan kompensasi, dan memantau uptime situs Anda sendiri.
Apa itu SLA
SLA (Service Level Agreement) adalah perjanjian tertulis antara penyedia dan pelanggan tentang tingkat layanan yang dijanjikan. Untuk hosting, SLA umumnya mengatur:
- target uptime dalam persen untuk periode tertentu, biasanya per bulan,
- definisi downtime dan cara mengukurnya,
- kejadian yang dikecualikan dari perhitungan downtime,
- bentuk dan besaran kompensasi,
- prosedur dan batas waktu pengajuan klaim.
Angka uptime di halaman promosi belum tentu sama dengan SLA. Jika tidak ada dokumen SLA yang bisa Anda baca, anggap angka tersebut sebagai klaim pemasaran, bukan janji yang bisa ditagih. Memeriksa keberadaan SLA termasuk dalam delapan hal yang perlu dicek sebelum membeli hosting murah.
Arti angka uptime dalam menit dan jam
Selisih antara 99% dan 99,9% terlihat kecil, padahal jumlah downtime yang diperbolehkan berbeda sepuluh kali lipat. Tabel berikut menghitung batas downtime berdasarkan rata-rata panjang satu bulan (sekitar 730 jam) dan satu tahun (8.760 jam).
| Uptime | Downtime per bulan | Downtime per tahun |
|---|---|---|
| 99% | sekitar 7,3 jam | sekitar 87,6 jam (sekitar 3,65 hari) |
| 99,5% | sekitar 3,65 jam | sekitar 43,8 jam |
| 99,9% | sekitar 43,8 menit | sekitar 8,76 jam |
| 99,95% | sekitar 21,9 menit | sekitar 4,38 jam |
| 99,99% | sekitar 4,4 menit | sekitar 52,6 menit |
Cara menghitungnya sederhana: kurangi 100% dengan angka uptime, lalu kalikan hasilnya dengan total waktu dalam periode tersebut. Untuk 99,9% per bulan, hitungannya 0,1% × 730 jam = 0,73 jam, atau sekitar 43,8 menit. Jika SLA memakai bulan 30 hari (720 jam), batasnya sedikit lebih kecil, yaitu sekitar 43,2 menit.
Periode pengukuran ikut menentukan
SLA bulanan dan tahunan memberi hasil yang berbeda untuk kejadian yang sama. Gangguan tiga jam dalam satu bulan sudah melanggar SLA 99,9% bulanan, tetapi masih di bawah batas 8,76 jam jika SLA dihitung per tahun. SLA bulanan umumnya lebih menguntungkan pelanggan karena setiap bulan dinilai secara terpisah.
Pengecualian yang umum di SLA
Hampir semua SLA mengecualikan kejadian tertentu dari perhitungan downtime. Pengecualian yang sering muncul:
- Pemeliharaan terjadwal, terutama yang diumumkan sebelumnya. Perhatikan apakah ada batas durasi dan frekuensinya.
- Serangan DDoS dan gangguan jaringan yang dinilai berada di luar kendali penyedia.
- Kesalahan pelanggan, misalnya skrip yang membebani server, plugin yang rusak, atau pengaturan DNS yang keliru.
- Penangguhan akun karena pelanggaran ketentuan layanan atau tagihan yang belum dibayar.
- Gangguan pihak ketiga, seperti layanan DNS eksternal atau layanan lain yang tidak dikelola penyedia hosting.
- Keadaan kahar (force majeure), misalnya bencana alam.
Perhatikan juga definisi "tersedia" yang dipakai. Ada SLA yang hanya mengukur apakah server menyala atau jaringan bisa dijangkau, bukan apakah situs Anda benar-benar menampilkan halaman. Dalam kondisi seperti itu, situs bisa menampilkan error 500 sementara server tetap dihitung aktif.
Cara kerja kompensasi
Kompensasi SLA hosting umumnya berbentuk kredit layanan, bukan uang tunai. Kredit ini mengurangi tagihan berikutnya. Pola yang sering dipakai:
- kredit dihitung sebagai persentase dari biaya bulanan layanan yang terdampak, dan persentasenya makin besar jika uptime makin rendah,
- total kredit dalam satu bulan dibatasi, sering maksimal sebesar biaya bulanan layanan tersebut,
- kredit tidak diberikan otomatis, melainkan harus diajukan dalam batas waktu tertentu setelah gangguan,
- pelanggan dengan tagihan tertunggak biasanya tidak berhak atas kredit.
Rincian angka berbeda di setiap penyedia, jadi baca tabel kompensasi di dokumen SLA masing-masing. Saat membandingkan beberapa SLA, perhatikan klausul berikut:
| Klausul | Lebih menguntungkan pelanggan | Perlu diwaspadai |
|---|---|---|
| Periode pengukuran | Bulanan | Tahunan |
| Definisi downtime | Situs atau layanan tidak bisa diakses dari luar | Hanya dihitung jika server fisik mati |
| Pemeliharaan terjadwal | Dibatasi durasinya dan diumumkan jauh hari | Tanpa batas dan tanpa pemberitahuan |
| Pengajuan klaim | Prosedur jelas dengan batas waktu wajar | Batas waktu sangat singkat atau syarat bukti berlebihan |
| Besaran kompensasi | Tabel kredit per tingkat uptime | Hanya "sesuai kebijakan penyedia" tanpa angka |
Kredit SLA jarang sebanding dengan kerugian usaha akibat situs tidak bisa diakses. Karena itu, SLA lebih berguna sebagai tanda keseriusan penyedia daripada sebagai jaminan ganti rugi, dan rencana backup serta pemulihan tetap menjadi tanggung jawab Anda.
Cara mengajukan klaim
- Catat waktu gangguan. Rekam waktu mulai dan selesai, sebaiknya dari alat pemantau independen.
- Kumpulkan bukti. Simpan tangkapan layar pesan error dan, jika ada, pengumuman di halaman status penyedia.
- Buka tiket ke penyedia dalam batas waktu yang ditetapkan SLA, dengan menyebutkan rentang waktu dan layanan yang terdampak.
- Lampirkan log pemantauan sebagai bukti pendukung.
- Periksa tagihan berikutnya dan pastikan kredit benar-benar diterapkan.
Memantau uptime sendiri
Jangan hanya mengandalkan laporan penyedia. Pemantauan independen memberi Anda data sendiri, baik untuk klaim SLA maupun untuk menilai apakah sudah waktunya pindah hosting. Banyak layanan pemantauan uptime menyediakan paket gratis dengan fitur dasar. Saat mengaturnya:
- Pantau halaman yang memuat data dinamis, misalnya halaman utama atau halaman produk, bukan file statis yang bisa disajikan dari cache.
- Pilih interval yang rapat, misalnya setiap satu sampai lima menit. Interval yang terlalu jarang membuat gangguan singkat tidak tercatat.
- Aktifkan pemeriksaan kata kunci jika tersedia, supaya halaman error yang tetap mengembalikan kode 200 ikut terdeteksi.
- Gunakan beberapa lokasi pemantauan, agar gangguan jaringan di satu lokasi tidak dianggap sebagai downtime server.
- Kirim notifikasi ke lebih dari satu saluran, misalnya email dan aplikasi pesan.
- Pantau juga masa berlaku SSL dan domain, karena sertifikat atau domain yang kedaluwarsa membuat situs tidak bisa diakses meskipun server normal.
Untuk pemeriksaan cepat dari komputer sendiri, perintah berikut menampilkan kode status HTTP dan total waktu respons sebuah halaman:
curl -o /dev/null -s -w "%{http_code} %{time_total}\n" https://example.com/
Kode 200 berarti halaman berhasil dimuat, sedangkan kode 5xx menandakan masalah di sisi server. Jalankan perintah ini beberapa kali pada waktu berbeda untuk melihat apakah waktu respons stabil.
Simpan log pemantauan setidaknya beberapa bulan. Jika data menunjukkan gangguan berulang yang melewati batas SLA dan tanggapan penyedia tidak memuaskan, data tersebut menjadi dasar yang kuat untuk mengajukan klaim atau pindah hosting tanpa downtime.
Sumber dan referensi
- Google SRE Book: Service Level Objectives: penjelasan konsep SLI, SLO, dan SLA dari praktik operasional Google.
- Cloudflare Learning: What is a DDoS attack?: penjelasan serangan DDoS yang sering menjadi pengecualian dalam SLA.
- MDN: HTTP response status codes: daftar kode status HTTP untuk membaca hasil pemantauan.