SLA Ketersediaan 99,9%: Apa yang Dijamin Vendor?

SLA adalah perjanjian tingkat layanan dengan vendor. Janji ketersediaan 99,9% berarti batas gangguan sekitar 43 menit dalam bulan 30 hari, sesuai cara pengukuran kontraknya. Kompensasinya sering berupa kredit tagihan, bukan penggantian penjualan yang hilang. Sebelum menandatangani, baca definisi gangguan, pengecualian, batas pengajuan klaim, dan rencana bisnis Anda ketika layanan berhenti.

Tabel tersebut memperlihatkan batas gangguan di balik persentase ketersediaan, rinciannya ada di sini. Ketersediaan 99,9% masih menyisakan hampir sembilan jam gangguan setahun. Jika proses pembayaran atau pemesanan tidak dapat menanggung gangguan 40 menit, periksa apakah target tersebut sesuai kebutuhan bisnis Anda.

Periksa kemudian bentuk kompensasi saat target tidak terpenuhi.

Kompensasi apa yang dibayar ketika SLA tidak tercapai?

Baca SLA komputasi awan mana pun, mekanismenya nyaris selalu sama: kredit layanan bertingkat, bukan kompensasi. Untuk EC2 yang berjalan di sedikitnya dua Availability Zone dalam satu wilayah, AWS mendefinisikan Region-Level Monthly Uptime Percentage sebagai 100% dikurangi persentase menit dalam sebulan yang tidak tersedia. Mereka membayar kredit 10% jika ketersediaan turun di bawah 99,99% tapi masih di atas atau sama dengan 99,0%. Kredit naik ke 30% untuk rentang di bawah 99,0% hingga 95,0%, dan ke 100% untuk apa pun di bawah 95,0% — tabel tingkatnya di sini.

Untuk Compute Engine Premium Tier di beberapa zona di luar Meksiko dan Stockholm, SLA Google memakai susunan kredit serupa. Komitmen satu instance serta wilayah atau tingkatan lain berbeda. Monthly Uptime Percentage adalah total menit dikurangi menit waktu gangguan, dibagi total menit. Kredit tingkat-nya 10% untuk ketersediaan 99,00–99,99%, 25% untuk 95,00–99,00%, dan 100% di bawah 95,00%, dibayar sebagai kredit tagihan dan dibatasi maksimal sebesar biaya bulan itu untuk layanan yang terdampak.

Kredit dihitung dari tagihan layanan, bukan nilai kerugian bisnis. Jika biaya komputasi $200 sebulan dan Anda memperoleh tingkat kredit tertinggi, nilainya hanya $200 meski gangguan menghilangkan satu hari pemesanan.

Gangguan apa yang tidak ditanggung?

Setiap SLA yang pernah saya baca mengecualikan kategori yang sama sebelum persentasenya berlaku. SLA EC2 AWS menyatakan dengan jelas bahwa SLA itu tidak berlaku untuk ketidaktersediaan yang disebabkan faktor di luar kendali wajar AWS. Pengecualian ini juga mencakup tindakan atau kelalaian pelanggan sendiri, serta peralatan, perangkat lunak, maupun teknologi milik pelanggan sendiri — lihat pengecualiannya.

SLA Compute Engine Google mengecualikan fitur pre-general-availability, apa pun yang secara terpisah ditandai di luar cakupan di dokumentasi, dan faktor di luar kendali wajar Google. Pengecualian lain mencakup perangkat lunak atau perangkat keras milik pelanggan sendiri maupun pihak ketiga, dan apa pun yang terkait kuota yang terlampaui.

Baca ulang klausul-klausul itu dari kacamata pembeli. DNS yang salah konfigurasi, API pembayaran pihak ketiga yang rusak, plugin yang dipasang sendiri: semuanya memang sengaja ditempatkan di luar jaminan. Panduan Microsoft soal membaca SLA cukup terus terang menyebut celah yang tersisa: kredit layanan biasanya berupa persentase dari biaya bulanan. Kata-kata mereka sendiri: "credits don't cover lost revenue, customer attrition, or reputational damage". Seluruh dampak bisnis dari sebuah gangguan ada di luar kontrak yang baru saja ditandatangani.

Bagaimana memeriksa cara vendor menghitung gangguan?

Mulailah membaca dari definisi pengukuran: bagaimana waktu gangguan diukur, dalam jendela waktu berapa, dan apakah satu permintaan gagal dihitung sama dengan sepuluh ribu permintaan gagal? Pengukuran berbasis waktu (apakah layanan tidak tersedia pada menit ini) dan pengukuran berbasis permintaan (berapa fraksi permintaan yang gagal) menghasilkan angka berbeda dari insiden yang sama. Definisi dalam kontrak menentukan metode yang berlaku.

Lalu periksa apa yang terjadi kalau sistem yang dipakai bergantung pada lebih dari satu SLA vendor sekaligus.

