Matematika SLA — Apa yang Dibayar oleh 99.9% Ketersediaan dalam Jam Gangguan

Bayangkan ini: Anda sedang berbicara dengan klien, mereka meminta '99.99% uptime', Anda mengangguk, dan keduanya melanjutkan. Setelah enam bulan, Anda memandang klausa kredit SLA dan bertanya-tanya bagaimana Anda sampai di sini. Jaminan yang Anda setujui secara santai memungkinkan waktu down hingga 52 menit per tahun — dan sebagian besar dari itu akan hilang dalam satu deploy yang buruk.

Ini adalah perhitungan yang harus dimiliki setiap pengembang sebelum menandatangani SLA atau mengkomitmen pada angka uptime dalam proposal.

Rumusnya

Persentase ketersediaan dikonversi ke waktu down menggunakan satu rumus sederhana:

Waktu down = (1 – ketersediaan) x periode

Untuk uptime 99.9%: 1 – 0.999 = 0.001. Kalikan dengan jumlah menit dalam satu tahun (525.960) dan Anda mendapatkan 525,96 menit — atau 8,77 jam waktu down yang diizinkan setiap tahun. Itu bukan kegagalan besar. Itu adalah deploy pada hari Selasa yang biasa yang memanjang selama beberapa jam, ganti database yang memakan waktu lebih lama dari yang diharapkan, dan pembaruan ketergantungan pada tengah malam yang menghancurkan layanan autentikasi. Delapan jam berlalu cepat.

Tabel Referensi

Simpan ini. Setiap angka di sini dihitung dengan cara yang sama — (1 – ketersediaan) dikalikan dengan panjang periode dalam menit, lalu dikonversi ke unit yang paling mudah dibaca.

Ketersediaan	Waktu down/Hari	Waktu down/Minggu	Waktu down/Bulan	Waktu down/Tahun
99%	14,4 menit	1,68 jam	7,3 jam	87,6 jam
99.5%	7,2 menit	50,4 menit	3,65 jam	43,8 jam
99.9%	1,44 menit	10,08 menit	43,83 menit	8,77 jam
99.95%	43,2 detik	5,04 menit	21,92 menit	4,38 jam
99.99%	8,64 detik	1,01 menit	4,38 menit	52,6 menit
99.999% (lima nol)	0,864 detik	6,05 detik	26,3 detik	5,26 menit

Baca kembali baris 99.999%. Waktu down yang diizinkan per tahun adalah lima menit dan dua puluh enam detik. Total. Termasuk pemeliharaan terencana, pemeriksaan kesehatan yang gagal, dan 30 detik yang dibutuhkan load balancer untuk menyadari node yang mati. Anda bisa menghitung seberapa realistis itu bagi kebanyakan tim.

Apa yang Diperlukan untuk Mencapai Lima Nol

Lima nol (99.999%) bukan hanya 'infrastruktur yang baik'. Ini adalah disiplin teknik yang berbeda. Untuk mencapainya, Anda membutuhkan:

• Redundansi penuh pada setiap lapisan — tidak ada titik tunggal kegagalan di mana pun di stack, termasuk DNS, CDN, database, dan lapisan aplikasi
• Penggantian otomatis dengan deteksi dalam detik — manusia tidak bisa merespons dengan cepat; pengawasan dan penggantian harus berjalan tanpa intervensi
• Deploy tanpa downtime — blue/green atau canary, dengan rollback otomatis. Setiap deploy yang membutuhkan restart akan menghabiskan anggaran 5 menit Anda
• Pengaturan aktif-aktif di beberapa wilayah — jika satu wilayah down, Anda tidak akan ikut turun
• Pemeliharaan terencana di luar jendela SLA — sebagian besar SLA 99.9% secara eksplisit menghilangkan pemeliharaan terencana, tetapi SLA 99.999% sering kali tidak menyisakan ruang untuk itu

Perusahaan yang benar-benar mencapai 99.999% — AWS S3, Google Cloud Storage — memiliki tim khusus reliability engineering, data chaos engineering selama bertahun-tahun, dan pengeluaran infrastruktur yang akan membuat kebanyakan pendiri SaaS pingsan. Ini dapat dicapai, tetapi bukan secara kebetulan dan tidak murah.

Anda dapat menggunakan Kalkulator Ketersediaan / SLA untuk menjalankan konversi ini untuk setiap persentase ketersediaan dan setiap jendela waktu yang Anda kerjakan.

Masalah Kredit SLA

Bagian ini mengejutkan banyak orang: kredit SLA dari penyedia cloud tidak memperbaiki Anda atas kerugian aktual Anda. Mereka hanya memperbaiki Anda atas sebagian dari tagihan hosting Anda.

