Arti Sebenarnya di Balik Uptime 99.9%: Membaca SLA Seperti Engineer

Arti Sebenarnya di Balik Uptime 99.9%: Membaca SLA Seperti Engineer

Proposal vendor datang dengan tulisan "99.9% uptime SLA" di bagian atas, dan itu terasa seperti janji. SLA — Service Level Agreement — memang janji tertulis vendor soal tingkat layanan, lengkap dengan kompensasi kalau meleset. Sebelum menandatangani apa pun, ubah dulu persentase itu jadi jam.

Itulah anggaran sebenarnya di balik setiap angka marketing, rinciannya ada di sini. Three nines masih mengizinkan hampir sembilan jam downtime setahun. Kalau halaman checkout atau sistem booking tidak bisa bertahan dari outage 40 menit di suatu sore sebulan sekali, angka di proposal itu tidak benar-benar melindungi Anda.

Pertanyaan berikutnya: apa yang terjadi begitu anggaran itu habis.

Bagaimana credit SLA sebenarnya bekerja

Baca SLA cloud mana pun, mekanismenya nyaris selalu sama: credit layanan bertingkat, bukan kompensasi. AWS mendefinisikan Monthly Uptime Percentage Amazon EC2 sebagai 100% dikurangi persentase menit dalam sebulan yang tidak tersedia. Mereka membayar credit 10% jika uptime turun di bawah 99,99% tapi masih di atas atau sama dengan 99,0%. Credit 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.

SLA Google Cloud Compute Engine punya bentuk yang sama. Monthly Uptime Percentage adalah total menit dikurangi menit downtime, dibagi total menit. Credit tier-nya 10% untuk uptime 99,00–99,99%, 25% untuk 95,00–99,00%, dan 100% di bawah 95,00%, dibayar sebagai credit tagihan dan dibatasi maksimal sebesar biaya bulan itu untuk layanan yang terdampak.

Perhatikan apa yang di-credit: persentase dari tagihan, bukan persentase dari kerugian. Bayar $200 sebulan untuk compute, kena tier tertinggi, dan yang kembali cuma $200 — meski outage itu menghilangkan satu hari penuh pemesanan.

Pengecualian yang diam-diam menelan jaminannya

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, software, 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 software atau hardware 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: credit 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 outage ada di luar kontrak yang baru saja ditandatangani.

Cara membaca SLA seperti engineer, bukan seperti pembeli biasa

Lewati dulu persentase besar di judul saat membaca pertama kali. Langsung ke bagian definisi: bagaimana downtime diukur, dalam jendela waktu berapa, dan apakah satu request gagal dihitung sama dengan sepuluh ribu request gagal? Pengukuran berbasis waktu (apakah layanan tidak tersedia pada menit ini) dan pengukuran berbasis request (berapa fraksi request yang gagal) menghasilkan angka berbeda dari insiden yang sama. Tulisan kecil di kontraklah yang menentukan mana 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 payment API tidak diganti oleh credit CDN, dan SLA vendor database tidak bicara apa pun soal app server yang berjalan di atasnya.

Tidak ada satu angka tunggal untuk dicari di sini. Yang ada hanya rantai kontrak yang dinegosiasikan terpisah, dengan pengecualian terpisah pula.

Kenapa five nines cuma marketing untuk kebanyakan SME

Five nines terdengar seperti pilihan paling aman. Untuk hampir semua SME, itu justru target yang salah. Google SRE Workbook menjelaskan trade-off-nya 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. Pelanggan ritel tidak bisa membedakan 99,9% dari 99,999%. Yang terasa buat mereka justru roadmap fitur yang mandek karena anggaran habis untuk mengejar five nines.

Bab yang sama menyebut biaya kedua: penyebab utama outage 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 uptime-nya sudah berhenti berkembang, dan itu sendiri adalah bentuk kegagalan.

Error budget: alternatif praktis dari mengejar nines

Bayangkan error budget seperti jatah cuti sakit. Tidak perlu berusaha memakainya sampai nol, tapi juga jangan berpura-pura jatahnya tidak ada. Yang perlu diputuskan cuma kapan memakainya.

Buku SRE Google memberi nama dan angka pada trade-off ini: error budget adalah 100% dikurangi SLO — Service Level Objective, target layanan yang dipasang tim buat dirinya sendiri, bukan janji ke pelanggan. Kalau target availability-nya 99,9%, error budget-nya 0,1% — jatah waktu yang boleh dipakai untuk down. 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. Ia menggantikan debat tanpa akhir soal seberapa hati-hati harus bertindak dengan satu angka jatah yang dipakai bersama-sama.

Untuk tim engineering 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 downtime yang sanggup ditanggung bisnis ini. Bukan membiarkan persentase marketing yang menjawabnya.

Checklist pembeli sebelum tanda tangan

• Ubah persentase yang dijanjikan jadi toleransi downtime Anda sendiri dalam jam, pakai tabel di atas, bukan copy marketing-nya.
• Baca klausul pengecualian sebelum tabel tingkat credit. Di situlah nasib sebagian besar jaminannya ditentukan.
• Cari batas waktu pengajuan klaim. Kebanyakan SLA mewajibkan outage dilaporkan dalam jendela waktu tertentu; lewat dari itu, Anda tidak dapat apa-apa — credit tidak turun otomatis.
• Tanyakan apa yang sepenuhnya di luar cakupan SLA — fitur preview, API tertentu, tier 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.

Di mana posisi SME yang membeli hosting atau SaaS di Indonesia

Perlakukan SLA apa adanya: hitung-hitungan risiko vendor atas layanannya sendiri, dituangkan dalam credit tier yang sanggup mereka tanggung. Bukan janji bahwa layanan akan terus jalan, dan bukan rencana untuk mengganti kerugian Anda kalau tidak.

Satu vendor dengan angka besar tapi tanpa rencana redundansi tetap saja jadi single point of failure. Bangun error budget Anda sendiri dari apa yang sanggup ditanggung bisnis, lalu rancang sistemnya dan pantau dengan angka itu sebagai patokan, bukannya berburu angka milik orang lain.