Mengalikan keempat persentase itu untuk mendapat angka "gabungan" adalah cara pintas yang umum — dan panduan reliability Microsoft terang-terangan menyebutnya tidak bisa diandalkan. Cara itu mengasumsikan kegagalan-kegagalan itu independen dan mengabaikan bahwa SLA tiap vendor punya definisi dan pengecualian sendiri. Outage di API pembayaran tidak diganti oleh kredit CDN, dan SLA vendor basis data tidak bicara apa pun soal server aplikasi yang berjalan di atasnya.

Periksa setiap kontrak dalam rantai layanan secara terpisah, termasuk definisi gangguan dan pengecualiannya.

Apakah UKM perlu target ketersediaan 99,999%?

Target 99,999% dapat terlihat menarik, tetapi belum tentu sepadan dengan kebutuhan UKM. Google SRE Workbook menjelaskan pertukaran biaya dan manfaatnya secara eksplisit: seiring reliability naik dari 99% ke 99,9% ke 99,99%, setiap nine tambahan datang dengan biaya yang tidak sebanding, sementara manfaat marginalnya bagi pengguna mendekati nol. Bagi banyak pelanggan ritel, selisih tersebut dapat kurang terasa dibandingkan tertundanya fitur yang dibutuhkan karena anggaran habis untuk mengejar target ketersediaan.

Bab yang sama menyebut biaya kedua: penyebab utama gangguan adalah perubahan itu sendiri, jadi tim yang mengejar reliability 100% pada akhirnya berhenti merilis apa pun. Deploy, patch, penambahan skala, semuanya jadi risiko bagi target yang tidak punya ruang untuk menampung risiko sama sekali. Sistem yang dibekukan demi menjaga angka ketersediaannya sudah berhenti berkembang, dan itu sendiri adalah bentuk kegagalan.

Berapa gangguan yang masih bisa ditanggung bisnis?

Tentukan jatah gangguan yang masih dapat diterima bisnis. Jatah ini membantu tim memutuskan kapan boleh mengambil risiko perubahan dan kapan harus berfokus pada pemulihan.

Buku SRE Google memberi nama dan angka pada trade-off ini: Error budget, jatah gangguan yang masih berada dalam target layanan, adalah 100% dikurangi SLO — Service Level Objective, target layanan yang dipasang tim buat dirinya sendiri, bukan janji ke pelanggan. Kalau target ketersediaannya 99,9%, jatah gangguannya 0,1% — jatah waktu yang boleh dipakai untuk berhenti. Bisa dipakai untuk deploy, untuk insiden, untuk migrasi berisiko, terserah kebutuhan.

Yang dilakukan budget ini, menurut kerangka buku itu sendiri, adalah menghilangkan politik dari negosiasi antara reliability dan pengembangan produk. Tim menggunakan batas yang sama untuk menilai risiko perubahan dan kebutuhan keandalan.

Untuk tim pengembangan kecil, ini jauh lebih berguna daripada SLA vendor mana pun. Angka ini ditetapkan dan dipakai oleh tim sendiri, dan memaksa kita menjawab pertanyaan yang sebenarnya penting: berapa banyak waktu gangguan yang sanggup ditanggung bisnis ini. Bukan membiarkan persentase pemasaran yang menjawabnya.

Daftar periksa sebelum menandatangani kontrak

• Ubah persentase yang dijanjikan jadi toleransi waktu gangguan Anda sendiri dalam jam, pakai tabel di atas, bukan naskah pemasarannya.
• Baca klausul pengecualian sebelum tabel tingkat kredit. Di situlah nasib sebagian besar jaminannya ditentukan.
• Cari batas waktu pengajuan klaim. Kebanyakan SLA mewajibkan gangguan dilaporkan dalam jendela waktu tertentu; lewat dari itu, Anda tidak dapat apa-apa — kredit tidak turun otomatis.
• Tanyakan apa yang sepenuhnya di luar cakupan SLA — fitur pratinjau, API tertentu, tingkat harga tertentu sering tidak tercakup sama sekali.
• Putuskan redundansi apa yang akan Anda bangun sendiri. Tidak ada SLA yang mengganti pendapatan yang hilang; risiko itu tanggung jawab Anda sendiri.

Apa yang perlu diputuskan pembeli hosting di Indonesia?

Gunakan SLA untuk memahami komitmen vendor dan kredit tagihan jika komitmen tidak terpenuhi. Siapkan rencana operasional sendiri untuk menghadapi gangguan dan kerugian yang tidak termasuk cakupan kontrak.

Satu vendor dengan angka besar tapi tanpa rencana redundansi tetap saja jadi titik tunggal kegagalan. Tetapkan batas gangguan yang dapat ditanggung bisnis, lalu gunakan batas itu untuk merancang dan memantau sistem.