AWS, GCP, dan Azure biasanya menawarkan 10–30% dari tagihan bulanan Anda sebagai kredit ketika mereka melanggar SLA mereka. Jika Anda membayar $500/bulan untuk EC2 dan mereka mengalami gangguan selama dua jam yang melanggar SLA, Anda mungkin mendapatkan kredit $50–150. Namun, Anda mungkin telah kehilangan ribuan pendapatan, menghabiskan jam kerja insinyur dalam tanggapan insiden, dan merusak kepercayaan klien.

Ketika Anda menulis SLA dengan klien Anda, pahami bahwa ini adalah model standar — kredit adalah tindakan kebaikan yang terikat pada biaya layanan, bukan kompensasi penuh. Baca bagian perbaikan secara hati-hati. Banyak klien perusahaan akan berusaha menegosiasikan bahasa kerugian nyata; itu adalah percakapan berbeda yang melibatkan hukum, bukan SRE.

Jendela Bulanan vs. Tahunan Memiliki Dampak

SLA diukur dalam jendela tertentu, dan jendela ini lebih penting daripada yang banyak orang sadari. SLA tahunan 99.9% memberi Anda 8,77 jam waktu down yang tersebar di 12 bulan. SLA bulanan 99.9% memberi Anda hanya 43,83 menit per bulan — tetapi itu mengatur ulang setiap bulan.

Klien hampir selalu ingin pengukuran bulanan — terdengar lebih ketat, dan memberi mereka kekuatan jika Anda memiliki satu bulan buruk. Yang mereka tidak selalu sadari adalah bahwa pengukuran bulanan sebenarnya dapat memberi Anda lebih sedikit fleksibilitas total: 43,83 menit x 12 bulan = 525,96 menit per tahun, yang sama persis dengan perhitungan tahunan. Perbedaannya adalah bahwa dengan SLA bulanan, satu bulan yang buruk dapat memicu pelanggaran bahkan jika seluruh tahun lainnya sempurna.

Ketika menegosiasikan, dorong pengukuran jendela tahunan jika mungkin. Ketika klien menekankan pengukuran bulanan, pastikan infrastruktur Anda benar-benar dapat mencapai 99.9% setiap bulan — bukan hanya secara rata-rata selama tahun itu.

Apa yang Harus Dijamin

Berikut adalah panduan yang benar-benar berguna:

Proyek pribadi dan produk tahap awal

99% cukup jujur dan baik. Downtime sembilan jam per bulan realistis bagi tim kecil tanpa tim operasional khusus. Jangan janjikan lebih dari yang dapat Anda berikan secara konsisten — biaya reputasi karena kegagalan SLA lebih buruk daripada menetapkan harapan yang lebih rendah sejak awal.

SaaS B2B pada infrastruktur cloud standar

99.9% adalah target yang tepat. Dengan pemantauan yang tepat, auto-scaling, database terkelola, dan pipeline CI/CD yang tidak membutuhkan downtime untuk deploy, ini benar-benar dapat dicapai di AWS, GCP, atau Azure tanpa usaha heroik. Anggaran 43 menit per bulan cukup ketat tetapi dapat dikerjakan jika proses deploy otomatis sudah teratur.

99.99% dan di atasnya

Ini membutuhkan investasi nyata: load balancer di beberapa zona ketersediaan, pengaturan aktif-aktif di beberapa wilayah, replikasi database dengan promosi otomatis, dan seseorang yang memiliki kepercayaan terhadap keandalan sebagai pekerjaan utamanya. Jika klien meminta 99.99% dan Anda belum memiliki infrastruktur tersebut, jawaban jujur adalah menegosiasikan ke 99.9% dan membangun menuju 99.99% sebagai item rencana — dengan kenaikan biaya infrastruktur yang sesuai dicerminkan dalam harga.

99.999% adalah wilayah Amazon dan Google. Kecuali Anda mengoperasikan infrastruktur keuangan, sistem kesehatan, atau layanan telekomunikasi dengan tim SRE khusus, ini bukan komitmen yang realistis.

Lakukan Perhitungan untuk Situasi Anda

Perhitungan ini dapat diterapkan pada setiap jendela waktu dan setiap target ketersediaan. Jika Anda bekerja dengan jendela SLA yang tidak standar — seperti jendela 90 hari, kuartal fiskal, atau jendela pengukuran khusus — rumusnya tetap sama: kalikan persentase downtime dengan jumlah menit dalam jendela Anda.

Itu Kalkulator Uptime / SLA di IO Tools mengelola semua ini — masukkan persentase ketersediaan dan periode waktu untuk mendapatkan batas waktu down yang tepat, yang berguna saat menulis bahasa SLA atau merespons permintaan klien tentang ketersediaan dengan penawaran yang realistis.

Ringkasan: 99.9% adalah batas praktis bagi kebanyakan tim tanpa investasi khusus keandalan. Apapun di atas itu membutuhkan uang nyata dan perubahan proses nyata. Ketahui apa yang Anda komitmen sebelum kontrak ditandatangani.

Anda mungkin juga menyukai